Embedded Muse 31 Copyright 1999 TGG January 7, 1999

EDITOR: Jack Ganssle, jack@ganssle.com

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

Embedded Seminar in San Jose

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.

The Trouble with Open Source

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