Richard Green, vice president for software at Sun Microsystems, will lead the company's effort to release Java to the open-source community at some as-yet-unknown point in the future. In an interview here with Computerworld, Green talked about how Sun plans to work through any problems raised by open-sourcing.
Are there any caveats or "ifs" to Sun's plan to open-source Java?
I think the only caveats would be that if our findings, based on the feedback from the community, were overwhelmingly against it, [then] we would certainly reconsider. And it's plausible, it is imaginable -- although unlikely -- that people would be concerned about risks of incompatibility as a byproduct of this. That evokes significant fear and risk [concerns] in people, and that's the only thing I can foresee as a gating issue.
What will be the process for getting community feedback?
I can't give a date when we will know. But I think we established during the [conference] some of the means that we will be using, which is membership feedback, participation in a [Java Community Process] and other things, [and] the number of downloads of both the NetBeans tools as well as the Java implementations. The more activity and the more involvement that there is, the greater the likelihood that people will be compelled to rely on the branded and compatible versions of the open-source software to go do it.
If feedback were negative, would Sun drop the open-source idea?
I don't think dropping the whole idea is a likely possibility. Our strong perspective is to proceed here, and if there is a matching strong reason in the community not to do so, our preference would be to try to work it out rather than just stop.
What about Sun's longtime fear that an open-source model could lead to multiple implementations of Java? Why would you want to build an implementation of any software platform that could not run the application base out there?
It's the mass. As the number of lines of code that use compatible Java continue to go up, there is increased force to ensure that implementations of the platform are compatible. Developers don't like to build apps that don't run.
Can you cite an instance where open-sourcing led to multiple implementations of a technology?
There are certainly different flavors of Linux. If you look at ISVs out there, they will say, 'We certify on this version of Red Hat, but not on SUSE.' The behavior of ISVs [is] demonstrating that there has been a fracturing in the Linux market. It's clear -- you have to buy a copy of an application not for Linux, but for Red Hat or a copy of an application for SUSE. That is indirectly but very clearly an indication of fracturing.
What does "open-source" mean in the case of Java?
In general, it's a little early to state very clearly what licensing technique we would use, although a strong leaning to an existing, well-practiced license is likely. But without being able to specify the license, I can't answer that question in very great detail.
What did Sun CEO Jonathan Schwartz mean when he said he wants the Java code released as soon as possible?
We will do it no sooner than when we can kind of measure what the community needs. Under those constraints, as soon as possible is accurate.
Is the need for faster innovation driving the desire to open the code?
I don't think so. It's important to clarify that this is not a black-and-white situation. We have done a great deal in Java to open-source it, and this is the last bit that we're talking about here. It's hardly like this is new. I think people are making a much bigger story out of this than need be. The key reason we want to do this is to get Java in more people's hands. We don't have an innovation issue. In fact, sometimes we're told that people cannot digest the new releases, the rate of change, of software that comes out from the Java process.
What will open-source Java mean for CIOs?
I think the positive message for them is [that] the likelihood of access and the growth of an industry that will give them competitive offerings is likely to increase.