Green spoke with Computerworld Wednesday. Excerpts from that interview follow:
Are there any caveats or 'ifs' 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 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, 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 programs 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 keying 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 won'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-practiced licensed is likely what we will do. But without being able to specify the license, I can't answer that question in very great detail.
You released Solaris under the Common Development and Distribution License (CDDL). Why would you do it differently here? It's as I said: It's the feedback from the community, 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 License], etc., 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 of the constraints of the license itself, but it also tends to impart some sense of industrywide sharing as you use more industry standard licenses. So we are going to be looking at both sides of this.
Both sides meaning what? The implication of your comment in the context of CDDL is that this is a Sun-centric license versus different open-source licenses. So we are going to look at the continuum of licenses 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, etc. 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 organizations 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 gotten 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. So to them, what's your message? 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 of giving IT organizations 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 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 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.
Apart from Sun, what platforms and languages out there have taken this path and have forked and delivered this worse-case scenario? What examples out there illustrate your fear? 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.' So explicitly, when you look at the behavior 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 measure of a caveat -- if there is negative feedback from the community that could be a problem with you going forward with the 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 manner where you can ultimately bring Java open-source? I think -- of any program, any technology that has the potential for dramatically mitigating the issue -- it would be Java, because of the history of compatibility and the tools we have.