why has CORBA failed?

There’s a great article in this month’s ACM Queue entitled The Rise and Fall of CORBA. Since it’s authored by Michi Henning, who worked on CORBA as part of the OMG’s architecture board, and subsequently became an ORB implementer, consultant, and author of a book on CORBA Programming with C++, I had to take notice. The article itself isn’t available online, so I’m sorry I can’t suggest that you read it — instead you’ll just have to put up with my opinions, peppered with some quotes from the article.

My own experiences with CORBA were short and sweet. Maybe "sweet" isn’t the right word to use — bitter might be more appropriate. Unfortunately, I was in school at the time, and was forced to use some ORB implementation as part of a course on distributed computing. Being in academia, particularly as a student, tends to cloud one’s judgment about the quality of the tools handed to you: if your innate feeling is that the tools suck, you tend to blame your own inexperience rather than suspecting that the tools really do suck. And at the time (1998), CORBA really was the darling of the development world. Remember, CORBA is middleware from the days before the Web, so in the absence of easy-to-use quasi-middleware like XML-RPC, SOAP and other web services, it really did have a rosy future.

Looking back on CORBA (now relegated to niche status), Henning argues that it’s too complicated for developers, has poor performance, and has other serious shortcomings like lack of thread support, lack of a diverse base of language bindings, and has too much competition from "good enough" middleware based around XML to be effective. I wholeheartedly agree with him, and his examples of unnecessary bloatware and confusing APIs bring back horrible memories of IDL compilers turning my simple IDL definition into 200 lines of incomprehensible bloatware, with 15-20 methods that you had to implement just to get to "Hello, World".

So CORBA is a technical failure. How did it get this way? Henning asks how it is possible for a technology produced by the world’s largest software consortium (the Object Management Group) to suffer such flaws. He postulates that the technical problems are but a symptom, not a cause:

The OMG is an organization that publishes technology based on consensus. In essence, members vote to issue an RFP for a specification, member companies submit draft specifications in response, and the members vote on which draft to accept as a standard. In theory, this democratic process is fair and equitable, but in practice, it does not work.

What Henning has just described is a classic "design by committee" failure. There are other serious flaws in the process:

1. No entry qualifications to participate in the standards process (many of the members barely understand the technology being voted upon)
2. RFPs frequently call for unproven technology and there is no requirement to have practical experience in the technology area before responding to an RFP
3. Vendors respond to RFPs even with known technical flaws, out of greed and/or a desire to compete with others for customers of (defective) technology
4. Vendors abuse the standardization process for their own goals (e.g. trying to block the adoption of a standard that deviates from their own pre-existing products)
5. RFPs often wind up being "kitchen sink" documents after enough revisions, in an attempt to ease political infighting by simply acquiescing and bogging down the RFP with more baggage
6. The OMG process doesn’t require a reference implementation for a standard before adoption, which I think is the most serious flaw; how can you approve something and claim it is the worldwide standard for a particular process if you don’t even know if the implementation will succeed?

CORBA is a failure of the OMG’s own technology adoption process in which it is difficult to achieve mediocrity, never mind excellence. But I think the key lesson — and a cynical one at that — lies in the final pages of the article. Let me just quote directly since I think Henning says it better than I could:

A democratic process such as the OMG’s is uniquely ill-suited for creating 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.

I’ve always been quite critical of consortia like the OMG, because their prodigious output has seemed to be abstract piles of useless garbage that nobody will ever use. Again, I’ve frequently chalked up this gut feeling to my own inexperience, but here’s someone who has plenty of experience in the field pointing out exactly the same flaws! On the topic of Web services, you can see others criticizing the work of marginally-useful standards bodies like the WCAG, which again — surprise, surprise — get bogged down in feature bloat, infighting, architectural incomprehensibility, etc. etc.

I really do think that technical excellence can often (perhaps always?) only be achieved by having a benevolent dictator running the show. Ultimately there has to be someone calling the shots and making final technical decisions; this is why projects like Linux and FreeBSD work so well. Sure, the internal project organization is more-or-less flat, but the buck does stop somewhere, and there is the notion of seniority within the team. And so, FreeBSD will continue to churn out innovative but stable versions of the operating system, while roundtable democracies like the OMG will continue to decimate forests of trees in printing specifications than few will use.

The bottom line: Communism didn’t work for the planet, so it sure isn’t going to work for standards bodies either.