Life at Eclipse

Blogosphere and twittersphere are both abuzz this week as a result of Mikeal Rogers’ “Apache Considered Harmful” post. I thought the article made a number of important points about how the software world is changing, and changing very rapidly. However, I think that follow-on articles such as “Has open source outgrown the Apache Way” are pushing the hypothesis a little too far. It’s one thing to point out the dynamism of GitHub, and the rise of social coding. But stretching that to the assertion that open source foundations no longer have a role is just wrong.

Disclaimer: I run an open source foundation, so obviously I have a vested interest in this debate.

First, I would like to point out that Eclipse is absolutely committed to moving to git as fast as we can get there. We’ve even announced a date by which we intend to shut down our previous standard SCM, CVS. At some point we also intend to discontinue Subversion support for Eclipse projects as well.

Many in the Eclipse community know that I was personally a skeptic about the value of adding git. I was worried that having three SCM systems at Eclipse was too many. In addition to the resources required to support three SCMs, this kind of variety can act as a barrier to entry for both contributors and adopters. If folks have to learn multiple SCMs to interact with Eclipse projects, that is a PITA for them. In short, I was resisting change.

Fortunately, there were many good folks within the Eclipse community that convinced me I was wrong. You know who you are. Thank you.

The argument that ultimately swayed me was that git brings a social dynamic to contribution that the other SCMs we used lack. Adopting git is a strategic attempt by the Eclipse Foundation at social engineering. If we can lower the barrier to contribution at Eclipse, then we will make our community stronger and more innovative. That is ultimately the reason why we’re doing this. This has required investments by our IT team, and as we adopt Gerrit we are modifying our processes for IP management as well. We know that you can both use git and do excellent IP management, because we are already doing exactly that.

Next up is to do more work with GitHub to make it even easier for the broader community to fork Eclipse projects and contribute code back. We are consciously embracing the whirlwind.

I would point out that the model we have at Eclipse where we have a professional staff and some resources at the Foundation makes this kind of change easier to do. Once we’ve made up our mind as a community to push in a new direction, we have the people and the resources to make it happen. We’re not always fast enough to please everyone, but we get there.

But is git and GitHub so powerful a force that the Eclipse Foundation should just roll over and die? I honestly don’t think so. There are some unique values that an open source foundation like Eclipse adds to the equation that are absolutely necessary.

The first thing to understand is that what we are trying to build at Eclipse are not simply open source projects, frameworks or code libraries. Our mission is to ship product-ready software platforms that major corporations and enterprises can safely use and distribute in their products. This involves a level of co-ordination and process that goes far beyond what you can do at GitHub.

A small sampling of the core value-add that happens within the Eclipse Foundation and its community would include:

• IP management. Although we often get criticized for being overly focused on the topic, nobody does IP management better than Eclipse. Which is a huge part of fulfilling our mission of delivering product-ready software platforms. Yes, it’s a lot of work, but it is absolutely a core value, and one not easily replicated.
• Predictability. The Eclipse community has shipped its major platform release on time to the day for eight years. Last year’s release was 46 MLOC, so we are talking about a non-trivial amount of code. The processes that we have in place to co-ordinate the activities and release engineering for 60+ projects absolutely require some amount of centralized support.
• Branding and community. The Eclipse brand means something to people. Millions of developers around the world use Eclipse or Eclipse-based products every day. They have confidence in the software and the community that delivers it. Looking inside the community, there is definitely a pride and a sense of community that comes with being part of Eclipse. Anyone who has ever been to an EclipseCon has seen this firsthand.
• Industry collaboration. Obviously GitHub has been wildly successful in fostering community-led open source. However, there are lots of instances where large and conservative corporations are looking at how to get involved in open source. In many cases, their business motivation is to collaborate with other industry players to create shared industry platforms. The kind of work that goes into facilitating these ventures goes far beyond picking a license and starting to hack some code. The processes that organizations like Eclipse and Apache bring to the table for project incubation, development processes, license management and IP contribution management are critical success factors.

At Eclipse we are trying to simultaneously embrace change, while delivering the core values and processes to fulfill our mission of delivering product-ready software platforms. I feel that overall we are doing a pretty good job, and offer more than enough unique value to sustain us for the very long term.

The last few weeks have seen two great articles discussing the openness and transparency of the Eclipse community. The two reports were completely independent of one another, but both highly valued the open and transparent data we make available about our projects, and the vendor-neutral governance model that helps sustain Eclipse.

The first was a blog post from Matt Aslett at the 451 Group that uses Eclipse to illustrate the strong corporate backing and involvement in open source, while also noting that “…individuals are prominent in many Eclipse projects as well”.

I was particularly happy to see Matt’s recognition of the great work Wayne Beaton has been doing in freshening up our project summary pages (example here) to make it even easier to find information about the past, present and future of each project at Eclipse.

Earlier this week, Vision Mobile published an EU-funded study that gave Eclipse very high marks for its openness. In fact, it rated the Eclipse community as the most open of the eight open source project communities evaluated. You can read a summary of the report on their blog, or download the full report for free in exchange for your email address. You can also read Florian Mueller’s excellent summary on his blog.

I waited to comment on the report until I had a chance to read and digest it. We were obviously very happy to have Eclipse #1, but were frankly surprised that it ranked Eclipse ahead of open source stalwarts such as Linux and Mozilla. As with all such analyses, the methodology determines the outcome. And although I disagree with the approach in a few places, generally I found it consistent and fair. In particular breaking down each community by: access to the code and transparency of decisions, transparency of development, control over the downstream use of the software, and community structure seems pretty reasonable.

I was particularly happy that Vision Mobile’s report also recognized the value of the project summary pages (example here) and of dash.eclipse.org in providing full and transparent information about the projects at Eclipse. The Eclipse Foundation staff and all of the projects put a lot of effort into making all of that valuable information easily available, and it is nice to see that hard work recognized.

We continue to see lots of interest in the Eclipse model of open source development from industry, as you can see from our recent automotive announcement. We truly believe that we have mastered the best practices for openly governed, vendor neutral open source. It is certainly nice to see that recognized in these articles.

I just got home from Germany after a whirlwind trip to join the Eclipse Democamps in Hamburg and Berlin. And now it’s time to head back already. Next week is the Open Forum in Stuttgart, and I have the great honour of joining an all star cast of keynotes including Dr. Willibert Schleuter (Audi), Harald Hönninger (Bosch) and Prof. Dr. Manfred Broy (Technical University Munich).

Open Forum is a new event that came about after successfully co-hosting the Eclipse Embedded Day and SPICE Days Conference in Stuttgart the last two years. The focus of the event is how open source organizational methods need to be adopted by enterprises. Enterprises which are today confronted by the twin challenges of ever-accelerating demands for innovation, and the fact that it is now largely software which is driving brand value and differentiation amongst consumers. Imagine the difficulty those challenges pose to companies which for nearly a century have prided themselves on mechanical and manufacturing excellence. Organizations like Eclipse offer them an interesting proof point that open source methods can be used to deliver high-quality, innovative software on a predictable schedule. As we just recently showed again when we shipped Indigo.

I am looking forward to this event, as it is well outside my normal open source comfort zone. It will be fascinating to talk with a community grappling with how to apply the lessons of open source to the next wave of innovation in industrial methods.

Today’s announcement that Oracle is proposing to move the Hudson project to the Eclipse Foundation is big news. It’s news because of the popularity of the project, its history and, let’s face it, the Hudson/Jenkins fork that happened a few months back.

One of the key issues that split the Hudson/Jenkins community was how to balance the corporate and community aspects of the Hudson project. Kudos to Oracle for continuing to work on these issues and make, what I believe is the right move for Oracle and for the Hudson community.

By moving the Hudson project to the Eclipse Foundation, Hudson will now be operating in a vendor-neutral, transparent, and not-for-profit organization. This means potential contributors will no longer be required to sign an Oracle contribution license agreement to contribute code. In fact, Eclipse allows you to keep the copyright to your code; the code you contribute remains yours, licensed under the Eclipse Public License (EPL). Furthermore, the Hudson trademark will now be owned by the Eclipse Foundation and held in trust for the benefit of the entire community rather than any particular company. So if you’ve been wary of participating in Hudson because of “trust issues”, the Eclipse model of collaborative development should make things a lot easier. Hudson will now be a truly community-based project.

Oracle has certainly taken some lumps for their handling of open source communities, hopefully they will get the kudos they deserve in this case. In particular, I would like to point out the effort that they have put into seeking the collaboration and support of Sonatype, Tasktop, VMware, Intuit and IBM. Eclipse Hudson is showing immediate signs of growth and diversity.

In our view, Hudson is coming to Eclipse for all the right reasons. The Eclipse community is itself a big user of Hudson, and we all look forward to the growth in momentum, innovation and predictability that will result from this move. With the addition of the Eclipse community processes for development, release and intellectual property management, we’re confident that the Hudson community and ecosystem will be thrilled with Hudson as an Eclipse project.

The Hudson project proposal is now available for review. I’d encourage everyone to provide feedback and welcome Hudson into the Eclipse community.