Skip to main content

Why Java is not Open Source: One Cowboy's Opinion

Posted by hansmuller on June 26, 2003 at 11:44 AM PDT

How many pubs are there in Dublin? Parachute out of a plane over
Dublin blindfolded. After you've landed, walk 10 paces in any
direction without removing the blindfold. There's a 90% chance that
you'll be within earshot of a publican, so order a pint. If the
atmosphere doesn't suit you, just walk 10 more paces in any direction.
You'll either be in another pub or the restroom. Either way, you'll
know what to do.

My week at the GNOME Users and Developers Conference (GUADEC)
concluded with a GNOME Advisory Board meeting. Bradley Kuhn from the
Free Software Foundation (FSF) and I had the inevitable discussion
about free software and Java. From my point of view, if you strip
away the religious arguments and you avoid the legal swamp that
surrounds the licenses that free software is bound to, what motivates
the freedom fighters is a desire for control. It's a not a desire
borne from megalomania, it comes from a more practical source - making
software work. If you only work with free software, then when you
encounter bugs or missing features you can fix them. You can change
the code to suit yourself and you can redistribute it. I was lectured
at some length about the counter example: if your Java application
suffers from problems with the Java Runtime Environment (JRE), than
you must work with Java licensee who provided the JRE to get a fix
produced. You can redistribute the result. You must be patient.

It's interesting to think about what this difference means in terms of
open source software (OSS). The fundamental dynamic with OSS is the
tension between the community that controls the evolution of the
software, and the possibility that a subset of that community might
fork the code. The developer community doesn't want a fork because
that would diminish or even eclipse their accomplishments as well as
reducing the size of their workforce. On the other hand, evolving
stable, working software requires a process that controls if and when
contributions are incorporated. In small OSS projects this control
might be vested in one or two hackers. In larger projects there's
usually a hierarchy of reviewers and "committers" who are trusted to
gatekeep the main code base. It's up to the gatekeepers to maintain
the balance between the stability of the software and the stability of
the community itself. If they fail to do so, the project will fade or
fork.

The dynamics of OSS software are more unpredictable when many
relatively autonomous OSS projects are combined into a large system,
like GNOME or a complete desktop Linux distro. The tension that keeps
the atomic projects together doesn't work as well at the molecular
level. If OSS project B depends on OSS project A, the forces that
ensure that A will continue to sustain B are social and sometimes
commercial. Project A less likely to change in a way that would be
incompatible with the goals of B if the projects have developers in
common or community A views B's success as part of their own.
Similarly, a common commercial interest can help maintain the synergy
between the two projects. But what happens when the two communities
aren't even aware of each other? Similarly, what happens when there's
no social or commercial overlap between the two projects? Commercial
projects are usually loathe to rely exclusively on synchronicity.

Like GNOME, Java is a large system created from independently
developed parts. Java is not an OSS project for a variety of reasons
(some historical), and one of them is the considerable importance of
maintaining compatability across releases for all developers and all
projects. There are three million (and growing) developers that
depend on Java, and the Java platform is itself growing and evolving.
It would not be possible to ensure that this growth and evolution was
realized in Java implementations that were mutually compatible and
backwards compatible with previous versions by relying on the bottom
up guiding force of social and commerical relationships within the
developer community. These forces work exceptionally well within an
individual OSS project and they can be applied to systems based on
integrating many such projects, however their efficacy diminishes as
the size of the development community increases. Here's an example
that illustrates the point.

Five cowboys are sleeping around a campfire. It's cold outside. The
fire dies down and one of them wakes up and throws a few more logs on
the fire. Temperature compatability is maintained and all the cowboys
sleep happily. Three million cowboys live in a city served by a large
hydoelectric plant. It's cold outside. One of them wakes up to find
that his electric boot polisher has failed and, assuming that the
power plant must be the source of his electrical problem, grabs a
monkey wrench and heads for the power plant. While attempting to
dismantle a high current distribution panel he's electrocuted and the
short circuit knocks out power to the entire city. All of the cowboys
catch cold.

I think that one of the primary reasons that Java is not an open
source project is that given the size of the developer community,
forks are unacceptable. In other words the millions of developers who
build software on top of Java value its stability more than they value
the right to get under the hood and fix it.

Related Topics >>