I attended the small event Sun hosted this evening to talk about the next steps towards an open source Java world. On hand for the discussion were Sun Software EVP Rich Green, VP of Developer Programs and Products Laurie Tolman, and VP of Mobile and Embedded Systems Alan Brenner. Dan Farber covers the details well here.
There were generally supportive statements around open sourcing javac and the hotspot VM by the end of year, as well as the JavaME (Mobile Edition). This is all good. The web site to follow for the work is http://community.java.net/jdk/opensource/
The interesting thing to watch here is how Sun works this opportunity as it's sort of backwards. Standards exist to enable multiple implementations. This is certainly how the JCP has functioned, and the Java certification program protects the brand. Open source software describes a licensing model that ensures a collaborative community can be developed around a software project, and Sun has a long history of participation in such communities, including its own, so should be able to develop a new community here.
Historically, standards often arise out of collaborative technology communities, and the shared technology snaps to the standard once created, enabling all the community participants to rapidly develop products. Here, the development community is coming somewhat out of order, behind the specification, but lets set that aside for a moment.
So what will open source Java mean? First remember that this effort has been driven not by Sun, but demanded by the community around Java. Whether the demands are valid or not, or indeed politically motivated or not, there are still good things to be had from the process.
Sun has driven the Java standardization process through the JCP for some time and has a strong collaborative community and process, supported by a strong certification and branding program. (The certification will always protect the brand and expectations of integrity, and Sun needs to finally stop the hand wringing over open source projects "drifting" from the specification. It doesn't happen in the real world, and it won't happen with Java.)
Delivering Java technologies as open source still makes sense, however, even if the standard has led the implementation so to speak.
As a primary reference implementation, it will provide the following benefits to the entire Java community, Sun included:
- It will harden the primary implementation for Sun's and the community's benefit. Allowing others to tinker and explore will find new and interesting problems. They can be addressed.
- It will enable new innovation. Many claim Java's day is done. Allowing new implementors to explore the primary production base will invariably lead to new ideas and innovation on the platform beyond JCP participants, and to everyone's benefit.
- As new code enters the source base, it will likely come in at a very high level of quality. Even if Sun developers act as the primary committers for the foreseeable future, a high level of inspection will be brought into play on code coming in from the outside. For new work delivered from the inside, the inspection will likely be equally vigorous from the community.
That is not to say there won't be challenges. As with any large code base that exists in a commercial product, all will need to be inspected carefully from a number of angles. Sun won't want any obviously embarrassing code released, but as well, they need to ensure all code licensed in from outside can be released, and manage that process.
Sun already supports a strong development community around OpenSolaris, and hopefully that experience can be leveraged by the “OpenJava” team. (Certainly the questions I asked of Sun people tonight indicated the Java folks were absolutely sharing notes with the OpenSolaris community.)
Likewise, Sun already supports a strong collaborative community in the Java Community Process, so they have a great channel to begin their open source efforts when they figure out how they intend to publish what sources.
Perhaps it would be better to contrast this against other similar efforts. Microsoft developed C# and the Common Language Runtime (CLR) of .NET as a product first. The specification for the C# language, and the Common Language Infrastructure (the CLR plus the base class libraries) was then taken through ECMA International, an industry consortium, to develop a standard, and then through the international standards process at ISO.
During the same period as the initial standardization, a team at Microsoft created a shared source project around the standard, aka Rotor, providing what was essentially a reference implementation of the standard by cutting down the product code base to the standard. The project, however, was not open source. It’s license restricts commercial distribution. It was essentially developed to drive academic research.
Neither are changes accepted back from the community around this "Shared Source" project. The code base is still linked to the product code, and Microsoft has concerns about intellectual property taint. It’s unfortunate. One of the first contributions from the outside world, within a day of the initial release of a million lines of code of implementation and test harness, was a fragment of code that improved the just-in-time compiler performance by 10%. It of course couldn’t be accepted. Nor the first robust bug fix the was contributed the next day. The community quickly got the message and stopped contributing.
A second implementation sprang up after the ECMA standard completed. The mono project was started by Ximian as a complete ground-up implementation of the ECMA C#/CLI standard, and distributed as open source software under the GPL. Ximian has been since acquired by Novell.
Microsoft continues to position mono as “an interesting science experiment” in its market commentary, despite its growing success, and to maintain an arm’s length ambiguity about the state and status of non-essential patents that may be infringed by mono.
Instead of encouraging multiple implementations of a standard they instigated, they discourage them. Instead of embracing open source collaborative development, innovation and contribution, they keep the community hobbled.
So Sun has a huge opportunity to “do it right” with Java. They began the release of Java EE 5 with the GlassFish project, and continue the work in the context of a culture shift that has delivered OpenSolaris. Now time will tell if they can harness all their collective experience in open source software, standards, and the JCP to bring about a complete open source Java world.