|
|
AS OF 7/4/2008 8:31PM EST
|
January 15, 2006 —
BEA, IBM and Sun are at it again. Remember that a key principle behind the Java community was “Collaborate on standards, compete on implementation”? Well, of late, developers have heard more about “compete on standards.”
The latest culprit is a spec called the Service Component Architecture, proposed by a bevy of companies, including BEA, IBM and Iona. Sun’s crying foul, complaining that SCA partially duplicates work already done by JSR 208, the Java Business Integration (JBI) specification unveiled as the centerpiece of last summer’s JavaOne.
But don’t forget: JSR 208 wasn’t a slam dunk. Both BEA and IBM abstained in the final approval ballot for Java Business Integration, and clearly those companies feel no loyalty toward a Java Community Process initiative that they didn’t support.
Worse, the fact that BEA and IBM pushed this particular project, which includes both SCA and an earlier project from the two companies called Service Data Objects, outside the Java Community Process makes one wonder exactly what the JSP is for. Complicating matters is that SCA is billed as a language-independent platform, so while it in part duplicates JBI, it’s not clear if the JCP is truly the best place for it.
According to Iona’s Eric Newcomer—who supports both JBI and SCA/SDO—the proposal will go to Eclipse, a Sun nemesis, instead of the JCP. But if that’s the plan, why were these specs developed behind closed doors, rather than using the Eclipse collaborative process?
Despite the broad acceptance of organizations like the JCP, the Eclipse Foundation and the Apache Software Foundation, it’s still far too common for companies like BEA and IBM to develop complete technologies and specifications first, and deploy them within their own products. Only after they have a comfortable head start, do they seek a community rubber stamp of the completed work. (Microsoft is just as guilty, using Ecma International to “fast track” specifications, like the Office 12 XML schema and C# language, into de facto industry standards.)
These practices abuse the notion of community development and “open standards.”
Groups like the JCP, Eclipse, Apache and Ecma should only accept projects if there is some real chance that different interest groups will have a legitimate say in the development of the specifications and technologies. Being presented with a complete spec as a fait accompli—and then endorsing that spec essentially unchanged—merely demonstrates that these organizations are focused on pleasing their corporate sponsors, not just on developing best-of-breed specifications that create opportunities and broaden a standard base for innovation.
If companies like BEA, IBM and Microsoft have good ideas for developing specifications, and want those specs to be endorsed by industry consortia, they should develop such specifications within those industry consortia, in an open, transparent and competitive manner. Then, and only then, should those consortia endorse them as standard. Rubber stamping does the software development industry a disservice. It’s time for the consortia to just say no.
|