Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

This Week’s Announcements

Hearty congratulations are due to Microsoft, Soyatec and Tasktop for their announcements yesterday regarding Eclipse and Silverlight, Azure and Windows 7. It is great to see Microsoft providing support to the ecosystem to ensure Eclipse remains a great development environment for the Windows platform (which still represents almost 80% of our users on any given day).

Much of this progress results from work led by Vijay Rajagopalan, a Principal Architect in the Interoperability Technical Strategy team at Microsoft. Vijay has been working closely with the Eclipse Foundation since just before EclipseCon 2009 and we’re very happy with the progress we’ve made.

Collaboration Is Just Good Business

Last week at the Open World Forum, I had the pleasure of attending Michael Tiemann’s talk on the “Road to the Digital Recovery”. Michael kindly summarized his key points on his blog.

The most interesting sound bite from Michael’s talk was his estimate that $1 trillion is wasted every year in ICT spending. His logic is:

…18% of all applications are abandoned before ever reaching production, 55% are “challenged”, meaning they are either late, missing key functionality, buggy, or some combination of the three that results in measurably degraded performance. Back when this study was done, the scope of the analysis concluded that $78B/year was being wasted by US CIOs on “bad software”, but that is the tip of the tip of the iceberg: with global ICT spending over $3.4T USD in 2008, money wasted on “bad software” now exceeds $1T USD per year.

I actually think that the reality is worse. Much worse.

Michael’s conclusion is based on the number of projects which fail to accomplish or only partially accomplish their stated objectives. Everyone in the software industry knows that these types of failures are a simple fact of doing business-as-usual. The proposed solution is to lower the percentage of complete or partial failures by improving the quality of the software being built through using open source processes and techniques.

While I have no disagreement with that conclusion, I think that it is missing a huge part of the problem, which is that we all collectively waste massive amounts of human and commercial capital by building too much software. The sheer amount of wastefully duplicated effort endemic to the ICT industry is staggering.

Note that I am not referring to the software which provides companies any source of competitive advantage. I am referring to the software infrastructure which every company needs to merely operate in their particular industry. In every single industry you will always find some amount of software required by 100% of the players, for which 0% get any sustainable or even measurable competitive differentiation.

For one example, imagine the scenario where a new government regulation in the (say) insurance industry requires all of the companies in that industry within that jurisdiction to implement a new set of procedures. Pretend that there are 30 companies impacted. Even if the implementation project within each of those 30 companies was executed flawlessly, the wastage is 30x, because none of those companies achieved any customer differentiating value from their efforts. Multiply this scenario across all of the companies in all of the industries and the wastage of human effort, skill and imagination is depressing.

In my view, the future impact of open source on the ICT industry is not simply to make software better quality. It is to reduce the amount of wasteful effort squandered on implementing and re-implementing and re-implementing yet again the same bags of stuff that our current corporately-silo’d development structures require.

Open source communities such as Eclipse, Apache, Linux, et al offer enormous potential cost savings to industry. By establishing the licensing, IP management, governance and development processes to enable cross-company collaboration, these communities open the possibility that much of the “operating systems” of various industries could be built and shared. This will require some cultural shifts, but I predict that the business and economic rationale will inevitably drive companies in this direction.

Kudos

I just received an email out of the blue that really reminded me of how important it is for all of us in the Eclipse community to help our users and adopters.

I just wanted to express my appreciation for the help Scott and the ECF team have been providing me as I explore using features of the EquinoxRT. Some of my questions have been off the beaten path (unicast/WAN bonjour discovery of update urls etc.) and these guys always knew where to point me - and in some cases had existing code samples. What surprised me was how quickly they responded (like in minutes) to my questions.

The success of our projects and community is not just about writing the code. It’s about engaging the community and seeing the technology become successfully used in action. So congratulations to Scott Lewis and the ECF team. Very nicely done indeed!

This also reminded me about how important a heartfelt “atta boy” can be to a team. If you’re reading this and you have been helped by an Eclipse committer, project, or staff member please remember to say “thanks”! It is certainly appreciated.

Differentiating Communities

I was asked earlier today if I could describe “…the Eclipse community and its differences between other traditional commercial open source communities say like Sugar’s and non, or less pure commercial communities like Apache.

Darn good question. Off the top of my head here are a couple of key differentiating points. I would certainly be interested in hearing the views and comments of others. Both from Eclipse and from other communities.

  • I actually don’t think of the likes of Sugar or MySQL as “traditional” open source communities. I think of them as corporately owned communities. Yes, there are vibrant communities there, but the intellectual property is owned by a single vendor backed by investors with an expectation that a profit will be made and that an exit will be had.
  • Communities such as Linux, Apache and Eclipse are distinctive in that they are either not-for-profit or non-profit and have a legal requirement to be vendor-neutral and a community requirement to respect the principles of openness, transparency and meritocracy. They are not motivated by their own profit, but are motivated to see the businesses of their stakeholders be profitable. As such, they are trusted agents at the centre of the business ecosystems that they create, in ways that a for-profit vendor could never be.

Eclipse is differentiated from Apache in many ways. But here are a few to think about:

  • First, our interests in creating a commercially profitable ecosystem are more overt. Obviously, there is a very vibrant ecosystem that has sprung up around many of the Apache projects and the Apache folks are happy about it. But at Eclipse it is a stated directive for the staff of the Foundation to help foster that commercial success, rather than a side effect. We work every day to attract companies to use technologies from the Eclipse projects.
  • Secondly, the Eclipse community is working on a single technology platform, so every Eclipse project can inter-operate with the others at some level. Since we are using a common technology platform (Equinox OSGi) and since many of our developers are paid to be full-time Eclipse developers we can do things like ship an annual release train where dozens of Eclipse projects release simultaneously. (This year there were 37 projects that shipped together.) These release trains form the technology platform for the Eclipse ecosystem to build products on for the next year. We now have a track record of shipping six years in a row with the release train on schedule to the day.
  • Thirdly, as a matter of culture Apache uses “community before code” as its mantra. We don’t run around saying this but the reality is that at Eclipse we value “code before community”. Diversity and community are one measure of the health of an Eclipse project but in the end we really care about the code quality and commercial adoption of an Eclipse project when we think of it as a success. The Eclipse projects that manage to do both are the ones we consider our home runs.

So vive le difference!

There are obviously some gross generalizations in the above, but I think I successfully captured some of the key points. Anything I missed? Anything blatantly dumb?

Welcome to the EPL

A bit of good news for the Eclipse Public License this morning comes from Intuit, which announced that their community site code.intuit.com will be using the EPL.

Intuit had previously decided to use the Common Public License, but when we pointed out that it had been superseded at the OSI by the EPL, they agreed that it made sense to go with the EPL. It turns out that some of the links and pages at the OSI had not yet been updated, and thanks goes to Russ Nelson for fixing those quickly!

All-in-all a good outcome for the EPL. It’s great to see the increasing adoption of our license by the broader open source community. It is now the license used by the Topcased and Symbian communities as well as a growing number of projects on code.google.com and sourceforge.

Time to Git Some Progress

Git has been growing in popularity, and I am particularly interested in its potential to reduce barriers to participating and contributing to Eclipse projects. There has been a vigorous conversation about using Git for Eclipse projects going on for some time over in bug 257706, including my own reservations about the idea. But it is clearly time to start making some progress on this topic.

In talking with Wayne, Denis and the committer reps on the Board of Directors, it seems that the most obvious place to start would be to have Git installed on our servers and providing a read-only cache of the work of all projects. The projects themselves will continue to use CVS and SVN. (see bug 280583)

I am personally willing to consider a future where Git becomes the standard SCM at eclipse.org, but time will tell if we can get there.

How can you help?

  • Give us feedback on this idea, either in the comments here or in the bugs mentioned above.
  • If you are involved in an Eclipse project and you would consider switching to Git, please start the conversation with your peers. Would someone be willing to start and maintain a list of willing projects somewhere?
  • Get involved in the eGit project. The faster we have a first class team provider for Git, the faster we can use more Git at Eclipse. The CVS plug-in for Eclipse does truly rock, and there are lots of people at Eclipse who will not even consider switching if Git is not supported with equivalent function and stability

Releasing Galileo

Denis pushes the Big Red Button

Denis pushes the Big Red Button


It was smooth as silk this morning as our esteemed Webmaster Denis Roy pushed the “big red button” to unleash Galileo. He had his moment of trepidation, but so far everything has gone very smoothly.

Thirty-three projects, 380 committers, 24MLOC+…this is a major software release no matter how you measure it.

Congratulations and thanks to everyone in the Eclipse community who contributed.

I would like to also take a moment to thank the people at the Eclipse Foundation who helped make it happen:

  • Wayne Beaton, Bjorn Freeman-Benson, Anne Jacko and Gabe O’Brien for helping run the development processes over the past year. Supporting the Planning Council, getting the Reviews done and keeping the portal running are just a few of their contributions.
  • Janet Campbell, Barb Cochrane and Sharon Corbett for getting all of the IP reviews completed. Eclipse’s well deserved reputation for care of our community’s IP is a big part of our success.
  • Denis Roy, Matt Ward and Karl Matthias for keeping the IT infrastructure up and running flawlessly. Not just for the deluge of downloads, but keeping CVS, SVN, Bugzilla, etc. working throughout a year of development.
  • Nathan Gervais for doing some very cool web design for Galileo. The look of the landing page, download pages, etc. is the best yet by far.
  • Ian Skerrett and Lynn Gayowski for helping with the marketing launch for Galileo. Lining up the press interviews, etc. is a big job. Helping organize 30 democamps around the world is an even bigger job!
  • Donald Smith for organizing a very cool Member Distro Download program.

Helping the community ship the release train is an all-consuming task for the staff here at the Eclipse Foundation. Each year sees incremental improvement, and this year was by far the best job yet. Congratulations and thanks to the team!

Berlin Board Stammtisch

Next week is our first-ever Eclipse Board of Directors meeting outside of the USA. Berlin is our destination, primarily based on the fact that it is a darn cool city.

Although Ralph won’t be able to join us, we are going to carry on the tradition he has created and have an Eclipse Stammtisch while we’re there. So Tuesday, June 16th is an opportunity for you to have a beer with the leaders of the Eclipse community.

If you can make it, please add your name to our Doodle poll. We’re hosting it at the Bavarium. Thanks to Eike Stepper for finding us a place on short notice.

We hope you can join us!

Some New License Flexibility

I have been remiss in updating our website with information regarding some decisions made by the Board late last year. Totally my bad.

So here is some good news:

  1. Projects can license their example code using the Eclipse Distribution License (EDL) as well as the EPL. The advantage to this is that it is clearer to Eclipse users that they can start with EDL-licensed example code when they are developing their products or applications. Because the EPL is a copyleft license and the definition of derivative works can be fuzzy, there can sometimes be confusion as to whether something which started its life as a piece of example code needs to be EPL-licensed or not. You can find details on how to apply this to your project in our policy document.
  2. Contributors of “non-code content” such as articles, whitepapers, etc. are now allowed to use two variants of Creative Commons licenses. This should make it easier for people to contribute their works to the Eclipse Resources library and other places on the Eclipse website.

If you have any questions on how to make use of these policy changes in your project, please drop us a line at “license at eclipse.org”.

I hope these improvements help!

Time Flies

Today is a bit of a milestone for me, as it is exactly five years since I assumed the role of Executive Director of the Eclipse Foundation.

I had an inkling that this was going to be a different kind of role when a few days before I even started a journalist by the name of Darryl Taft called my home to ask me if it was true I was taking the job. Being totally caught off guard, I think I said something dumb like “no comment”. Not an auspicious beginning for a very public position.

It is hard to over-state the early challenges we had getting the Eclipse Foundation up and running. Five years ago we had about fifty members, no staff, no bank account, no offices and the heat was on to take over the creaking IT infrastructure that was still hosted at IBM. The development and IP processes existed in paper form but had never even been tried for real.

Today we have over 170 members, seventeen wonderful staff in three locations and great IT infrastructure. Our development and IP processes have been refined through several iterations and are demonstrating real value to the committers, members and ecosystem at Eclipse. These processes are definitely not perfect, but they get the job done.

But the true excitement of being part of Eclipse has been seeing the original vision of a vendor-neutral open source foundation at the centre of a commercial ecosystem coming to fruition. That was the original vision of people such as Skip McGaughey, Dave Bernstein, Danny Sabbah and John Swainson. I am sure that there are others, and I apologize for not listing everyone. Those “founders” if you will deserve a lot of credit for getting the Foundation created and the Bylaws, etc. written.

Sure, we have no shortage of challenges, but today there exists a multi-billion dollar ecosystem with hundreds of companies and millions of developers using Eclipse. The growth in projects at Eclipse has been awesome to watch as well. The breadth of technology being developed at Eclipse would have been hard to even imagine five years ago. That is awfully darn cool.

This is a pretty tough job. It involves dealing with many different interests and trying to find workable solutions. Anyone who has known me for a long time will tell you that I am not a natural politician. But this has been the single most exciting job I’ve ever had and I look forward to the challenges of the next five years. We are not resting on our laurels here at the Eclipse Foundation. The best is yet to come.

Recent Posts

Archives

Categories

Meta