Via Mark Baker I found an article in the ACM Queue entitled The Rise and Fall of CORBA by Michi Henning. Lots of good stuff in the article some of which is excerpted below.

the CCM (CORBA Component Model). A specification for CCM was finally published in late 1999 but turned out to be largely a nonevent:

• The specification was large and complex and much of it had never been implemented, not even as a proof of concept. Reading the document made it clear that CCM was technically immature; sections of it were essentially unimplementable or, if they were implementable, did not provide portability.
• No commercial CORBA vendor made a commitment to implement CCM, making it a stillborn child.
• Even if implementations had been available by the time CCM was finally published, it was too late. The horse had already bolted: EJB had become entrenched in the industry to the point where another component technology had no chance of success.

The failure of CCM did little to boost the confidence of CORBA customers, who were still stuck with their complex technology.
...
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:

1. Standards consortia need iron-clad rules to ensure that they standardize existing best practice.
   
2. No standard should be approved without a reference implementation.
   
3. No standard should be approved without having been used to implement a few projects of realistic complexity.
   
4. Open source innovation usually is subject to a Darwinian selection process.
   
5. To create quality software, the ability to say “no” is usually far more important than the ability to say “yes.”.

The lessons listed above seem rather self evident and obvious yet it s a sad fact of the software industry that the mistakes of CORBA keep getting made all over again. Core XML technologies like W3C XML Schema and XQuery are 'standards' without a reference implementation which invented new features by committee instead of standardizing best practice. At least one of the guidelines is probably unrealistic though. It is hard to require that a standard shouldn't be approved until it has been used to solve a real-world problem since people solving real-world problems typically don't want to be used as guinea pigs.