Sun should Open Source unprofitable parts of Java
Apache and the Taligent-derived internationalization technologies developed by Mark Davis' ICU4J team. IBM is talking to Sun about some kind of further Open Sourcing arrangement for Java. Java is openish: it has a community process to guide the development of new libraries, its source code is readily available, it puts out betas for advance feedback, and it has had a bug tracking forum with voting to allow the least popular bugs to be tracked (and, I suppose, to get addressed earlier: nice if everyone really has the same bugs.)
Looks good? but there is also a dynamic at play which keeps some parts of Java in the doldrums, and I don't see that shifting Java over to some IBM/Sun-sponsored consortium would necessarily make much difference. Open Sourcing can only deliver the benefits of 10,000 eyes when feedback and enhancements can be merged back into the code base fast. Any organization dealing with code fixing must prioritize their fixes according to their own lights and capacity. As Joel on Spolksy creepily puts it Fixing bugs is only important when the value of having the bug fixed exceeds the cost of the fixing it.
So Open Sourcing is effective when it allows the people who have the value requirement (the users of the code) to get the code fixed: the owners of the code simply may not have the value requirement, especially for a loss-leader like Java. Shifting all the J2SE holus-bolus from one big organization to another might help broaden the priorities for fixes and enhancements, but that simply is not the game we should be playing. Anyone who has waited for known bug fixes to be folded back into Apache Xerces, say, will sympathize.
It would be better for Sun to look at the parts of Java that do not lead to server-sales or profit, and to farm them off into smaller, separate, focussed, Open Source efforts whose can concentrate on maintaining them. The name of this game is No Resource Contention: the community interested in one library should be able to concentrate on it.
One library that leaps to mind in this is javax.swing.text.html. Arthur van Hoff's great parser class has not changed much since it was created, around 1994: it implements a now-sucky HTML 2 which cannot handle XHTML ( /> empty elements, ઼ hex character references, and so on), let alone HTML 4 or W3C DOMs. Its nice SGML-compliant features have never been developed further, and it has a show-stopping flaw for the modern Web: you are bound to get an encoding exception if you try to feed it with an HTML document as a String in the harmless/typical case where the markup has a meta tag that specifies the MIME Content-Type and encoding.
Of course, this all reflects Sun's earlier priorities, where Java applets run inside browsers; but how I envy Windows programmers, who get to use Internet Explorer as a component when they need it.(In fairness, Sun has not being doing nothing for HTML: the latest 1.4.2_04 release this week has a fix relating to frames, for example. And maybe they will be serious about their recent Java Desktop brand.)
Democracies prevent mass interest from swamping regional requirements by having independent secondary or tertiary tiers (e.g., states or local councils). It is fine to have a senate deciding on JCP, and mass voting deciding on bug priorities, but Java needs an organizational process to farm value from autonomous efforts so that the users are the developers.
Even if Sun prefers to retain control over a stragic asset like Java, it should take a hard look at the components of Java that are related to platform-breadth and market-reach rather than to profitability, and slough these off to small, reactive Open Source efforts. javax.swing.text.html would be a good component to start the experiment with.
Comments on this weblog
1 to 5 of 5
1 to 5 of 5
Return to weblogs.oreilly.com.