mult.ifario.us

It looks like SUN's serious about open sourcing Java, where Java means the JDK. Among the various languages that I use, I could count the number of times that I've looked at the source code for Ruby, Python, Perl, GCC, GCL, and GHC on the fingers of an absent-minded stonemason, and almost all of those times have been when I wanted to compile something bleeding edge on an obscure operating system. Diving into a highly complex codebase and making positive changes simply isn't done. The SUN JVMs are already open enough for my taste. The JVMTI is available as a plug-in point, and the source code for the Java standard libraries is available.

Will "open source Java" prevent cruft from getting into the standard libraries for Java or evict some of the current dross and detritus? Will it save us from the next EJB or Crimson? Strip the Java standard libraries down to a minimal subset of what they currently contain, don't put it back, provide a great package manager, and that's open enough for me.

The important thing for people to realize is that both individually and collectively, the WS-* specifications are a work in progress. Wwork is ongoing by vendors, by end-users, by thought leaders, to figure out what is important (i.e., useful) through a mixture of implementation and experimentation.

A new specification should be looked at as a proposed experiment. The experiment should be based on a set of well-considered hypotheses and motivated by practical experiences. The history of the accepted standards in the space (e.g., the evolution of SOAP from the initial proposal to the refinements outlined by the WS-I Basic Profile) bears this out, and other experiments (e.g., BPEL4WS 1.1 becoming WS-BPEL 2.0) are being tempered by implementers and collective discussion. The questions in my mind are not so much about establishing the fundamental and forever immutable tenets of Web Services — always an impossible task for any effort — but rather about ensuring that the experiments that we are investing in are properly conceived, controlled, and executed.

Microsoft's behavior has always raised questions about their support for standards-based software and interoperability, but Microsoft's departure from the WS-Choreography working group at the W3C (see the bottom of the IPR document) seems to make it clear that they have no interest in harmonizing their pieces of BPEL4WS, WS-ReliableMessaging, and other web services standards with the output of the working group.

To complement the Web Services Reliable Messaging specification currently in-progress in OASIS, Microsoft, IBM, BEA, and TIBCO just released WS-ReliableMessaging. (The WS-Addressing specification is in the same salvo, presumably to supply unambiguous identification of endpoints for the purpose of tracking acknowledgements.) The OASIS version (which I mentioned earlier in my weblog) was initially publicized as "WS-Reliability".

The OASIS version is backed (in terms of initial committee membership) by Hitachi, Fujitsu, WebMethods, Sonic Software, NEC, Oracle, IONA, SeeBeyond, WRQ, SAP, and Sun. The other version is backed (in terms of authorship) by IBM, Microsoft, BEA, and TIBCO.

The kicker in the Microsoft/IBM/TIBCO version is, as expected:

EXCEPT FOR THE COPYRIGHT LICENSE GRANTED ABOVE [to reproduce the specification document], THE AUTHORS DO NOT GRANT, EITHER EXPRESSLY OR IMPLIEDLY, A LICENSE TO ANY INTELLECTUAL PROPERTY, INCLUDING PATENTS, THEY OWN OR CONTROL.

(Is "impliedly" a word?) OASIS has some more reasonable IP terms. At any rate, I'm not sure what "intellectual property" IBM/Microsoft/TIBCO could possibly be referring to (other than potentially spurrious patents), since sequence numbers, acknowledgements, endpoint identification, and timeouts are part of more messaging and communications protocols in the network domain, Internet domain (SMTP), and business domain (HL7, EDI, EDI-INT, etc.) than I could count.

A recent article on ZDNet entitled "Web Services in Serious Jeopardy" reviews the intellectual property issues swirling around BPEL4WS, and David Berlind takes a hard stance with respect to adoption:

What can you do? Refuse to develop anything with BPEL4WS or the applications servers that support it (to the exclusion of something standard) until the specification is royalty-free.

There are a lot of "standards" floating around the web services and business process enactment space right now, including a pile of "standards" recently emitted by BEA. The BPEL4WS, WS-Transaction, and WS-Coordination specifications are also frequently and mistakenly referred to as "standards". Last time I checked, before something could honestly be referred to as a standard, it needed to be proposed to and subsequently approved by an (honest) standards body like the W3C, ISO, ANSI, OASIS, or IETF.

For instance, I like the IETF's perspective on announcing compliance with a proposal or submission:

An Internet-Draft is NOT a means of "publishing" a specification; specifications are published through the RFC mechanism — Internet-Drafts have no formal status, and are subject to change or removal at any time. Under no circumstances should an Internet-Draft be referenced by any paper, report, or Request-for-Proposal, nor should a vendor claim compliance with an Internet-Draft.

Perhaps it is now necessary for the community to move to a higher level and create an open standard for opens standards. Ideally, the specification for an open standard could serve as its own reference implementation, and, if a validator were to be implemented, the difference between marketing collateral, white papers, proposals, working drafts, and standards (as well as qualifiers such as "open") could be unambiguously determined.

Seriously, and on the bright side, seeing large vendors jockey for position with respect to "standards" is a good thing even if some of the "standards" are not. The software marketplace has validated the importance of open standards as starting points for interoperability and collaboration, and the rush to market "standards" shows that vendors recognize this importance. On the one hand, large vendors are not eager to pursue open standards because the accompanying interoperability and collaboration also drive innovation and competition. On the other hand, large vendors should favor honest, open standards because they create markets. Where's the John Maynard Keynes of technology when we need him?

Eric Newcomer (IONA's CTO and a heavyweight technologist) wrote a thoughtful piece on C|Net called "The Web Services Shell Game". I would like to quote the whole thing, but this paragraph in particular stuck with me:

The market leaders are scared that comprehensively adopted Web services standards will change the economics of the software industry and make their investments in current products unsustainable. The choice for these vendors is to start over and risk losing market share or to try and control the revolution. Not surprisingly, these companies choose the latter option.

I have nothing to add.