Open Source Java: Neutral for Vendors, Good for Developers and Great for Sun

The industry has been talking about “open source Java” for many years and it finally happened (Java goes GPL)..

To be honest, I have not been enthusiastic about open sourcing Java. First of all, what does “open source Java” mean? Java source code has been available for many years. What is the additional benefit of putting such source code under an open source license? Secondly, what kind of open source license we are looking for? Thirdly, if Java is open sourced and controlled by a community, how do we prevent fragmentation and incompatibility? Lastly, what are the drivers from both a technology and business perspective to open source Java? Developing and maintaining Java code is a high cost activity – somewhere somebody has to make money to sustain this sport.

After looking at Sun’s announcement a few times, let me first clarify what “open source Java” means – It is not about Java. It is about open sourcing the implementation. The license is GPL V2 license:

1. Java SE: Java HotSpot virtual machine, the Java programming language compiler (javac), and JavaHelp online help software, and JDK.
2. Java ME: Sun is first releasing the source code for Sun’s Java ME Feature Phone implementation based on Connected Limited Device Configuration (CLDC), which currently enables rich mobile data services in more than 1.5 billion handsets, and the source code for the Java ME testing and compatibility kit (TCK) framework. Later this year, Sun will release additional source code for the Advanced Operating System Phone implementation for based on the Connected Device Configuration (CDC) specification and the framework for the Java Device Test Suite.

What does it mean to the community? In my take, it is neutral for vendors, positive for developers and great for Sun.

For developers, the immediate effect is the possibility of having some 5-year old bugs fixed (Java has been suffering from a list of bugs that have been rated high priority by the community but Sun never assigned someone to work on it). Going forward, it is possible that a growing and healthy developer community around world will contribute to this open source effort. -Though it begs the questions that are unclear from Sun’s announcements: Who controls code commit? What is the decision process for code commit?

For vendors, GPL license is a big challenge to deal with. GPL is sometimes called “commercially unfriendly” license because GPL license requires value-add software that is based on GPL code to be licensed under GPL. So the result is that it prevents vendors from leveraging the “open source Java” stack to create proprietary software with proprietary IP. In reality, if a vendor is going to use Java implementation from Sun in a proprietary commercial environment, it is probably better for the vendor to license Java commercially from Sun instead of opening up proprietary code to GPL. So from a vendor perspective, Sun’s “open sourcing Java” does not really bring any benefits – unless it is commericialy friendly licensed. For example, Rod Smith from IBM has been suggesting Sun to use an Apache-like license already (See Sun kicks IBM’s shins ) .

From the perspective of Sun Microsystem, this is a smart move and makes a lot of sense to Sun.

The immediate benefit I see is that possibility of increased commercial licenses from Sun (though it looks counter intuitive). Additional commercial licenses are driven by the two factors:

1. “Open source” branding: customers are more willing to adopt open source products and technologies;
2. The GPL license model: GPL is great for Sun! GPL is challenging for other vendors who are interested building proprietary value-add. For such vendors, it is actually safer to purchase a commercial license from Sun instead of going through the GPL license, which would otherwise force the proprietary value-add to be GPL open sourced as well.

The next benefit is the possibility of reduced cost of building and maintaining the Java software stack. As “the only company who has not made money from Java”, Sun has spent a lot of money on this software stack, which has been freely downloadable for a long time without any direct revenue. -My guess is that the Java software stack has been consuminng over one thousand full time engineers at Sun per year. Overtime, the community can potentially take over some of the work and make it less costly for Sun.

The industry is in transition in general. Web 2.0 is a driving force. Community is a driving force. Open source is another driving force. Open source, in particular, impacts how customers buy products, how developers use product and how vendors do business. Venture investors and smart entrepreneurs are leveraging these forces well. So are some smart vendors. Though a long way to go, I salute Sun for the series of good steps that they have taken in the last 12 months: open sourcing Solaris, supporting x86 and AMD, and now open sourcing Java implementation (Now my remaining hope is that Sun can get their Java software strategy right and be able to leverage Java to build a profitable business).