Friday August 18, 2006 Why Bother Open Sourcing Java?
I was making a serious point on Tuesday when I commented that the number of developers interested in the source code to Sun's Java SE implementation would be quite small (I guessed in the low hundreds). OSDir may make fun of it and C|Net rather miss the mark too, but Neil Ward-Dutton, who asked the question I was answering, has a better understanding of the matter but still misses the heart of the matter. That's not to say that monetisation at the point of value isn't crucial for Sun, but the Java platform is more a market-maker than a direct revenue generator.
All that the 4 million plus developers of applications on the Java platform really care about is that there's a full Java implementation everywhere they see the Java logo, which works the same as all others and includes all the class files their application needs. I call this "works-the-same compatibility", and it has always been the core value of the Java platform. It allows you to upgrade the operating system without breaking the applications. With a little care, it allows you to have one application and target multiple platforms.
Almost none of those 4 million plus developers will ever want to join in with any activity that's maintaining the internals of the Java platform. As Alan notes, the only regard most Java developers will have for open source Java implementations is a fear of incompatible forks (and I remember your concerns from TSS in Spain, Kirk).
But there will be some who are interested. There has already been enough interest for 30 or so developers to collaborate on GNU/Classpath, and there's another group (dominated by IBM and Intel) working on Apache Harmony. I'd guess that as many as 400 people could eventually form a core developer community around an open source code base sparked by Sun's implementation.
So why do something that, if it works, goes unnoticed by the 4 million? It's not just for the 400. I'm keen to ensure that the Java platform finally finds its place at the heart of the Free software movement, but to do that it needs to be released under Free license. While there are people who assert that requirement for ideological reasons, there are a much greater number who do so for purely pragmatic reasons. Developers aren't lawyers, and they mostly don't want to hire lawyers either, so the only license terms they'll accept are ones that have been vetted by an authority they trust. Without an OSI-approved license, the cost of including software in an operating system is just too much. So they won't.
Now, the Java platform makes perfect sense in a world of free operating systems (and I disagree profoundly with Scott Handy's assertion that the world only needs one - I am running four different Free operating systems here as I type). It allows the developer to work independently of the platform, insulated from different distributions, different versions and even different CPU architectures. It means you can choose the perfect operating system for the job, yet still use the same application.
While the actual code-base will only be touched by the 400, the 4 million will benefit from the extended deployment range, the greater pool of expertise and the greater diversity of interests that will result (and I firmly believe, again unlike Scott Handy, that opening the source is essential). Open sourcing Sun's Java implementations is hard, has risks and affects only the 400 now, but it will quickly grow benefits that the 4 million will reap. That's the motivation - preparing for the world where, as I've said elsewhere, the network is the computer, and open source is its soul.
Comments are closed for this entry.
Posted by Jonathan Schwartz on August 18, 2006 at 07:41 PM PDT #
It is actually a bit bigger than that. There are around 40 active developers (who contribute each and every month) and the FSF has papers on file for more than 120 individuals and organisations/companies helping out (and this doesn't include people with onliner fixes, bug reporters, etc). It really is a wonderful group of people. But that is just the core library hackers.
GNU Classpath really is a community of communities working on various offsprings like compilers, tools, runtimes, for research or commercial products, people who package it all for the smaller and larger GNU/Linux distributions, etc. They all work together to create the greater whole. And precisely as you say because they can and are allowed and because the simple free software license enables them to work together without "legal friction".
It would be wonderful to see if we can somehow merge this community of communities with your proposed Sun Libre Java community. I know many of us would be very happy to see that happen. We worked all this years very hard not to be different, but because we wanted the right to be different and innovative. Because we are passionate about this stuff, just like some of the Sun engineers are. For the ideological and pragmatic reasons you mention we had to create our own movement that had all the freedoms we needed to be effective and innovative. Now that you seem to want to embrace these reasons inside Sun I can see our movements merge in the long run. There are some small conditions to make this easy (like having a gpl-compatible license). And it won't be an easy or quick process. But I do hope it will happen in the end if you will allow our groups to mingle freely. It would create an insanely great platform and community.
Posted by Mark Wielaard on August 19, 2006 at 12:46 PM PDT #
The size of the community working on an open-source Java does not really matter. The real thing that matters is that by not being free (as in license, not cost), Java has missed out being a real part of the free and open source operating systems such as Linux or the various versions of BSD Unix.
Linux desktop applications, for example, could really have used features present (or easily created) in a language like Java. Heck, Class.forName("foo").newInstance() alone would have made it trivial to create plug-in architectures for the major desktop environments. I would much rather do this than try to load dynamic shared objects from C. And, Java would have gained by increased pressure to make its desktop APIs better.
If you were writing the GNOME or KDE desktops, think of how much faster you could have written the software it using a language such as Java. Think of the smaller number of libraries that would need to be created. Think of the easier cross-platform packaging. It would have been really cool if Sun's Java Desktop system had actually been written in, well, Java. In this era of concern for security especially in business environments, consider a full desktop application stack written in a language with security features built in, running as managed code, on say, OpenSolaris.
As proof of this, look at how quickly we are getting great applications created using a modern language running on a bytecode-based managed system. The only problem is that these applications are being written in C# on Mono.
In addition, writing any kind of application, server, desktop, or whatever, in Java certainly makes it far easier to port the application to other platforms. That makes OpenSolaris more relevant.
Java not being free also hindered Java usage on so-called "minor" platforms such as BSD Unix. The great efforts of the Blackdown organization have provided Java runtimes for those platforms, but not for a long time.
It may be too late for an open-source Java to make a difference. That's too bad. The issue has always been removing barriers, not active development.
Posted by Eric Foster-Johnson on August 21, 2006 at 07:12 AM PDT #