Who Cares About Open-Source Java?

Sun Microsystems has cried wolf a few too many times. Recent word that Sun is planning to open-source Java or some part of it generated a big yawn on my part. I might have been interested a few years ago. But now I say, Who cares?

How many times have they talked about or hinted at plans to do something like this? More than I care to count. Thats just it; I dont care.

Suns attempt to maintain relevance in the business is not exciting me. Ive never understood how Sun has been able to generate so much hype and press all out of proportion to any actual accomplishment—witness last Octobers empty announcement of a "partnership" between Sun and Google. Sheesh.

Now, as JavaOne approaches, were hearing about new efforts around open-sourcing Java. And as much as I tend not to care, a lot of developers certainly do.

Resource Library:

But part of me has to ask what Sun means when it says "open-sourcing."

Some say that if Sun were to sponsor an Apache project it would have tremendous significance, because the company would be finally opening up Java to collaboration and participation by others outside of the JCP (Java Community Process).

However, if by "open-sourcing" the company means sponsoring its own open-source project, with its own licensing and its own community, it does not mean much, since Sun would still exercise control over Java. For this to be meaningful Sun needs to give up control, not just publish the source code.

Java is a killer innovation from Sun, and you cant blame the company for wanting to hold onto it. Yet theyve never been able to monetize it. Now, it seems the one thing theyve been most afraid of—losing control of Java—is the one thing they really need to do to succeed in software. And new CEO Jonathan Schwartz seems poised to do it … or at least to do something.

Click here to read more about recent indications that Sun may open-source some part of Java.

Sun has been considering the pros and cons of open-sourcing Java for several years now. As the owner of the trademark and the primary steward for the platform, Sun has a great deal to gain from retaining some measure of control, and it may gain more in the long term by opening Java up—particularly in the enterprise space.

Java would most benefit from support from other programming platforms, such as PHP, Perl, Python, Ruby and even Mono, if the JVM (Java virtual machine) opened up to become "xVM," said Cameron Purdy, president of Tangosol, a Java-focused software company based in Somerville, Mass. "The move would be an instant win for the Apache Harmony project, and could significantly reshape the meaning of compatibility over time for server hardware heavyweights such as IBM," he said.

An open-source Java would mean that every Linux distribution would be able to ship with a state-of-the-art Java platform. Also, adoption of Java technologies in the open-source world, as with GNOME, for example, would be much improved. And the adoption of Java on the desktop would be further along, developers say.

"The biggest questions are what license to use—and hopefully it would be an Apache-, MIT- or BSD-style license instead of an untenable GPL-style license—and how Sun will realize a return from its investments over [the] long term," Purdy said.

Open-sourcing Java "would be interesting, as it would mean we could fix bugs more easily," said JBoss founder Marc Fleury, in Atlanta. "The evolution of the platform must be under JCP control, however, and the portability of Java ensured by a stringent branding program controlled by Sun," he said. However, "The OSS Java rallying cry is a bit rhetorical."

Meanwhile, Rod Smith, IBMs vice president of emerging technologies, who called for Sun to open-source Java in February 2004 (based on an eWEEK article he read), said he suspects this news may just be a ruse to get more people to come to JavaOne.

Smith said, "To IBM, its kind of late, given the ramp-up of innovations around Ruby or PHP on Web 2.0. Java/J2EE [Java 2 Platform, Enterprise Edition] continues to fall behind. But better late than never."

Next Page: Compatibility issues and innovation.