In a move that may make his life easier, Redmonk's Stephen O'Grady has published an interview that he did of himself regarding the issue of open sourcing Java. If he covered all the questions that people have already asked him, and anticipated others, he can forever point to the interview-cum-FAQ instead of carving out another answer with his keyboard every time a question about open sourcing Java comes his way. Sun is a client of Redmonk. So, Stephen presumably has some idea of what Sun is thinking and to some extent, is even influencing that thinking. In asking himself how long it might be until Java is open sourced, Stephen told himself that it would probably be within the next two years. That seems reasonable given that Sun CEO Jonathan Schwartz was on stage at JavaOne a couple of weeks ago saying it was just a question of how, not when.
That is the magic question. Sun has faced this question before. But under different circumstances. As it turns out, open source and DRM are fundamentally incompatible with each other. Prior to open sourcing its Solaris operating system, the answer to the how question was simple. Sun didn't exactly own all the intellectual property in Solaris. Which IP specifically? I don't know. But assuming it involved both copyrights and patents, the bottom line is that if you don't own that IP, not only can't you open source it, you can't indemnify users of it (as Sun has). So, to open source Solaris, Sun had to identify the specific chunks of IP that required a lawyer's attention and went from there. That's "how."
With Java, the how is not so simple. Sun, I believe, has the IP rights it needs to open source Java. It's the compatibility problem that's the major thorn (as O'Grady and others often allude to). Most people don't understand the depth of the problem so here's my attempt at putting it in layman's terms.
There's only one company that makes and distributes Windows XP: Microsoft. For this reason, no matter where Windows XP turns up, you're pretty well assured that if you develop software to run on it, it will be compatible with every system that runs Windows XP. If you're the developer, that sort of compatibility makes it easier to reach your target market. If you're an end-user of that software, then you can be pretty confident about loading it onto all of your Windows XP systems without running into major compatibility problems. Problems do happen. But compatibility is what saves both the developer and the end-user a significant amount of time and money in terms of dealing with them.
In some respects, the Java Runtime Environment (JRE) is very much the same as Windows XP. In other respects, it is different (as operating environments go). Given its popularity, particularly in the server world where the enterprise version of it is quite prevalent, developers and users should be afforded the same benefits of compatibility found in the Windows XP world. Developers need to know that when they develop something to run on a JRE, that it will run on every instance of a JRE out there. Users need to know that when they acquire a solution that's designed to run on a JRE, it will run as advertised on their JRE. But where the JRE is different from Windows XP is in who supplies it. Unlike with Windows, where the only supplier is Microsoft, there are multiple JRE suppliers. In the server world, for example, BEA, IBM, Oracle, JBoss, and Sun all independently develop and provide an enterprise edition of the JRE known as Java Enterprise Edition (JEE, formerly referred to as J2EE).
Imagine a world where there was more than one provider of Windows. Provided all versions of Windows were 100 percent compatible with each other, this sort of multiple provider ecosystem makes it possible for end-users to substitute a new provider in the event that they become dissatisfied with their current one for whatever reasons (cost, performance, security, etc.). Not only are there multiple JRE providers, each JRE provider has the leeway to substitute a JRE heart of their own choosing -- the major functional part of which is known as the Java Virtual Machine (JVM) -- for the one that's provided by Sun, the inventor of Java.
So, you can imagine how, with multiple providers of what's supposed to be the same operating environment each developing their own version of that environment, in some cases, right down to the very heart, how all sorts of opportunities for incompatibilities between the different providers can arise creating a nightmare for developers and end users alike. Sun's big fear is that if Java is open sourced (and for the most part, we're talking about the heart part of Java being open sourced), that such incompatibilities are almost guaranteed to result. That's because with an open source Java, no provider would be obligated to develop or distribute a version that's compatible with those of the other providers.
There is a precedent.
With the different providers of Linux out there, and no oversight over the versions they distribute, compatibility is a very real pain point. While most users of Red Hat Enterprise Linux I've spoken with over the years appear to be happy with their choice, they're also quick to point out that even if they weren't, they couldn't fathom the pain of switching to another distribution (eg: Novell's SuSE Linux). Much the same way switching off of Windows is too painful for some to consider, a similar point of no return exists in the Linux world. The net net is that many Linux shops end up locked-in to an operating system that was supposed to help them get away from such lock-ins. That pain is also mirrored in the compatibility charts of big developers like SAP who, instead of certifying their solutions to simply run on any distribution of Linux, they must certify them to run on specific version numbers of provider-specific distributions (eg: Red Hat Enterprise Linux 4 for x86 version 2.6.9-34.EL [U3]).
To avoid that nightmare and to give developers and end users the same sort of creature comforts of compatibility that can be had with Windows XP, Sun takes responsibility for compatibility from one JRE to the next by putting them through a series of rigorous compatibility tests. If your JRE doesn't pass the test, then your not allowed to associate your solution with the Java brand. Just mentioning the word "Java" in your literature could land you in court (depending on the context). The basic idea is that if a solution can't claim to be a Java solution, then buyers will steer clear of it when searching for Java solutions. And, if a solution legally associates itself with the Java brand, buyers can buy it with confidence that the Java compliant solutions they intend to run on it will indeed run.
Presumably, this compatibility oversight is good. Right? Developers get a lot of assurances. End users experience the flip side of those assurances. Even the different JRE providers should theoretically like the idea of compatibility from one JRE to the next. In an ecosystem where the providers are forced to participate on a level playing field and the end users can actually fathom switching from one provider to another, that equates to opportunity that each provider might not otherwise have. However, in practice, the Java ecosystem hasn't historically worked quite so perfectly.
For example, for the longest time, JBoss couldn't get its open source solutions certified by Sun. It couldn't even afford to pay to have its solutions tested. Nevertheless, end users who were willing to take a chance on compatibility flocked to it. Sun and JBoss (now a part of Red Hat) eventually worked things out to the point that hell practically froze over at the last JavaOne when JBoss CEO Marc Fleury shared the stage with Sun CEO Jonathan Schwartz as though the two were once childhood buddies. They weren't. JBoss' popularity, despite its lack of certification and a a very public and acrimonious relationship between Fleury and Sun, meant Sun had to somehow adapt. And it did.
On the provider side, there was also some dissension among the ranks. While IBM hasn't come out and said that if Sun open sourced Java, the first thing it (IBM) would do is start distributing a version that's incompatible with the rest, the likelihood of that happening is pretty good. Not just because IBM might make changes. But also because other solution providers would too -- essentially increasing the odds that if Sun open sourced Java, we'd end up in the same situation that the Linux ecosystem is in today: for all intents and purposes, forked.
This brings us full circle to the question of how. It's pretty clear from what's been said and written that Sun wants to open source Java, but it wants to somehow do so without sacrificing the compatibility component. In his interview of himself, O'Grady appears unwavering in his stance on the compatibility issue. Citing something he previously published, O'Grady quotes himself as saying:
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."
But then, O'Grady goes on to point to a substantial body of thought leadership coming from all quarters of the blogosphere (including from within Sun) suggesting that open sourcing Java without worrying about governance is the right thing to do. A body of thought leadership that, by the way, dispels the aforementioned myth of Linux forking. O'Grady says he'll admit defeat if and when he must. But, as a long time advocate of standards and the benefits they can bring to end users and developers, I'm with him: I'm having difficulty seeing it. While that softball hangs over the plate to be hit out of the park, it's clear that the "how" question is currently about the governance that O'Grady is talking about.
To listen to those who routinely rip Sun for not open sourcing Java, one might percieve Sun to have stood perfectly still on the issue since the 90's. The truth is that it has been very slowly, if not methodically, preparing for the plunge, testing a variety of approaches, sometimes with other assets (perhaps to play it safe and see what happens). Breaking the logjams with JBoss and ObjectWeb's JOnAS (the other open source JEE solution) come to mind as a step in the right direction. Creating a new open source license (the CDDL) that's actually recombinant with other open source licenses didn't just lay the groundwork for open sourcing Solaris (which it subsequently did), but also for fixing the open source license proliferation problem (which it probably won't , particularly since version 3 of the GPL is clearly marching to the beat of its own drummer).
Perhaps downplaying any connection to open sourcing Java, O'Grady points to the recently inked Distro License for Java (DLJ) and cites the technical issues that it overcomes (echoing what Sun chief open source officer Simon Phipps told me the night the DLJ news went public). But the DLJ very subtly addresses another problem and practically seasons the market (for the day when Java is open sourced) with a resistance point to forking. If, for example, the most important distributions of Linux (ie: Red Hat, SuSE, Debian, Ubuntu, etc.) are pre-wired and optimized to run a Sun-certified JRE (something that the DLJ makes possible), end-users could end up thinking twice before ditching that JRE for another one. Put another way, the result of the DLJ could be an installation base of "compatible Java" that the potential forkers may have to think twice about before forking.
Consider Apache for example. It's open source. It comes with most distributions of Linux. About the only Web server IT shops aren't loathe to replace it with is another version of Apache from the Apache Foundation. Such penetration also greases the wheels for another trend which is already threatening to marginalize the JEE/J2EE crowd (thus further neutralizing the specter of forking): powering enterprise applications with Java, but not necessarily with Java application servers. The idea that application servers could be overkill and there might be a better way was first explained to me three years ago by Cape Clear chairman and CEO Annrai O'Toole. Judging by the discussions I was party to during the downtime and evening hours at this year's JavaOne, the idea clearly has legs, giving birth to other companies that work with (heavy) or without (lightweight) JEE servers when orchestrating business process between service-oriented software components -- companies like LogicBlaze.
If the DLJ theories are a bit of reach for you in terms of how Sun is testing the open source waters, then maybe Sun's Project DReaM along with the Open Media Commons hits closer to home. Sun's Schwartz has a dream that one day, he'll undo the damage to the marketplace that's currently being done by proprietary forms of digital rights management technology such as Apple's FairPlay (damage that I routinely chronicle in this blog). As a means to that end, Sun is willing to contribute its DRM-relevant intellectual property as open source to an open standard that those using proprietary schemes could adopt in the name of greater interoperability between all the services and products that rely on DRM. The setup -- a technology that's seeded with Sun IP and a multi-partry organization (the Open Media Commons) that drives that technology's adoption -- is a virtual repeat of what Sun did with its identity technologies and the Liberty Alliance when it saw Microsoft's proprietary Passport architecture getting traction in the market. But where Sun's approach to DRM is different from the Liberty Alliance initiative is that some form of governance is necessary to do exactly what Sun wants done with an open sourced Java --- to guarantee compatibility.
As it turns out, open source and DRM are fundamentally incompatible with each other. Not technically. But philosophically. Whereas the open source philosophy basically says "here's some code, change it to your heart's content," the idea behind DRM is that the code has to enforce the rights of content rightsholders (eg: a record label) and therefore, it can't be changed to the heart's content of some developer because, in the process of doing so, that developer could end up compromising some rightsholder's rights (essentially neutralizing the DRM function of the DRM software). If the DRM function of the software can be neutralized, then it will be a cold day in hell before rightsholders (again, record labels, movie studios, etc.) will allow their content to be secured by that DRM software the same way they allow their content to be secured by DRM solutions from Apple and Microsoft. So, for Sun, the challenge has been to figure how to open source the DRM code it will be contributing to the Open Media Commons (a move that could spawn a significant amount of adoption and innovation) without giving open source developers the right to fork that code to the point that it could compromise rightsholders rights.
So far, the answer is compatibility governance of open source. Open source developers will have access to the code and are free to do with it what they want, up until a point. Through testing by a qualified a third party, that point will be enforced through governance. If testing and analysis of some open source developer's code reveals that that code could lead to a compromise to rightsholders' rights, then the outcome is rather simple: that software doesn't get the digital keys that it needs to unlock protected content. Open source developers don't like being told what they can and cannot do and the move by Sun has not been very warmly welcomed by the open source community. But Sun is banking on them having a change of heart as they come to realize that in the alternative systems -- the proprietary ones put forth by Apple, Microsoft, CableLabs, and others; the ones getting significant market traction right now -- shut out open source development altogether. To Sun's credit, it is trying to figure out a way to bring open source developers into a DRM world that, as evil as I and others see it, isn't about to go away anytime soon. No other company has tried.
To be clear, open sourcing Java is very different from open sourcing some DRM code. In the case of Java, there wouldn't be some third party content provider holding their content as ransom (like a gun to the developer's head) until the code is proven to be compatible. The Java ecosystem doesn't include that sort of third party leverage. But just the idea that Sun is architecting an open source ecosystem that involves some degree of governance is evidence to me that the company is prepared to entered uncharted waters as it looks for the answer to the "how" question.