Tweet Follow @jack_ganssle

Embedded Muse 31 Copyright 1999 TGG January 7, 1999

You may redistribute this newsletter for noncommercial purposes. For commercial use contact

EDITOR: Jack Ganssle,

- Embedded Seminar in San Jose
- The Trouble with Open Source
- Thought for the Week
- About The Embedded Muse

Embedded Seminar in San Jose

I’ll present the seminar "The Best Ideas for Developing Better Firmware Faster” in San Jose on February 18, 1999.

The focus is uniquely on embedded systems. I'll talk about ways to link the hardware and software, to identify and stamp out bugs, to manage risk, and to meet impossible deadlines. If you’re interested reserve early as these seminars fill completely.

For more information check out or email

The Trouble with Open Source

One of the reputedly great things about a lot of public domain software is that it often comes with the source code.

I don’t want the source code. What am I going to do with it? Fix bugs? Most of us are far too busy just doing our own work to worry about maintaining someone else’s code. I personally have written half a dozen compilers, yet I’d never, in a million years, want to dig into the innards of a freebie compiler to find some obscure optimization bug, or into an OS to figure out why context switches corrupt registers. No way.

80% of all embedded systems are delivered late. If we figure that maintaining public domain software is now another required part of developing our own systems, well, disaster looms.

Now, the argument that open source means lots of people - *other* people - are correcting bugs is certainly valid. Just don’t let it be me, or anyone else concerned with getting a product to market on time.

A healthy software world means we buy development products for cold hard cash. That money goes into other developers’ pockets; part of the service they provide is a useful support group that efficiently deals with bugs. Admittedly many commercial products don’t live up to this ideal. I’m convinced, though, that as long as we’re all mucking around in each others’ code the software crisis will never go away.

This philosophy goes to modules that we include in our own products, like communications packages and real time OSes. Yeah, a lot of these off-the-shelf products are less than perfect. But as long as we demand access to the source we’ll never be truly productive developers.

Fact: Time to market pressures grow daily; it’s almost impossible to get a product out the door on-time.

Fact: Buggy tools and software packages are schedule-killers.

Fact (well, at least this is my contention): If we are forced to maintain our tools we’re doomed.

Too many developers have bought into the “I can fix it” school of thought for dealing with the reality of poor tools. Better solutions exist.

GNU tools show the yin and yang of the “open source” model. Sure, you can download all of the GNU source and build your own compilers. Better, send Cygnus some money. Let them provide you with the tools, and then you get to hold them responsible for maintaining the products. Cygnus has leveraged the best of open source while still providing support.

Another option might be better communication between developers. If the problem is that people don’t trust commercial products, perhaps we need a repository for success and failure stories. A registry of tools versus real developer experiences. One sailing magazine tracks hundreds of boats and their owners, so that a prospective buyer can contact a dozen or more owners to get the real scoop on the product. I’d like to see something similar for commercial products so we can get a vendor-independent, real “in the trenches” view of how well a particular product stands up in real use.

But don’t give me the source code. I want to go home at nights.

Thought for the Week

News Release January 4, 1999
Redmond, Washington
Bill Gates, Chairman and CEO of Microsoft Corporation, announced today that the latest version of their Windows operating system, Windows 2000, would be delayed until the second quarter of 1901. No reason was given.