An Analysis of Open Sourcing Java
I'm going to try to really tackle the issue of opensourcing Java and
state my opinion of why it's a bad idea. Then I'll propose a way would
could do it without all of the problems. It's a long one but please read to
the end and provide your feedback. This is an issue that many feel strongly
about and has the potential to influence Java's long term future. And as a
career Java developer, it's something that personally concerns me.
Note, I don't want this to become a Microsoft slam. I think they have
made many fine products over the years in addition to some really bad ones
and some very questionable business practices. I do have to respect them
for the fact that they never give up. They keep working on a good idea,
even if it takes five revisions before their product is succesful. In this
post I am only discussing Microsoft's actions in relation to Java. Who
knows, had I been in the shoes of a VP trying to grow the desktop market
(which is hard with 95% penetration) I might have done similar things.
I'd also like to mention that here I use Java and JVM interchangably. I
am more than familiar with the difference between the language, the VM, and
the libs that make up the runtime (and dear god, please don't make me
purposes of this discussion I will consider them all part of what makes up
Java. I think this makes sense for the kind of highlevel issues we are
The Debate: Open Sourcing Java
A lot of people have been talking about the war of words between
related parties on the issue of open sourcing Java. Even href="http://today.java.net/jag/page7.html#62">James Gosling and href="http://developers.slashdot.org/article.pl?sid=04/05/01/1835221&mode=nested&tid=108&tid=126&tid=156">the
Slashdot crew have gotten in on the act. But what would open sourcing
Java actually do? What kind of benefits would we, as a community, get?
As a Java developer, and I'm assuming that most of my audience for this post
is a Java developer, I really don't care about the politics of a license. RMS may
opine that without a free Java you can't implement a completely free desktop, but
I really don't care about an abstract sense of free. I care about what an open source Java
would actually mean, and how it would actually affect me. To me it breaks down like
The Benefits of Open Source Java:
- Multiple eyeballs fix all bugs
- The ability to fork Java if you want to add new features or fix bugs
- The ability to take Java (non-forked) in new directions that Sun wouldn't think of
- Keeping Java alive if Sun tanks
- The ability to make sure no one else can 'take Java away from us', ala Microsoft's embrace
and extend policy
The Problems with Open Source Java:
- Multiple incompatible Javas (both language and environment)
- People from one team not listening to other teams. Standards wars.
- Someone else co-opting the entire system to make it proprietary without a large
company to defend it.
- A monoculture of VMs (which is not incompatible with the idea of multiple VMs)
Now, as a developer, I don't care about competing with the Jones' (.NET,
perl, C) or about the politics of freeness (RMS). I care about making
and deploying great applications, and deploying them everywhere. For
this reason I love the advantages of open sourcing Java. It makes Java
better and lets me play with it. Still, I really hate the disadvantages. #1
on the list is multiple incompatible environments. The current JVM
situation, with multiple revisions and platform specific bugs, is bad
enough. Imagine if there were 10 or 20 JVMs out there each with their own
idea of what "Java" is. Chaos for the developer. I think this is the
number one reason that J2ME has failed. There are too many propriatary
extensions and platform incompatibilities to make it easy (or even
feasible) to develop J2ME software. I'd hate to see that happen on the
desktop or server. That makes my life as a Java developer, (and let's face
it, we are the only ones who really care this passionately about a
programming language), simply hell. In the end we would still need a
validation to ensure that all widely deployed Java environments are
compatible, and we'd basically be where we are now, with Sun's compatibility
tests and control over the spec, only with more fighting and less work getting
So what else do we have here. Multiple eyeballs fix all bugs. Well, you can already
download the source and fix a bug if you want to. You can even submit the fix to Sun.
You just can't get the fix to your users (or the rest of the world) in a timely manner.
This is a problem but one that doesn't require GPL'ing Java. In a world with
Open Source Java we could still have these problems. The only solution is an active
developer team with an interest in accepting feedback. (more on this down below).
Next up, the ability to add custom features. People have been doing that for years
with custom JVMs and compiler extensions. GPLing won't change that. Taking Java
in new directions already happens with the JCP. The process may have some problems
with infighting and general slowness to decide anything, but open sourcing would
mean we'd have even more people bickering about trivial issues. (And if you think that's
bad, trying sitting in on a city council meeting sometime.) This would make the problem
worse, not better.
Next is the issue of Sun going out of business. I think that Java would
be fine without Sun. It's a language, carefully spec'd out, with multiple
implementations from many organizations, some with billions of dollars.
(Hint. It's a TLA). If Sun went out of business tomorrow we'd be fine. I
can't say the same about MFC and Win32.
One really odd issue is the monoculture problem. We could have all JVMs derived
from a common source (and why not since it's freely available, and in fact the GPL
encourages a single source), so one flaw would affect them all. This is the danger
of a monoculture. This is a problem even if we have multiple JVMs with incompatibilites.
Having multiple implementations of a single spec helps prevent this. I like the idea
that a bug in the Windows VM doesn't necessarily affect the OSX one, just as I like
being immune to Outlook viruses by using a different IMAP compatible email client.
Finally, open sourcing, particularly with the GPL, would protect Java
from an embrace and extend attack from a hostile company, which pretty
much means Microsoft. I don't think that it would since they have already
done it twice. The GPL wouldn't have stopped what they did. First was an
incompatible JVM. Lawsuits happen, years pass, MS settles, and the damage
is already done. The GPL wouldn't change this. Second, MS takes the good
ideas of Java and makes their own in the form of C#, adding lots of cool
new research. Again, the GPL wouldn't stop that. No license (or contract, or
law), will stop a determined foe. Only humans with their own interests
can stop other humans. Any license can be powergamed around.
So now we can see that opensourcing Java doesn't solve anything. We have
problems, and I'd like to see some changes in the way that Sun handles things,
but by and large they do a good job and just GPLing it all would
introduce great headaches for very little gain. I urge anyone who thinks otherwise
to submit an opposing analysis. This really is an important issue and I'd like
to have some frank realworld discussions about it.
As a final note (and I'll stop bugging you, I promise) remember that open
source excels at building software where the solution is already known
(like most of the Unix utilities we take for granted. No one wants to
reimplement grep) or where the advantages of customization out weigh the
costs of usability, installation, or integration (like Apache). I think
this may apply to some parts of Java but not to others.
So I have one suggestion: I would like to see Sun partially open source
parts of Java. Development of new standards and specs are pretty well taken
care of by the JCP, but I'd like to see them open up the implementation to
Swing (my personal interest). I want them to basically put the whole thing
into CVS and start taking patches. Make a few Sun employees the architects
and lead product managers. They still make the final decision about what
makes it into an official release (JRE 1.6, 1.7, etc), and non official
releases can't be sold or distributed as Java, but we'd still the
the advantages of faster turnaround, multiple eyeballs, and customized
versions for certain situations. This would sort of be like what happens
with the Win LAF, (a project
created to fix the problems with Swing's built in Windows look and feel),
but more official and with the ability to move Swing along faster. There's
a large community of people who want to make Swing better (and soon).