Communications - August 2008

sion of the architectural vision.

CORBA’s numerous technical flaws have accumulated to a point where it is very difficult to fix or add anything without breaking something else. For example, every revision of CORBA’s interoperability protocol had to make incompatible changes, and many fixes and clarifications to the protocol had to be reworked several times because of unforeseen interactions with features that were added over time.

can We Learn from the Past?

A democratic process such as the OMG’s is uniquely ill suited for creating good software. Despite the known procedural problems, however, the industry prefers to rely on large consortia to produce technology. Web services, the current silver bullet of middleware, uses a process much like the OMG’s and, by many accounts, also suffers from infighting, fragmentation, lack of architectural coherence, design by committee, and feature bloat. It seems inevitable that Web services will enact a history quite similar to CORBA’s.

What steps should we take to end up with a better standards process and better middleware? Seeing that procedural failures are the root cause of technical failures, I suggest at least the following:

Standards consortia need iron-cast rules to ensure that they standardize existing best practice. There is no room for innovation in standards: throwing in “just that extra little feature” inevitably causes unforeseen technical problems, despite the best intentions.

No standard should be approved without a reference implementation. This provides a first-line sanity check of what is being standardized. (No one is brilliant enough to look at a specification and be certain it does not contain hidden flaws without actually implementing it.)

No standard should be approved without having been used to implement a few projects of realistic complexity. This is necessary to weed out poor APIs: too often, the implementers of an API never actually use their own interfaces, with disastrous consequences for usability.

Interestingly, the open source community has done a much better job of adhering to these rules than have industry consortia.

Open source innovation usually is subject to a Darwinian selection process. Dif-

ferent developers implement their ideas of how something should work, and others try to use the feature and critique or improve it. That way, the software is

^technical ^problems ^extensively ^scrutinized ^and ^tested, ^andonly the “fittest” version survives. (Many are at the heart open source projects formalize this pro- _of _coRBa’s _decline. cess with alternating experimental and _production _releases: _the _experimentalthis raises the releases act as the test bed and evolu- question of how ^tionary ^filter.)To create quality software, the ability it is possible for to say “no” is usually far more important than the ability to say “yes.” Open source

a technology that embodies this in something that can be was produced called “benevolent dictatorship”: even _though _many _people _contribute _to _theby the world’s overall effort, a single expert (or a small _largest _software cabal of experts) ultimately accepts or _ejects _each _proposed _change. _Thisconsortium to preserves the original architectural vi- _suffer _such _flaws. sion and stops the proverbial too many _cooks _from _spoiling _the _broth.as it turns out, At the heart of these open source practices are two essential prerequi-

the technical sites: cooperation and trust. Without problems are cooperation, the evolutionary process _cannot _work; _and _without _trust, _no _ca-a symptom rather bal of experts can act as an ultimate ar- than a cause. biter. This, however, is precisely where _software _consortia _find _their _doom. _Itis naïve to put competing vendors and customers into a consortium and expect them to come up with a high-quality product—commercial realities ensure that cooperation and trust are the last things on the participants’ minds.

Of course, software consortia contribute to an evolutionary process just as much as open source projects do. But it is the commercial marketplace that acts as the test bed and evolutionary filter, and it is the customers who, with their wallets, act as the (usually not so benevolent) dictator. This amounts to little more than an industry that throws up silver bullets and customers who leap after them like lemmings over a cliff. Until we change this process, the day of universal e-commerce middleware is as far away as ever.

Michi henning ( michi@zeroc.com) is chief scientist of ZeroC, Palm Beach Garden, FL. From 1995 to 2002, he worked on CORBA as a member of the OMG’s architecture board and as an ORB implementer, consultant, and trainer.