Open Source -- Then and Now: A Conversation With Ray Gans of the OpenJDK Community Program

Interviews Index

Few have been closer to the day-to-day processes involved in open sourcing the Java Platform, Standard Edition (Java SE) than Ray Gans, a manager at Sun Microsystems with a long history of working with Java compatibility programs. He currently manages the OpenJDK and Mobile & Embedded community programs, where he works to improve the collaboration between Sun and the open-source Java developer community. We met with him to gain a better understanding of how the open sourcing of the Java SE platform is going and where it is headed.

Tell us about your history at Sun working on Java compatibility issues.

In 1997, Sun hired me to work on the 100% Pure Java program, which allowed application developers to verify that their applications used no proprietary APIs and were written to be as portable as possible between Java runtimes from different vendors. From there, I moved to the compatibility testing groups that work on Technology Compatibility Kits (TCKs), comprised of compatibility requirements and test suites. TCKs are used to verify that an implementation of Java technology actually meets the specification.

As part of this effort, I worked with the European Digital Video Broadcasting (DVB) standards group, an organization of cross-European TV and technology professionals that incorporated Java technology into the design of their Multimedia Home Platform (MHP), an open middleware specification for TV set-top boxes. As a member of the MHP Experts Group, I helped define the compatibility testing policies and process for MHP.

My entry into open source began when I took over program management to begin the JDK community on java.net in 2004. While this wasn't open source, we made JDK source code available to the developer community and allowed them to engage in research, make enhancements, fix bugs, submit bug reports, and discuss the code with Sun in a manner similar to many open-source communities. The code was released under the Java Research License (JRL), which is not an open-source license but a permissive license that allows developers to do pretty much what they want with the code, as long as they do not distribute it to non-JRL licensees.

We built the JDK community of projects -- now known as the OpenJDK community -- in March of 2005, where other projects associated with the JDK could do research.

That community was very important to Sun's implementation of JDK 6 through the JDK 6 project. We received more than 500 contributed fixes and loads of bug reports. After publishing weekly builds starting in November 2004, we received far more feedback than we would have gotten from typical beta programs, resulting in a higher-quality release of JDK 6 in December 2006.

We learned a lot about the needs of the community through these projects and made contact with many people in the free and open-source world who wanted us to go further. So when we announced in May of 2006 that we were open sourcing the technology, we had a good idea of how to begin, which brings me to my current role as manager of the OpenJDK community program.

Can you recall what you felt when you first heard that Sun was open sourcing the platform?

I was in the audience at the 2006 JavaOne conference keynote when Jonathan Schwartz made the announcement. I was sitting next to Rich Sands, who's my marketing counterpart in community work and now OpenJDK. We looked at each other, smiled, and said, "We're going to be very, very busy this next year." We were not expecting the announcement, but both of us were really excited by the news.

"Sun is not an open-source foundation having no commercial interests such as Apache or Eclipse. We're a corporation that needs to present a comfortable working environment in which non-Sun people feel they count and their voice will be heard."     Ray Gans Manager of the OpenJDK Community Program for Java SE, Sun Microsystems

In November 2006, when James Gosling was asked what kept him up nights about open sourcing the platform, he said that he wasn't worried that it would become less reliable, but he might lose sleep over "the mechanics of the infrastructure: the hosting, the bug tracking, the day-to-day bits and picture -- things that all open-source projects go through." How's it going today, eight months later?

We've also had many concerns related to what James said -- the mechanics and infrastructure need to appeal to people. Sun is not an open-source foundation having no commercial interests such as Apache or Eclipse. We're a corporation that needs to present a comfortable working environment in which non-Sun people feel they count and their voice will be heard. We don't want them to feel as though they're dealing with a big corporation that will make all the decisions, do whatever it wants, and ignore the community.

So we need to foster an environment in which participants' code is published, their bug reports are dealt with effectively, and they can have a free and interesting exchange of ideas with Sun engineers and non-Sun engineers. As we've said from the beginning, we won't be able to get it done all at once -- it will evolve over time.

So far, the OpenJDK project seems to be working well. It has an interim governance policy that allows developers to look at the source code, play around with it, provide contributions, start projects, report bugs, and so on. So far, the infrastructure is running smoothly, but we're just beginning. We've opened up internal mailing lists to the external community so people can see what folks are talking about and participate if they'd like. We believe such transparency is important to developers who want to know what's going on and how to contribute.

What does your experience at the 2007 JavaOne conference tell you about the response of developers to open sourcing the platform?

Reactions ran from mild interest to wildly enthusiastic, though everyone I talked to thought open source was good for the platform.

I suppose this range of reactions is understandable since most developers have little interest in changing the platform itself, but almost all are concerned about the state of the platform and its future. I think our announcement hit the right mark since open source strengthens the platform by inviting more people to participate in its evolution while retaining the TCK and the JCP (Java Community Process program) so that developers can remain confident that the platform will not fragment or become bloated with poorly designed new APIs.

"A significant cultural change is occurring within Sun. Engineers who once worked solely with their internal teams are now encouraged to work with people outside of Sun and listen to their ideas."     Ray Gans Manager of the OpenJDK Community Program for Java SE, Sun Microsystems

What, if anything, has surprised you the most about this process?

I'm surprised by something every day! The biggest challenge is getting our hearts and minds around open source and understanding how it affects the way we do business at Sun on a daily basis.

A significant cultural change is occurring within Sun. Engineers who once worked solely with their internal teams are now encouraged to work with people outside of Sun and listen to their ideas. I've noticed in other large open-source groups at Sun, such as the OpenSolaris group and the GlassFish group, that this cultural change takes a while to occur. Some people need to learn to communicate more effectively and manage their time so that they can work both with the community and on their Sun tasks and assignments, while others jump right in and are very effective on day one.

Sun is part of the free and open-source Java community now. We've started as the bulk of the OpenJDK community participants, but over time, I fully expect many more developers to join us to build a community of people both inside and outside of Sun who work closely together in OpenJDK.

Can you address the biggest concerns that Java developers have about open source?

There are four main concerns that I hear from developers: licensing issues, the availability of implementations, the dangers of fragmentation, and how the compatibility tests -- the JCK (the Java Compatibility Kit or the TCK for Java SE) -- will be made available to the OpenJDK community.

There will probably always be concerns about licensing. We've chosen version 2 of the General Public License (GPL) for OpenJDK, which we think will help eliminate proprietary forks of the code due to its strong copyleft provisions.

We've also added an exception to the license, which we're calling the Classpath exception after the GNU Classpath Project, which uses the same exception. This allows one to bundle OpenJDK code with an application, but it does not usually force the application to be open sourced under GPL. So if you want to keep your application proprietary, you can still bundle it with the OpenJDK Java runtime and not have contamination problems.

Second, in addition to open-sourcing the technology, Sun will continue to distribute our current production implementations of the JDK based on the same code. This means the commercial, non-open-source implementations that developers use today will be available and will probably remain Sun's primary distribution of Java SE technology in binary form for the foreseeable future. We plan to make sure that the open-source and non-open-source versions are as close as possible to each other, so that -- whichever one you choose -- you'll have an equivalent experience.

Open-source Java SE provides an opportunity for those who are unwilling to use a non-open-source implementation or want to have an escape valve or safety net to protect themselves from getting locked in to a particular vendor.

Also, those end users and developers who choose to continue with the Sun production implementation of the JDK can rest assured that there's an equivalent free and open-source implementation available if they ever need it.

A third issue is the risk of fragmentation, the primary reason Sun didn't open source the JDK in the past. Fragmentation could seriously damage one of Java technology's best features, the ability to move applications from one implementation to another with ease. This "Write Once, Run Anywhere" feature of Java applications could be seriously compromised if competing but different-behaving implementations of Java SE became widely used and distributed.

"There are four main concerns that I hear from developers: licensing issues, the availability of implementations, the dangers of fragmentation, and how the compatibility tests -- the JCK -- will be made available to the OpenJDK community."     Ray Gans Manager of the OpenJDK Community Program for Java SE, Sun Microsystems

Yet we now know that the free and open-source community also sees the benefits of one Java platform. Some developers may want to see it changed in various ways, but in general, no one benefits from multiple variants of the technology. Sun now believes that if we build an environment that is conducive to collaboration, people will want to work together to build one Java platform.

Don't get me wrong. Forks aren't necessarily bad -- in fact, we expect offshoots and forks to provide interesting opportunities for research and new implementations. If what comes out is appropriate and desirable, then the OpenJDK community would work with that fork and reunite at some point.

A fourth issue related to OpenJDK and the GPL has to do with how the compatibility requirements and tests -- the JCK -- will be made available to the OpenJDK community. The good news is that Sun will provide the JCK for OpenJDK-based distributions and developers who need access to it. We're still working out the final licensing terms, but that should be ready soon. For people who want to start from code bases other than OpenJDK, Sun's existing TCK licenses and associated scholarship program for qualified not-for-profits will remain in place.

Are a good number of developers collaborating on the OpenJDK code base and related projects?

We've only recently open sourced the bulk of the platform, so it's hard to answer this. There is quite a bit of buzz in the industry about OpenJDK. Currently, developers are downloading the code and playing around with it, trying to build the runtime.

Sun's Java compiler, javac, and the Java HotSpot virtual machine code were made available in November 2006 and have generated a lot of interest since then. The HotSpot VM is a fairly tricky piece of code, so it's taking a while for people to get their hands around it. We've had a lot of discussions about the compiler and have set up the Kitchen Sink Language project to allow people to play around with new compiler language features as a form of research.

What will Sun do about so-called encumbrances -- the code that Sun doesn't own or have the right to release as open source?

A number of developers inside and outside Sun are working now to remove encumbrances from OpenJDK. I expect this will be the focus of much of the effort during the next few months. All of us want a completely free and open-source implementation of OpenJDK.

We've released "binary plugs" for code that Sun is not permitted to distribute as source, which give developers the ability, when building the JDK, to actually use these binaries instead of compiling the source themselves. This allows the entire JDK to be built and run.

We hope that the community of developers will help us resolve these encumbrances as quickly as possible and replace the binary plugs with equivalent code that can be made available. Until we have them all replaced, we won't have a fully free and open-source JDK.

Tell us about JDK 7.

We released code for JDK 7 in May 2007. New development of JDK 7 will occur through the OpenJDK project. Sun is working on transitioning its source control management system to Mercurial for OpenJDK. Until that's completed, we have to update OpenJDK manually from our internal systems. This transition will be expanded over the coming months to improve bug tracking and expose other internal Sun tools to make the development process more participatory and transparent.

What impact does open source have on the JCP program?

We currently have a JSR -- Java Specification Request 306 -- which is a change to the JCP and the JSPA, the Java Specification Participation Agreement, that will make some adjustments to the way the JCP works.

We need to look more closely at how free and open-source development fits into evolving specifications and technologies through the JCP. Although there are many examples of doing a JSR in the open, it's often more awkward than it should or could be. So we're investigating ways to make the JCP more open-source friendly. Hopefully, we'll see some changes in the coming months.

Do you have any closing thoughts?

I encourage developers to check out the OpenJDK project site, download the source, and participate in the discussions. Tell us what we're doing right and what we're doing wrong. Give us ideas. We're very interested in what you think. Let us and the rest of the developer community know what it will take to get you more excited about Java technology.

We're looking for people who are as passionate about the technology as we are. If you're one of those people, then we want to get to know you.

OpenJDK
Mobile & Embedded Community
OpenJDK: Now the Journey Starts for the Community
Sun Open-Source FAQs
Java.net
Open Source at the 2007 JavaOne Conference
MHP Experts Group
Wikipedia on Copyleft
GNU General Public License (GPL), Version 2