Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for April 2009

2008 Retrospective

I wrote this retrospective recently for a Board committee, and Doug Gaff gave me the excellent suggestion that I blog it. I am sure that it is of interest to many in the community.

The following is a listing of the 2008 objectives set by the Board for the Foundation staff, and some thoughts on our accomplishments. I have to say that I think 2008 was a pretty darn good year for the team. Perhaps not an outstanding year, but an awfully good one. We got a lot of things done, and have really set the stage for future growth.

I am sure that I have forgotten some major accomplishments. My apologies in advance!

2008 Annual Objectives Completion

1. Help ship a great Ganymede release train

Thanks to a lot of great work by the project committers, the Ganymede release train went off without a hitch and by any measure was a great success. The Foundation staff contributed to that success in a number of significant areas:

  • Bjorn and team built and ran the Ganymatic build system that was used by the group. He also chaired the regular conference calls and ensured that the process ran smoothly.
  • Janet and team reviewed all CQs in time to ensure that there were no unresolved IP issues.
  • Ian and team executed on the marketing release plan, including the very successful Ganymede DemoCamp program.
  • Wayne executed a series of podcasts to raise awareness of the new features.
  • Denis and team made sure there were no infrastructure issues and that all of the systems were ready for the onslaught of downloads.

2. Maintain the financial and organizational health of the Foundation

There is a lot of work that happens behind the scenes to ensure that the Eclipse Foundation is a well run business. The fact that we’re a not-for-profit doesn’t mean that good management isn’t required to ensure that we keep the lights on, and our services to the community running. Here are few highlights:

  • We noticed the economic downturn in the autumn of 2008 and took immediate action to reduce expenses
  • Converted a significant portion of our reserve funds to CAD at a great exchange rate to reduce our exposure to currency fluctuations. (For those who don’t know, Eclipse’s membership revenue is in USD. But most of our staff, and thus our expenses, are actually in Ottawa, Canada.)
  • Retained all staff and did well on the staff satisfaction survey at the end of the year.
  • Achieved 99.966% uptime on all core IT infrastructure. (Which is pretty cool given that we have such a small IT team. Congrats to Denis, Karl and Matt!)
  • Deployed donated AMD servers to increase capacity and redundancy.
  • Achieved the 2008 financial budget in all material respects.

3. Grow membership and communicate membership value

The membership of the Eclipse Foundation is what funds Eclipse and what supports the operations of the Eclipse Foundation. If you (the reader) work at a company which supports Eclipse through being an active member please accept our deeply felt “thank you!” for your generous support.

  • Finished the year with 190 members. The goal was 180.
  • Implemented the placement of strategic developer logos on the eclipse.org home page.
  • Completely re-did the members content and membership benefit content on our website.
  • Implemented a major overhaul of our Bylaws and Membership Agreement to enable Enterprise Membership. This was the first time we had ever run a vote of the Membership to amend the Bylaws and Membership Agreement, so it was a significant undertaking.
  • Implemented automatic linking of projects that a member contributes to on their membership page. (See IBM’s for an example.)
  • Added member logos to the project pages to recognize their contribution. (See DSDP TM’s for an example.)

4. Implement programs to focus growth in industry verticals

Much of the future potential growth of Eclipse is in industry verticals. Our strategic direction is to take the Eclipse model of collaborative open development to these industries and help them be successful in using open source to create industry platforms.

  • Implemented the processes for the creation and lifecycle management of Industry Working Groups. This included gaining Board and Membership approval of changes to the Bylaws and Membership Agreement to restructure our membership classes.
  • Created our first IWG: Pulsar (Mobile tools)
  • Executed successful Eclipse Banking Days in Frankfurt and New York.
  • Had the initial meeting to kick off the Eclipse Automotive IWG.
  • Had initial conversations with companies interested in insurance, semi-conductor and network carrier industry working groups.

5. Sustain and grow our technical community

Eclipse lives or dies based on how vibrant our technical community is. Ensuring that we have sustainable growth in our project and committer population is a big part of what we try to do at Eclipse. To all of the developers (member employees, individuals and students) who work on or contribute to Eclipse projects thank you for your energy and enthusiasm. You are what keeps Eclipse fresh and exciting!

  • Executed a very successful EclipseCon 2008, with a lot of positive feedback on the technical content. Thanks go to Bjorn, Anne, Donald, et al that helped make EclipseCon a success!
  • Executed a very successful Eclipse Summit Europe, with a lot of positive feedback on the technical content. Thanks go to Bjorn, Anne, Ralph, Lynn, Donald, et al that helped make ESE a success!
  • Grew by approximately 40 new projects in 2008.
  • Pruned our committer rolls of inactive committers.
  • Introduced the notion of “committer emeritus”
  • Got Babel up and running to crowdsource translations for Eclipse projects.
  • Organized two series of DemoCamps in 2008 that featured events in at least 20 cities.

6. Foster Eclipse’s growth as an OSGi-based multi-tier runtime platform and community

I think that this is pretty self-explanatory. 2008 was the year that Eclipse runtime technology really took on its own identity. Which is major step forward.

  • Supported the creation of the Eclipse Runtime top-level project.
  • Planned and implemented a new Equinox community portal.
  • Planned and executed the launch on the Eclipse RT top-level project; had at least 5 positive press articles based on this launch.
  • Organized an Equinox/RCP/OSGi training series with Eclipse Member companies.
  • Focused on runtime topics as part of our Ganymede launch PR messages.

7. Improve committer satisfaction with Foundation processes and procedures

I know Eclipse has a lot of processes. In many ways those processes are what differentiates Eclipse and helps make it a unique place. But at the same time those processes can run the risk of creating unnecessary barriers to entry to participation and contribution to Eclipse. Balancing all of the interests is tough, but I really think that in 2008 we made some significant enhancements.

  • Executed a complete re-write of the Foundation’s IP Policy, including support for parallel IP for all projects, not just incubating ones.
  • Implemented automatically maintained IP logs for all projects.
  • Drafted and got Board approval for a revised and simplified development process.
  • Implemented xml project plan infrastructure to streamline the process for creating the annual Roadmap.
  • Implemented IPzilla enhancements to allow private conversations on IP issues between the EMO and the project leadership community.
  • Steady improvement in the portal applications to give committers better service and more options for self-service.

8. University outreach program

We actually accomplished a lot on university outreach in 2008. I don’t think we necessarily did a good enough job in communicating everything that we did, so hopefully the links below will help a little in that regard.

  • Google Summer of Code initiative was a great success in 2008, with 22 student projects.
  • Creation of the IDE4EDU project which provides a stripped down version of the Eclipse IDE targeted at students.
  • Developed a strategy for university outreach, and started engaging universities to raise awareness.

Written by Mike Milinkovich

April 17, 2009 at 11:38 am

Posted in Foundation

One Small Step Towards Reducing License Proliferation

OSI Certified

License proliferation has been a hot topic amongst the open source community for the past couple of years. I am happy to report that the Eclipse Foundation and IBM have collaborated to do our bit to help by superseding the Common Public License (CPL) with the Eclipse Public License (EPL). This means that the CPL will no longer be considered an active open source license.

Perhaps the best way to explain this is via a Q&A:

1. What was actually done?

There was a two step process that was followed to make this happen. First, following the terms of the CPL, IBM assigned the responsibility to serve as the Agreement Steward of the CPL to the Eclipse Foundation. Second, the Eclipse Foundation officially recognized the EPL 1.0 as the new version of the CPL 1.0. In OSI license terminology, the EPL now supersedes the CPL.

A quick read of the two licenses will quickly show that they are very very close. Other than their names and (previously) their Agreement Stewards, the only substantive difference is the breadth of the patent license termination in the event of a patent law suit. (See the second paragraph of Section 7.) For more information on the relationship between the CPL and the EPL see the EPL FAQ.

2. What does this actually mean?

For those projects that are currently using the CPL and wish to continue using it, not much. However this will open up an additional option for those CPL-licensed projects wishing to migrate to the EPL.

Using OSI’s classification of licenses, it means that the CPL will move from the “Licenses that are popular and widely used or with strong communities” to the “Superseded licenses” category as maintained by the OSI. It does not mean that the CPL has disappeared. However, it is the recommendation of the OSI, IBM and the Eclipse Foundation that new projects use the Eclipse license rather than the CPL if this “style” of license appeals to you. See below for more details if you have an existing CPL-licensed project.

3. Why was this done?

License proliferation in open source is a real issue. It costs businesses to review multiple licenses, and the plethora of licenses can be confusing to someone starting a new open source project.

Over the past five years we have seen the Eclipse Foundation go from a good idea that might work to one of the most successful open source communities out there. We have seen the Symbian Foundation adopt the EPL as its license, thereby bringing a huge community and code base in its own right to the EPL, plus demonstrating the utility of the license well outside of the Java domain that it is best known in. More recently, Google also added the EPL as one of the licenses it supports on Google Code. It is clear that if we wanted to consolidate on one license, that the EPL made the most sense.

4. I have a CPL-licensed project. What do I need to do?

You can continue to use it if you want to, although the whole reason we’re making this happen is because we wanted to provide projects with an easy option to migrate to the EPL to help reduce license proliferation.

There is a very simple path to moving your CPL-licensed project to the Eclipse Public License. Since the EPL has been denoted as the successor version of the CPL, you can use a provision in Section 7 (“In addition, after a new version of the Agreement is published, Contributor may elect to distribute the Program (including its Contributions) under the new version.”) to easily switch to the EPL.

5. When does this take effect?

Immediately.

6. Wait a second! The CPL also says “Each new version of the Agreement will be given a distinguishing version number.” How can the EPL 1.0 be a new version of the CPL 1.0?

Well, you’re right. We could have created a CPL 1.1 that simply pointed to the EPL 1.0. But frankly that seemed a lot more confusing than helpful. Especially since the licenses effectively differ by about one-and-a-half sentences. However, more importantly, the EPL is indeed the successor version to the CPL. The Eclipse Foundation and its members developed the EPL from the CPL by modifying those one-and-a-half sentences. The name of the license doesn’t change that history.

Written by Mike Milinkovich

April 16, 2009 at 1:57 pm

Posted in Foundation

Stating the Obvious

Bjorn’s latest blog post on “Not A Product” has received some passionate responses. It is important that everyone understand that the opinions expressed in Bjorn’s post are his own. They are most definitely not the consensus position of either the Eclipse Foundation staff or of the Board.

Bjorn has served the Eclipse community long and well. He deserves the opportunity to express his opinions as he sees fit. If anyone has misinterpreted Bjorn’s posts as some sort of signal of change in the direction of the Eclipse Foundation, I apologize. They are most certainly not.

Since November 2001, the Eclipse ecosystem has been built upon a strongly defined platform built with a high degree of quality and a deep concern for API evolution. Since 2001, Eclipse has shipped binaries to help developers quickly adopt our platform. That is what has gotten us to this level of success, and that is the model we will be using going forward with e4 and beyond.

Written by Mike Milinkovich

April 3, 2009 at 4:02 pm

Posted in Foundation

Follow

Get every new post delivered to your Inbox.

Join 2,995 other followers