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.2) Isn't the Eclipse model a bit too loosely organized to work for a platform as cohesive as Java?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 therein 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?
Community comments
Don't confuse ecosystem governance and implementation governance
by Geir Magnusson Jr,
Re: Don't confuse ecosystem governance and implementation governance
by Mike Milinkovich,
Re: Don't confuse ecosystem governance and implementation governance
by Geir Magnusson Jr,
Re: Don't confuse ecosystem governance and implementation governance
by Mike Milinkovich,
Re: Don't confuse ecosystem governance and implementation governance
by Geir Magnusson Jr,
Don't confuse ecosystem governance and implementation governance
by Geir Magnusson Jr,
Your message is awaiting moderation. Thank you for participating in the discussion.
One of the most confusing things about this whole subject is the conflation of what Sun is actually doing - moving their implementation of Java SE to an open source license and hopefully under an open community governance model - and what they aren't doing - revising the ecosystem governance, the JCP.
The difference is subtle, but important, and tying the two together is confusing.
The beauty of "Java The Ecosystem" is that there can be multiple implementations of any given specification. We have a rich enterprise environment because we have competing implementations - and corresponding innovation - between IBM, BEA, Oracle, SAP, Sun Glassfish, Red Hat JBoss, Geronimo, JOnAS, etc. Sure, Sun has the RI in Glassfish, but that hasn't stopped others from building significant market share in the Java EE server space to the benefit of users due to choice and innovation.
We have a rich SE environment with multiple implementations of Java SE - and appropriate innovation - with Sun, IBM, BEA, Oracle, Apple and now Apache Harmony. Again, Sun has the RI (and unlike EE significant market share), but the implementations that are offered by others are important and useful to users. For example, competition between the implementations in performance has brought significant improvement in the last few years.
In both cases, there hasn't been any real problems with compatibility.
So, yes, Eclipse's governance model may be appropriate for an open source Java SE implementation, and yes, I believe having one open source/open governance implementation that competitors collaborate on as the basis for their own differentiated products is a good thing too. But lets try to be clear that we aren't really talking about the governance of "Java The Ecosystem" quite yet.
Re: Don't confuse ecosystem governance and implementation governance
by Mike Milinkovich,
Your message is awaiting moderation. Thank you for participating in the discussion.
Re: Don't confuse ecosystem governance and implementation governance
by Geir Magnusson Jr,
Your message is awaiting moderation. Thank you for participating in the discussion.
I mostly agree with you :) But the thing I think is important is that we're entering that renaissance anyway. Apache Harmony is moving right along, and Sun is as well. As it's shaping up, they are probably going to be targetted for different communities, and that's very healthy.
Governance of the spec ecosystem is orthogonal to multiple governance models of the various implementations of that spec. That fact that we have this multi-implementation mode is a real credit to Java.
Lets tackle spec governance separately.
geir
Re: Don't confuse ecosystem governance and implementation governance
by Mike Milinkovich,
Your message is awaiting moderation. Thank you for participating in the discussion.
I definitely agree that Apache Harmony is moving right along. I credit its community success with much of Sun's belated movement towards open sourcing Java.
As I said in my original blog post on the topic I am sure you guys would welcome a large code contribution from Sun. On the implementation side (as you characterized it) I believe that would be likely be an excellent move.
I hope that my ideas are not being perceived as any kind of knock on Apache or Harmony, because they are definitely not meant that way. My concern is that the path Sun takes to open sourcing Java might follow their historical pattern.
Re: Don't confuse ecosystem governance and implementation governance
by Geir Magnusson Jr,
Your message is awaiting moderation. Thank you for participating in the discussion.
Re the "knock" - not at all, and I share the worry about history repeating itself.
I brought this up because the Java ecosystem is very different now than it was just a few years ago, due to evolution in governance.
For example, open source implementations of specs are flourishing (when before, they weren't permitted!) while the whole compatibility promise has been preserved. JBoss, Geronimo, JOnAS, Glassfish for the EE platform, Apache Harmony and Sun's implementation for the SE platform (yes, both are still an unfulfilled promise, but I have high hopes for both) as well as "piece-parts" such as GNU Classpath and Kaffe, and countless implementations of non-platform specs such as Apache Tomcat, Apache MyFaces, Apache OpenJPA, Hibernate, etc.
All of this reflects a Java governance model that is vastly different than 2001.
And yes, we'd welcome a large code contribution from Sun at Apache Harmony, and more importantly, participation in the community. We've been saying that since we started. But I also understand that open source (and the governance model you choose) is a means to an end, and Sun probably has different community goals for their project than we do for Apache Harmony. And that's ok - that means choice for users/ISVs/researchers/OSVs, with more opportunities to participate. After all, this is the "Participation Age" :)