Richard Green, the Sun Microsystems executive who will lead the company’s effort to open-source Java, says a major issue with any such move is the longstanding fear that Java will fracture and follow a path similar to Linux. Despite that concern, Sun announced its Java open-source intentions plans this week at JavaOne, which the company says was attended by about 15,000 people. Green, Sun’s vice president for software, says the company’s default position will be to work through any problems raised by open-sourcing. Sun has not yet announced a timetable for the release or how Java will be licensed as open-source.
Do any caveats apply to your 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 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 in people, and that’s the only thing I can foresee as [being] a gating issue.
What will be the process for getting this community feedback, and at what point will you know whether you have that buy-in?
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 JCP [Java Community Process] and other things, [and] the number of downloads of both the Net Beans 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 understanding and compelled to rely on the branded and compatible versions of the open-source software to go do it.
So, if you get negative feedback and people saying, ‘We have grave concerns about Java forking’, you may drop the whole idea of open-sourcing Java?
I don’t think ‘drop the whole idea’ is a likely possibility. I think we have to go sit down with representatives from the community and JCP and really understand the reasons for concern, and see if we can put programmes in place to overcome them. 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.
In the past Sun has been pretty clear about its fears that open-source might lead to a forking. What is prompting this shift on the part of Sun?
There [are] two big trends. In general, the open-source initiatives around the world — a really good example that we’re keen on is the Open Solaris initiative — are demonstrating that additional contribution, additional use, produces better innovation, more rapid innovation, and doesn’t seem to compel people to want to diverge. We certainly haven’t seen that very frequently. There’s another issue: over time, the continuous growth of the portfolio of applications that have been written to a compatible platform exert pressure to remain compatible. If there are these applications out there that will run only on a compatible version, and if you were to come out and diverge with an incompatible version, you wouldn’t be able to run those apps. Who would do that? 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.
What does open-source mean in the case of Java?
Does it mean the same thing to you as open-source Apache or Linux? In general, as I noted, it’s a little early to state very clearly what licensing technique we would use, although a strong leaning to an existing, well-practised licence is likely what we will do. But, without being able to specify the licence, I can’t answer that question in very great detail.
You released Solaris under the Common Development and Distribution Licence [CDDL]. Why would you do it differently here?
It’s as I said: it’s the feedback from the community [and] it’s examining what [the] goals are. I’m not sure yet. There is lot of open-source Linux out there under GPL [General Public Licence], etcetera, and that also seems to be a very interesting and successful model. I do want to make sure that there is no issue or question about Sun’s intent when we go and do this. And so the licensing scheme not only has implications for the constraints of the licence itself, but it also tends to impart some sense of industrywide sharing as you use more industry standard licences. So we are going to be looking at both sides of this.
What do you mean by ‘both sides’?
The implication of your comment in the context of CDDL is that this is a Sun-centric licence versus different open-source licences. So, we are going to look at the continuum of licences that we have used and others have used to figure out what the community wants.
Sun CEO Jonathan Schwartz says he wants the Java code released as soon as possible. What does as soon as possible mean to you?
No sooner than what I implied. We will do [it] no sooner than what I’ve implied. 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.
Some analysts believe you need to open up Java to ward off competitive threats, because, within the process it’s now under, it just doesn’t innovate quick enough, and that’s the driving motivation for going to open-source.
I don’t think so. It is likely that in open-sourcing, or completing the open-sourcing of Java, to be fair, so much of Java has been opened-sourced already. Java EE [Enterprise Edition], all the tools, etcetera, 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, the SE [Standard Edition] bit that we’re talking about here. It’s hardly like this is new or precedent and, in that regard, 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. There are organisations and businesses that can only accept open-source technology given certain licensing models and certain restrictions or the lack thereof, and this is about access and community scale more than innovation.
Now, that said, certainly the more people who are using Java and able to amend Java, doubtlessly the rate of innovation will change. But we haven’t in general [received] feedback from developers, from end users, from major corporations, that Java is stagnating. 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.
CIOs with application developers on staff care more about the business value of something than they do about the nuts and bolts of it. What’s your message to them?
Why should they be concerned? 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. There [are] just more people accessing the technology, more developers, and the likelihood of growing an industry that gives them competitive choice. And so open source has the capacity to give IT organisations that increased value.
It also has the corollary value of, depending on the products that they buy, they have access to the source code and [so] can better understand the workings of the technology, and address issues as they come up if others can’t. So, it has that associated value as well. But the flip side, of course, is [that] one of the core values of the Java ecosystem is ‘write once, run anywhere’ — compatibility matters. There is a validation and branding exercise that gives you some sense of certainty, and I know CIOs are very interested in that.
What platforms and languages have taken this path and forked, and delivered this worse-case scenario? What examples out there illustrate your fear?
There are certainly different flavours of Linux. If you look at ISVs out there, they will say, ‘We certify on this version of Red Hat, but not on SUSE.’ So, explicitly, when you look at the behaviour of ISVs, they are demonstrating that there has been a fracturing in the Linux market. It’s very 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.
How can you avoid that and still go open-source? Is that basically part and parcel of the open-source process?
It is a potential. But, in other realms, there isn’t the history of compatibility as a priority, as a value — a whole ecosystem built on that. The other case is there weren’t the tools in other realms like Linux to validate compatibility. There is no tool set that will tell you that this Linux is identical to that Linux. There is none. We have built that over the years in Java. We can validate and certify compatibility, enormous test suites that Sun and others have contributed to that we use for the certification process.
You are saying upfront that you are going to open source Java. But there is a kind of caveat: if there is negative feedback from the community that could be a problem with you [regard to] going forward with open source.
It’s worthy of consideration. But I also made it clear that if there are significant considerations our default will be to work through them — it won’t be to stop.
So you think this whole issue of forking can be solved in such a way that you can, ultimately, make Java open source?
I think — of any program, any technology that has the potential to dramatically mitigate [against this] issue — it is Java, because of the history of compatibility and the tools we have.
Join the Computerworld LinkedIn Group. This group is open to IT Leaders, MIS & IT Managers, Network & Infrastructure Managers who share insights, discuss challenges & wins and keep abreast of cutting edge technologies.