Java's baby steps toward open source

According to Brian Behlendorf, co-founder of the Apache Web Server Project and founder of Collabnet, the challenge lies in eliminating the dichotomy between compatible and flexible open source distributions.

Phipps expressed the dichotomy in terms of two successful "freedom" camps: "There are two freedom camps. One is facilitated by guaranteeing the vendor implementations will be compatible. The other has its freedom guaranteed by standardized licensing. Both make their source code available. The question is how can we bring those successful freedom communities together."

Compatible, in this case, is Sun's requirement that implementations of Java go through a compatibility testing suite to be certified as compliant to the standard set by the Java Community Process.

For enterprises, compatibility is a desirable, and there is less compulsion to mess with the underlying code. For Sun, compatibility to a single specification is also a way to prevent code forking, as happened in the Unix world that fragmented the industry with incompatible solutions, and more recently with Linux, which has many commonalities and some compatibility from one distribution to the next. But, absent of the guarantee of cross-vendor compatibility found in the Java world, Linux--like Unix--has been victimized by proprietary trappings that lock-in end users.

Sun is concerned that IBM, BEA or Microsoft could use their market clout and ample resources to create a Java fork that then could become a dominant "standard," leaving in the dust Sun's dream of a more level playing field with multiple choices and more predictable and less costly implementation.

"The issue is not with the open source community," Phipps said. "The problem is in giving away rights unintentionally by those who don't care about the community ethos."

The open source development community wants access to source code and the capability to make modifications without encumbrance. How the two freedom camps will unite remains uncertain. "The devil is in the details…we need an actual implementation," Phipps said. As an example, the Apache Software Foundation (ASF) is doing an implementation of a J2EE server, the Geronimo project.

The project is nearing completion and certification, but a legal issue is holding up the process. As documented on the Geronimo project download site, the Geronimo license requires the ASF present a notice from Sun with certified releases:

Any redistributed derivative work of the software licensed hereunder must be compatible and branded with the appropriate compatibility logo specified by Sun and licensed by Sun pursuant to a separate Trademark License required to be executed by you with Sun.

The implication of the Sun notice is that for every change to the code, the J2EE server would have to be retested for compatibility. "If you have to test every derivative work--which can be as basic as installing a patch--it's an incredible amount of overhead. The risk of divergence from the standard is minimal. It's a tradeoff between flexibility and conformance to a specification," Behlendorf said. "We are in conversation with Sun and working within the system. We haven't yet considered whether it's the wrong approach to resolving the issues," Behlendorf added.

The ASF is working with Sun to resolve problems with the content of the notice, and has proposed an alternate wording:

Any claims of compliance to Java(tm) Technology Specification(s) apply only to the original, unmodified Work. Derivative Works do not inherit compliance and may be subject to third-party restrictions on claims of compliance and use of related trademarks.

But given the historical success of uncertified open source J2EE servers such as JBOSS, language like this, which subtly endorses forking, gives Sun the jitters as long as open-source-savvy predators like IBM lurk in the shadows.

Behlendorf is optimistic that the open source community has a built-in, self-regulating element that will prevent forking that fragments Java. "If a technology is widely promulgated and used, and open source, it can't become a point of control," Behlendorf said. "We don't expect a repeat of Unix. It sounds idealistic but Linux forks and coalesces all the time. People converge to a common standard."

Behlendorf's assessment of the ever changing status quo may be on the money. However, it fails to acknowledge the discomfort that enterprises have with such randomness as well as the comfort zone that those enterprises seek from more explicit standards. De jure standards like the Java Community Process that's behind Java give buyers significant leverage over their solution providers.

Switching because your current solution is too slow, unstable, insecure, or expensive when compared to other solutions is never easy. Consider how wedded the world is to Microsoft's solutions in spite of the risks that come with them. Switching is easiest when there's a standard to which all implementations must conform. Compliance with standards and competition on implementations is what helps to keep costs in check as well.

The concern that Behlendorf and others in the open source community have is that innovation will be slowed because of the compatibility compliance testing. A truth-in-labeling approach, in which software is clearly marked as compliant or not, could provide the flexibility programmers want.

Linux may indeed coalesce. Given the fact that it predictably forks, enterprises using Linux have no illusions about switching distributions. As proven by Red Hat's at-will repricing from free to fee for its distribution of Linux and the number of companies that instantly subscribed, it puts the vendor in charge of both your IT and your bottom line instead of you. Any reproduction of that phenomenon in the Java ecosystem may ultimately produce the same effect.

You can write to me at dan.farber@cnet.com. If you're looking for my commentaries on other IT topics, check out my blog Between the Lines or my column archives.