About Sun ‘Open-Sourcing’ Java

Let’s assume that ‘open-sourcing’ Java means giving others the right to create derivative works as long as they in turn open up the source of the derivative work – the crux of the legalese behind the GNU GPL. If Sun were to do that, then suddenly there is nothing that forces anyone to deal with them. Some enterprising company could just come along with a couple of million dollars, set up a new code fork complete with their own community process for standardization, and suddenly Sun is left out in the cold.

Not convinced? Don’t think that’s a reasonable scenario?

How about Eclipse? The lumbering bureaucracy of the current Java Community Process (JCP) is what caused IBM to start the Eclipse foundation in the first place. In fact, frustration with the JCP is where the project got its name in the first place (get it, ‘Eclipse’, as in ‘Eclipse’ the ‘Sun’). IBM set aside an endowment of a couple million, formed a management committee and a couple of years later we’re looking at the foremost name in Java IDEs.

If Sun open sources Java, they lose one of the few reasons for anyone to deal with Sun at all. Because the Java Language Specification is wide-open, there are already numerous third-party JVM implementations including one by IBM. There are already a couple of different open source Java API library initiatives that are fairly decent, and IBM has already proven that they can support their own Java GUI initiative in the form of the Eclipse SWT. What this is really all about is control of the Java community process and ultimately control over Java’s future. If Sun were to give up control of Java, they’d have to figure out how to both rapidly respond to change and turn a buck at the same time which is something that few companies (with the exception of IBM) are very good at.

So Is Sun likely to acquiesce with IBM’s request to ‘open source’ Java? Not likely. Now maybe if Sun dumped McNealy….