Open Source Java: The Jason Voorhees of Technology Questions

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Like some horror B-movie villain, this is the question that just will not die: when/will/should Sun open source Java? As James and I were discussing at JavaOne just a few weeks ago, it’s a question we’ve fielded countless times over the past few years, and speaking candidly it’s not one of our favorites because of the various contexts in which the question(s) is asked. James compared the ongoing debate to a soap opera (Moonlighting, in fact), with all of the posturing that goes on; see Berlind’s summary of some of that from JavaOne here. In an effort to preemptively answer some of the questions that have arisen around the open sourcing of Java over the past few weeks, however, I thought I’d do a Q&A. At least James won’t have to do it 😉

Q: Before we get going, what is your on-the-record position on the question of open source Java? Good thing? Bad thing?
A: I haven’t changed my stance materially since the debate became more serious following the launch of Project Harmony. In my reaction to that notice I said the following:

I’ve become convinced over the years that Java’s principle and primary virtue has been compatability. Yes, some will cite the *ilities (scalability, reliability, etc) or security as their motivation for selecting Java, but overall I think Java’s attracted the crowd it has largely because of the compatability it offers. I’m not naive on the topic; I’ve spent enough time in the field to know that cross-platform compatability is a relative term (trying moving a large application from WebLogic to WebSphere and you’ll see what I mean), but overall I think portability is far better in Java than in the alternatives.

This is why – and this may surprise some people (certainly it surprised IBM when we discussed it at the time of their open letter to Sun last year) – I’m actually not in favor of an open source Java. Or to put it more clearly, I’m not in favor of an open source Java that risks in any way the compatability of the platform. Not because I’m not a fan of open source – I am, and not because I think Sun’s been a perfect steward – they’ve been good, but not great. It’s because open source offers the opportunity for forking, and while that’s been a manageable risk for projects like Linux (depending on how you see the overall distro compability), Java’s a different animal. Java’s a platform whose credibility rests on its ability to run code platform to platform, but a platform whose advocates are not always a.) on the same page or b.) content to wait for consensus building.

If a governance model is devised by which the compability of Java can be guaranteed while opening the source, I’d be first in line to support it. But I haven’t seen such a model put forward yet; the threat of “not being able to call it Java” has never impressed me as being all that intimidating an obstacle for vendors over a certain size and with certain motivations. No, I tend to agree with my colleague who used Winston Churchill’s line last year when comparing the JCP to democracy during a JavaOne panel, calling it “the worst form of governance, except all other forms of governance.”

That’s consistent with what I’ve been saying publically and privately about the open sourcing of Java all along. My thinking might be evolving on the matter slightly, but I’m more or less possessed of the above opinion.

Q: How is your opinion evolving – what’s shaped that opinion?
A: Well, a number of folks that I have great respect for have taken rather unambiguous stances in favor of open sourcing Java. These are not the kind of people that have little appreciation for the risks and threats inherent in such a move, but rather the type that understand that intimately. The most convincing of the arguments are coming from those that are closest to Sun; it’s not that an outsiders perspective, such as mine or Bob Sutor’s, is irrelevant; it’s more that those agitating for an open source Java within Sun are facing greater risks, and therefore their actions on its behalf carry more weight.

Tim Bray more or less applauded Harmony when it was launched, Danese Cooper is literally driving the open source Java bandwagon, and Simon Phipps recently undercut my assertion that forks would represent a clear and present danger to an open source Java.

Much as I might take exception to individual aspects of their various arguments, I’d be foolish not to recognize that a.) they’re all smart people, b.) they know Java, and c.) they’ve got Java’s (and in most cases, Sun’s) best interests at heart. Thus I’m not backing off on my analysis, and I maintain that the risks to an open source Java are real, but perhaps they can be mitigated under the right circumstances. Either way, I’m sure we’re going to find out.

Q: What do you mean?
A: Just that, in reading the tea leaves, it seems inevitable that Java will in fact be open sourced. When, where, and under what licensing I couldn’t say – I don’t have inside information on the topic, or at least none that I can disclose – but I’m fairly convinced now that it will happen, and probably sooner than “a couple of years.”

Q: What leads you to believe that?
A: Well, a couple of things.

  • First, there’s the demand. I might personally believe that a lot of people are looking to open source Java for the sake of open sourcing Java, rather than having a clear problem to be solved – but either way, the fact that the question keeps coming up indicates that on some level there’s demand.
  • Second, Jonathan Schwartz is on the record publically as saying that all of Sun’s software assets will eventually be open sourced.
  • Third, Jonathan and new software head Rich Green conducted a very public commentary on the subject at JavaOne; if they had no intention of ever open sourcing Java, this would seem to be a very unwise move. Part of that session gave rise to a comment made by Green and reiterated by Schwartz, that it was a not matter of whether, but how.
  • Fourth, Java is increasingly facing competition from new quarters and fronts. While some seem to still be content in talking about the development world as Java vs .NET, and some within Sun have made some very unfortunate comments dismissing the prospects for various competitors, the fact is that Java is but one amongst many potential language choices these days. For some requirements, it’s the best option. But for fewer and fewer requirements, is it the only option, even within the most conservative JEE shops.
  • Last, Sun’s got a new CEO. Some of the folks with untouchable status under the previous CEO may find themselves less so under the new one.

Q: Let’s get back to the question of forks and compatibility; how do you reconcile your concerns with forks and compatibility with Simon’s point that fork != incompatible? His view would seem to be validated by some of the most popular open source projects like those of the LAMP stack.
A: First, let me say that I agree with Simon – a fork does not, and should not, imply incompatibility. He cites the example of OO.o and NeoOffice, in which the latter is a compatible derivative of the former. It’s interesting and potentially significant that he doesn’t extend the argument to imply compatiblity via file format, but that’s an argument for its own entry.

If I can restate the original question slightly, I think what people want to know is: why is Java more at risk for incompatible forks than other open source projects, like Linux or MySQL, or bringing it closer to home, Mono. As Ian puts it:

Does open source inherently lead to compatibility problems? Hardly. How many incompatible versions of, say, Apache are there? Or the Ps of the LAMP stack (Perl, PHP, Python)? Or MySQL? GNOME? KDE? BIND? CUPS?

I could respond by questioning what is meant by Linux “compatibility,” but that would merely be a diversionary tactic – as Ian says. My real answer is simple: money. The commercial interests around Java are immense, the only one that’s close is Linux. But think of a company like IBM or Oracle; huge portions of their middleware portfolios are built in, on or around Java. The investments in the platform number are counted by B’s rather than an M’s, and as the old saying goes, people do funny things when it comes to money.

Do I think it’s inevitable that an open source Java leads to a fork? No, I do not. But do I think it’s possible that vendors could seek to extend the JVM, as Microsoft did once upon a time?Do I think it’s possible that one of the larger ISVs would attempt to fork it – or even introduce unintentional incompatiblilities? Yes, I do. Thus I’m concerned. But if Danese, Simon and Tim have the right of it, I’ll be happy to be wrong. Maybe the Java name is more valuable than I give it credit for.

It’s also possible, as Ian argues, that the lack of an open source Java is in fact causing rather than preventing forks.

Q: What role does the recently announced DLJ license for the runtime play in all of this?
A: Well, I think it’s a step down the path towards a more available Java. It’s not necessarily a step towards an open source Java, although it’s certainly evidence that Sun has a better understanding of some of the problems people have had with the platform.

But what I’m curious to see is whether or not this move has any impact on the clamor for an open source Java. In the piece I wrote when Harmony was launched, quoted above, I noted that there were many who cited the difficulty of obtaining Java as a reason for open sourcing Java, when in fact the two had little if anything to do with each other. That, as the DLJ proves, was a licensing problem, not a source problem.

Are there still reasons to open source Java, now that that licensing problem is fixed? Of course. But for those that used the distro difficulties as justification, there’s one less reason.

Q: Do you think open sourcing Java would make it more or less relevant?
A: Well, I think open sourcing Java is likely to make it more relevant – but to what degree? That’s the question. Open source unquestionably would remove some of the last barriers to entry for those within the Java community, and therefore would be open to becoming relevant in ways that it is not currently. But from there it’s a question of demand; to what degree would developers adopt Java in spaces where they might be using other technologies. Tough to say. If you believe in simplicity and productivity, you might be inclined to argue against Java being more relevant. If you’re more inclined to say that concurrency and scaling are the issues of the next several years, you might be inclined to argue for greater relevance. It all depends on where you see things going.

Q: Last question: if you think it’s inevitable that Java will be open sourced, would you care to guess as to when?
A: I hate guessing, and I dislike predicting even more, but I will say my expectation is that the timeframe is likely measured in months rather than years. Whether that’s born out or not depends on a great many things – some of which can be anticipated, some of which cannot. Personally, I hope it’s soon, so we can stop speculating on what might happen and focus on what has happened.

Update: Reading David Berlind’s response to this reminded me that I forgot my disclaimer, so here it is: Sun’s a client of ours. As is, for that matter, IBM. Oracle, however, is not, nor is MySQL or the other open source projects mentioned.


  1. There will be a hundred different views of this question if you ask 125 people. I can appreciate where you’re coming from on this. However, as I look at it, don’t we already have “forks” of the JVM? Sun has one, IBM has its own, Microsoft has one it thinks is a JVM… and there are a couple open source projects. I could write all day on the topic of why I personally think Java needs (not should, but needs) to be open source but I tend to wait for action – not soundbits from execs for media to speculate on. I’ll believe it’s open source when I see the source code. I just truly hope it won’t come out under a vendor “owned”, “open source” license…

    I REALLY like what Microsoft did with its .NET CLR. With an open source Java… hmmm… there’s many options. In the long run, I can only see this helping the Java platform thrive.

  2. Minor point, but is was actually early 2004, not 2005, when we published the open letter to Sun about open sourcing Java. This has been going on a long time…

  3. Stephen: I wrote a reply here Tuesday but it evidently didn’t actually post (I blame my GPRS connection – I am on vacation away from broadband). You referenced my “forks” blog but didn’t mention my “compatibility” blog, which I think is highly relevant. Therein lays the issue, which was very evidently the key issue for JavaOne attendees even if some voices glibly brush it off while in the guise of being helpful.

    The summary of my article is “How can we create a community of code from Sun’s Java SE implementation that allows forks and uses an OSI approved license but prevents large players being able to take unfair advantage”. That’s the question that’s not been answered so far and which Sun’s Java team have to resolve.

    Bob: Your “letter” was good PR for you and was strong on “what” but carefully avoided any of the real issues, especially the “forkable but compatible” issue which is the #1 issue for the Java community.

  4. DLJ is rather irrelevant in the big picture. It does not fix most of the problems of the licensing of Sun’s proprietary implementation, so it still relegates Sun’s code to second class status on most GNU/Linux distributions, assuming they bother carrying Sun’s implementation at all. While analysts may consider second class status in Debian to be a huge achievement, in reality, Debian’s non-free repository is where proprietary software like Netscape 4 goes to rest in peace.

    Compatibility is trivial to get right: open up the J2SE compatibility test suite for public access and let everyone be able to verify everyone else’s compatibility claims. That way, redistributors can verify that a runtime works as expected in their specific configuration (kernel, libc, gui libraries, etc.).

    If Sun really cares about compatibility, that’s how to do it.

  5. Dalibor: I agree, that addresses “works-the-same” compatibility, but it does nothing for “no-unfair-advantage” compatibility (see my blog entry linked above for definitions).

  6. I think ‘no-unfair-advantage’ and compatibility don’t have much to do with each other.

    One is an issue of governance & contracts between Sun Microsystems and their licensees/competitors that’s being played out on the (highly intransparent) field of JCP politics, the other is a technical, falsifiable property of an implementation.

    As for ‘no-unfair-advantage’ aspects of governance, I guess J2SE could simply follow the lead of J2EE, where opening up the JCP & givernance process led to a significantly better specification, and implementations.

    Having read Simon’s blog, that talks about Sun caring about avoiding unfair advantage for themselves, I have to stop myself from laughing too hard, though that’s certainly not Simon’s fau;t, as I don’t think he’s well informed on the specifics on Sun’s deceptive behaviour in the J2SE space.

    I’ve personally wasted lots of time trying to track down information Sun was not making available to independent implementors between Java 1.2 and Java 1.5. Sun somehow ‘forgot’ to publish up to date specifications for the Java programming language and the JVM between 2000 and 2005, despite changing both quite a bit. If that’s not unfair advantage for Sun, I don’t know what it is.

  7. Dalibor: Has that unfair advantage you speak of led to an imbalance of the commercial Java marketplace?

  8. Just imagine what might have happened had Sun used the same model as Eclipse — open-source code with license allowing commercially-licensed plugins.

    Sun failed miserably by not opening up the test kit, as this would have defined the standard and would have encouraged developers to submit open tests to ensure that the core did not deviate from accepted practice.


  9. Simon’s comment on “unfair advantage” misses a key point.

    Not taking unfair advantage is key to science. The Caltech Honor Code has sufficed for over a century: “No member of the Caltech community shall take unfair advantage of another member.” The single sentence governed the entire institution when I was an undergrad over forty years ago and still holds true.

    Since open-source is just the use of the scientific method to create effective programs, I have found that open-source developers do NOT take unfair advantage.


Leave a Reply

Your email address will not be published. Required fields are marked *