In an earlier column I opined that Java seemed to be getting too big for JavaSoft to handle. Judging from its recently announced reorganisation plans, Sun Microsystems reached the same conclusion.
Sun intends to do away with JavaSoft and its other independent operating units and replace them with seven divisions built around products, technologies and services.
Combining the software product divisions from the former SunSoft and JavaSoft business units into a single division is a good idea. I'm sure I wasn't the only one confused to find that Java Studio is a SunSoft product, while the Java Web Server is a JavaSoft product. However, I would have preferred that the Java architecture and platform, inclusive of the software developer program, were separate from the development tools and desktop software so it could be more vendor neutral.
JavaSoft's problem was that its mission was no longer as clear-cut as it was when Java was first announced. Since then, Java has gone through several of the stages outlined in the Gartner Curve, which is related to the Technology Adoption Life Cycle from Geoffrey A. Moore's book Crossing the Chasm. Specifically, Java has gone through the Technology Trigger (its initial release), ridden the hype of Inflated Expectations and slammed into the Trough of Disillusionment. It is now digging out of the trough along the Slope of Enlightenment.
JavaSoft's mission was clearest during those initial stages of Java hype and the resultant backlash. But as more firms began to accept Java and use it to develop products, it was not appropriate for JavaSoft to develop competing wares. That's how Microsoft got in trouble: by creating applications based on the operating system it developed. This gave Microsoft an unfair advantage.
Sun's new Java division will be charged with making sure that all implementations of Java labeled as Java-compliant meet certain minimum requirements. Otherwise, we will lose much of the benefit of Java's being more than a programming language. This is already happening with various implementations of Java-like languages and tools, such as Microsoft's Visual J++ 6.0 and Hewlett-Packard's Java Virtual Machine (JVM).
In order to properly guide Java through its Slope of Enlightenment to the final stage, the Plateau of Productivity, Sun should take a clue from Netscape's decision to move its browser from a commercial in-house product to an open-sourced product. In particular, Sun should provide some way to guide the development of "clean-room'' JVMs -- JVMs developed without Sun's source code license, or even without the developer having looked at the source code for a JVM. Just as Netscape set up mozilla.org to guide the further development of its browser, Sun should do the same for Java and JVMs.
Having a single source for non-Sun JVMs would enable more effort to go into improving the quality and performance of those JVMs rather than constantly writing new ones. If Sun doesn't coordinate this effort, you can rest assured some third party will, such as the Java Lobby (www.javalobby.org), a nonprofit organisation that promotes Java as an open standard.
Sun should not be afraid of an open sourcelike setup for Java.
The key lies in figuring out what should be open sourced, or at least managed like an open-source project, and what should be put in the category of money-generating products and services.
The reorganisation is a useful first step, but Sun needs to put more effort into adding checks and balances to its open process if Java is to be saved from the fate of fragmentation that Unix has suffered.