 |
|
 |
 |
|
|
 
Hans Muller's BlogWhy Java is not Open Source: One Cowboy's OpinionPosted by hansmuller on June 26, 2003 at 11:44 AM | Comments (3)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. Bookmark blog post:  del.icio.us  Digg  DZone  Furl  Reddit
CommentsComments are listed in date ascending order (oldest first) | Post Comment
| |
 java.net RSS Feeds
|
