Opinion: Use an Eclipse-style Governance Model for Open Source Java

When the possibility of open source Java was announced recently, Laurie Tolson, Sun's vice president of developer products and programs said "On the governance side people want an easy way to contribute and interact. We are looking at the Apache, Linux, Solaris and other governance models..." 

Analyzing the implications, Java Eclipse Foundation Executive Director Mike Milinkovich blogged about how using CDDL and an all-Sun governance model would be a terrible idea. Instead, Mike suggests that a way for Java to be truly free and independent would be to use an Eclipse-style governance model. InfoQ sat down with Milinkovich to futher discuss the idea of an Eclipse governance model for Java and its implcations.

1) You mentioned an Eclipse style model might work for open sourcing Java, how so?

I need to preface all of these comments with an initial thought. Let's all remember that Sun owns the Java intellectual property. Whatever they do is clearly their decision and we all need to respect that. My opinions are from one who has an interest in ensuring the long-term success of Java. But unlike Sun Microsystem's officers, I do not have a fiduciary responsibility to maximize SUNW's shareholder's value. So there is a whole set of constraints that I don't need to be concerned about that are going to be very important to Sun's management.

That said, the great thing about Eclipse is that it provides an open and transparent place for individuals and companies to collaborate on building open source platforms. The key factor that has encouraged so many companies to become involved in Eclipse projects --- and there are over 45 companies now participating in Eclipse projects --- is that it is a completely level playing field. Every single company participates under exactly the same rules of engagement.

To be clear, I am not advocating that Sun bring Java to Eclipse. But the Eclipse style of independent, open governance is in my mind perfectly suited for reinvigorating both the commercial and developer ecosystems that have made Java so successful.

It depends what you mean. In my mind there needs to be two distinct processes surrounding Java. The one everyone is already familiar with today is the process of specifying those pieces of Java which are ready for standardization. A rigourously defined and managed specification process with freely available TCKs will be key to Java's continued success. That said, I do believe that the JCP needs to be more open. From a governance point of view it should be more independent. From a transparency point of view, I believe the value of confidential expert groups expired several years ago.

On the implementation side, the Eclipse model would work great. Eclipse, Apache and others have shown time and again that open source communities can build great implementations of specifications. I have no hesitation in saying that either would provide an organizational model for future open source implementations of Java.

3) Who would call the shots for Java with an Eclipse style model?

That's the whole point. There would not be a single point of control any more. On the specification side, an "OpenJCP" would call the shots. On the implementation side the meritocracy created by the committer population would drive the projects. Apache Harmony is aleady showing that can work for a JSE implementation. And Eclipse has shown that it can be successful for any number of interesting and innovative Java-based projects. In addition, Eclipse-style architecture and planning councils could be helpful, but that would really depend on what level of inter-project co-ordination was required.

So in my rich fantasy life we have a specification organization that builds specs and TCKs under open source rules of engagement. And instead of mostly lame RI's, we have an open source community to build quality implementations freely available to all. Both organizations should be demonstratably independent and openly governed. The Java label should only be used by implementations that pass the TCKs.

4) What might be some of the risks?

When I look at Java today I think that the status quo is the biggest risk of all. Unless Java becomes truly independent, the energies of all the individuals and companies who like Java but are unhappy with Sun's control of it will eventually go elsewhere. The energy and enthusiasm that was there

in the late '90's is dissipating. Either something bold is done to reinvigorate it or we will watch that energy go to new languages and platforms.

5) How do you feel about the balance between JCP oversight and keeping the development process of a project nimble in general? Do you see a need to adjust the current balance as Java is moved to be open source?

Standardization is all about investment protection for the consumers of technology. It is critical that a functioning standards process for emerging Java technologies be there.

That said, I have always believed that the attempt to mix innovation and standardization in the same time and place is just plain dumb. Innovation in Java does not happen at the JCP. It happens at places like Eclipse, ObjectWeb and Apache. A far better process would be to take open source projects that have demonstrated success and adoption and take their APIs to an "OpenJCP" to harden them into specifications. Instead, what we have today is a process where JSRs get started to compete with open source projects once they get too successful.

Eclipse and Apache both have incubator processes which have proven to be successful in helping new projects get off the ground. That's how to get new ideas implemented. After they're implemented and gone through real user adoption then they're ready for standardization. Think of it as a funnel where not every innovation will make it to standardization. But if you don't accept the some risk of failure then you can't innovate.

So I guess the answer is don't even try to be nimble in the JCP. Standards setting and specification writing are not nimble activities. Instead, let's have a well defined process for taking already proven technologies and make them stable specifications.

What do you think about this idea? Would an Eclipse-style model be appropriate for an open source Java?