tecosystems

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.