Open Source Java advocates comment
In response to my recent Blog on what Open Source Java advocates want, Keith Lea posted a comment that said:
I think it would work perfectly if Sun released something called something vague like "FreeVM" which is simply the JDK, under a BSD license, but not called Java in any way. Then, if you want to release a version of it, you have to submit it to Sun for testing to be able to call it Java. Otherwise it's called FreeVM or whatever the developers want to name it.
The problem with this is that it fails to address the fundamental problem from Sun's perspective - why would Sun want Java technology based on Sun's implementation (which is known to be compatible) to be distributed in an incompatible way, regardless of what it is called? If the answer is to leverage "innovation" of more developers, that assumes that the innovation is of more value than the compatibility. Sun has already determined that the JCP is the way to manage compatible innovations - agree to the standard specification first, then build reference implementations and test suites that allow multiple, compatible implementations of the standard. Is it really the "specify first, then innovate" approach that open source advocates disagree with?
I think it would work perfectly if Sun released something called something vague like "FreeVM" which is simply the JDK, under a BSD license, but not called Java in any way. Then, if you want to release a version of it, you have to submit it to Sun for testing to be able to call it Java. Otherwise it's called FreeVM or whatever the developers want to name it.
The problem with this is that it fails to address the fundamental problem from Sun's perspective - why would Sun want Java technology based on Sun's implementation (which is known to be compatible) to be distributed in an incompatible way, regardless of what it is called? If the answer is to leverage "innovation" of more developers, that assumes that the innovation is of more value than the compatibility. Sun has already determined that the JCP is the way to manage compatible innovations - agree to the standard specification first, then build reference implementations and test suites that allow multiple, compatible implementations of the standard. Is it really the "specify first, then innovate" approach that open source advocates disagree with?
Posted by Keith Lea on March 02, 2005 at 02:02 PM PST #
Posted by Dalibor Topic on March 02, 2005 at 04:20 PM PST #
Posted by Simon Phipps on March 03, 2005 at 03:45 PM PST #
Posted by Keith Lea on March 03, 2005 at 06:18 PM PST #
Keith: I had in mind something like the way MySQL works. The spec lead would work on implementing v6 (vN) as a closed source reference implementation, while an open source community would work on updating their code to reflect v5 (vN-1) specifications. This way the stable open source version would always be of a proven level of the Java platform while the evolving version would be creating the next release.
This way we both have the benefits of "many eyes" making the open source version sound with the benefit of a fully funded (from licensees) reference implementation for the latest and greatest by the spec lead on behalf of the expert group. In this model there would be no need for hostility between the two versions as one would be maintaining the commodity market, probably under GPL so as also to satisfy the Linux world, while the other would be serving the needs of the commercial leading edge.
With both Roxo and Geronimo nearing compatibility the initial open source code bases are there, and in my view it doesn't need to be either/or. Of course, I'm only speaking personally here.
Posted by Simon Phipps on March 05, 2005 at 05:17 PM PST #
Posted by Keith Lea on March 06, 2005 at 05:16 PM PST #
Posted by Simon Phipps on March 07, 2005 at 07:06 AM PST #
Yes - the process is too slow and innovation is too important to wait. The JCP is not agile enough.
The process is tilted too far towards the infighting of major corporations. Innovation does not happen in specification committees. If innovation isn't allowed in the official Java space then it'll just go elsewhere. In the late 90's, Sun understood this, which is why they started down this road all those years ago.
The MySQL (open source, closed community) model has weaknesses. It works ok for old tech (document-centric RESTful stores are where all the cool kids are playing today) but innovation happens elsewhere. This model will lead to atrophication and the JDK's decline into irrelevance. Java would become just the new COBOL.
By freezing alternative implementations out of the process, licensing revenues are traded for influence on the other players in the game. When other implementations start innovating and diverging, that lack of influence will start to tell.
Android has already started pushing changes back upstream. Unless Harmony is allowed access sometime soon, de facto compatibility will matter more than the TCK, leading to a divergent fork. Given the number of Andriod phones that are likely to ship, this is a real threat to Java.
Then there's Linux. The patent threat is the only card the offical JDK has left to play. Sooner or later, a corporation with enough patents and motivation will call the bluff and fork the GPL'd edition. Again, this divergence would represent a real threat.
I never understood why Sun agreed to give away their valuable branding rights in Java to every FOSS implementation that passed the TCK. Sun has already agreed that it's implementation is Free Software with all that this means. It's not clear now what value they really have left in Java.
But it's not too late to cut a deal and take back the brand. FOSS doesn't need it.
Robert Burrell Donkin
- Apache Member, speaking personally -
Posted by Robert Burrell Donkin on May 01, 2009 at 12:38 PM PDT #
It was a very nice idea! Just wanna say thank you for the information you have shared. Just continue writing this kind of post. I will be your loyal reader. Thanks again.
Posted by links of london Sweetie Bracelet on October 20, 2009 at 12:40 AM PDT #