Competing Standards - Embedded.com

Competing Standards



#include

Competing Standards

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, exceptional projects with exceptional needs exist. 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 a lot of neat things with a basic set of Legos, 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, many roadblocks make it difficult to achieve such openness. I recently ran into one of these obstacles 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, more and more attempts have been made to create semi-proprietary “open” standards groups. Sun's 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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.