embedded software boot camp

Open Source Embedded Software

Wednesday, September 12th, 2001 by Michael Barr

Magazines like Embedded Systems Programming are founded on the ideal that the free flow of information between technological peers, even at competing organizations, benefits everyone. This is a view shared by the proponents of open source software. Whether it’s an operating system, a memory test suite, or simply a useful design paradigm, why should any one of us reinvent what has already been invented (and tested) by others in our profession?

Certainly, there are exceptional projects with exceptional needs. In such cases, invention of new techniques and technologies cannot be avoided. We can’t always combine existing components into a useful whole. However, such exceptional cases are rare. To take an example from childhood, you can build quite a lot of neat things with a basic set of Lego’s, but a “spaceship windshield” is a one-of-a-kind part for one-of-a-kind projects.

Most of the time, though, we’re all using the same basic components. Processors, operating systems, device drivers, and other building blocks are transferable from one company or project to another. Once developed, a technology or technique is, in fact, most valuable when it is shared with others. This benefits the creators too, as others may strengthen the component by finding and fixing flaws. This is the academic model of development, transferred to the commercial marketplace.

Unfortunately, there are many roadblocks to such openness. I recently ran into one of these when I tried to arrange a new point/counterpoint discussion. As envisioned, the debate would have addressed the differences in thinking and approach between two competing groups working toward real-time Java. A technological leader of each group was willing to participate and both thought this open debate would be a good way to uncover any flaws in one or both approaches. It might even have helped to bring the two groups together, if they found a high degree of overlap.

Plans for the debate were put on hold, though, after non-technical people on both sides expressed concern. It seems both groups are jockeying for position in the marketplace; both hope their approach will become the de facto standard for real-time Java. Though both groups acknowledge the need for open debate in the discussion of technology that could risk human lives and are conducting their own meetings publicly, they remain unwilling to debate each other.

In addition to the feeling of frustration at the intrusion of non-technical issues and people into what should have been a purely technical discussion, I also have a feeling of dread. I suspect that progress toward a real-time Java standard will be slowed (or doomed to failure) as a result of the lack of discussion. How can either of two competing solutions to the same problem be adopted as a standard without such a debate occurring first? What are those of us outside the two groups to think if these two large self-proclaimed “expert groups” cannot achieve a common standard on their own?

As the open-source movement has caught on in recent years, there have been more and more attempts to create semi-proprietary “open” standards groups. Sun’s Java Community Process, which is behind one of the two real-time Java groups, is a prime example. But it’s not at all clear that today’s “open” standards groups are anything more than the old proprietary standards, disguised.

NOTE: this article originally published on 12/6/00.

Tags: , ,

Leave a Reply