InfoQ

News

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

Posted by Floyd Marinescu on Oct 16, 2006 10:03 AM

Community
Java
Topics
Governance ,
Open Source
Tags
Java SE ,
Eclipse

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.

2) Isn't the Eclipse model a bit too loosely organized to work for a platform as cohesive as Java?

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?

  • This article is part of a featured topic series on Governance

Related Sponsor

Visit SOA Appliance Comparison Site
*Video Usage Model Tutorials
*Comparison to IBM DataPower X150
*Performance Benchmarks
*On-demand webinars

5 comments

Watch Thread Reply

Don't confuse ecosystem governance and implementation governance by Geir Magnusson Jr Posted Oct 16, 2006 11:28 AM
Re: Don't confuse ecosystem governance and implementation governance by Mike Milinkovich Posted Oct 16, 2006 1:55 PM
Re: Don't confuse ecosystem governance and implementation governance by Geir Magnusson Jr Posted Oct 19, 2006 12:25 PM
Re: Don't confuse ecosystem governance and implementation governance by Mike Milinkovich Posted Oct 22, 2006 5:36 PM
Re: Don't confuse ecosystem governance and implementation governance by Geir Magnusson Jr Posted Oct 26, 2006 4:42 AM
Sort by date descending

  1. Back to top

    Don't confuse ecosystem governance and implementation governance

    Oct 16, 2006 11:28 AM by Geir Magnusson Jr

    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.

    Reply

  2. Back to top

    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.
    Hmmm. I mostly agree with you. The point that I'm making is that simply doing one without the other is not going to lead us to a happy place. Governance matters. Simply open sourcing Java under the CDDL and having an OpenOffice-style-Sun-only governance model isn't going to do much for sparking the renaissance in Java that it needs.

    Reply

  3. Back to top

    Hmmm. I mostly agree with you. The point that I'm making is that simply doing one without the other is not going to lead us to a happy place. Governance matters. Simply open sourcing Java under the CDDL and having an OpenOffice-style-Sun-only governance model isn't going to do much for sparking the renaissance in Java that it needs.
    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

    Reply

  4. Back to top

    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.

    Reply

  5. Back to top

    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 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" :)

    Reply

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

  •  Jul 02, 2009,
  •  

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

  •  Jul 01, 2009,
  •  

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

  •  Jun 30, 2009,
  •  

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

  •  Jun 30, 2009,
  •  

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.