Eclipse Labs

Mike wrote on his blog back in December that the Eclipse Foundation is "looking at creating an Eclipse Foundation affiliated forge where projects which are based on the Eclipse platform, but are not interested in hosting at eclipse.org can run their projects."

Click on the image, but it's not an official eclipse.org Eclipse Lab!

Admittedly, this announcement was a little vague, most probably because this is part of the Eclipse Foundation's program plan for 2010, and lots of details still need to be worked out. In the comment section, Mike wrote that he is "expecting to announce this at EclipseCon in March." This tells me that there are at least a few open questions that need to be answered, or negotiations that need to take place, or else this could have been announced in detail already.

As a committer representative on the Eclipse Board of Directors, I know a little bit more (but not too much) about this, but Board meetings are confidential, for good reasons - otherwise Mike wouldn't be able to openly discuss his vision and plans with the Board, which is one of the main functions of the Board of Directors.

So let me just go through what everyone does know (or can know) so far, based on what Mike has written in his blog posting and in the corresponding comment section, with a little bit of added interpretation and speculation just because it's rumour season:

1. "An Eclipse Foundation affiliated forge where projects ... can [be] run" sounds to me like a concrete place for project hosting, i.e. a URL like eclipselabs.org. It turns out that this domain has been registered in December by the Eclipse Foundation. My hope is that soon, eclipselabs.org can be listed in the "Specific requirements" section of this wikipedia article on software hosting facilities, as a specialized software forge for Eclipse-related open source projects.
   
   
2. This is for projects that "are not interested in hosting at eclipse.org", and "Eclipse Labs will hopefully over time form a powerful complement to the projects hosted at Eclipse.": Sounds to me like existing projects at eclipse.org will not be affected. Instead, I hope, this will be attractive by pulling together open source projects that currently would have to be started or hosted elsewhere (e.g. at Sourceforge, Github, Google Code, ...).
   
   
3. "There will obviously be some constraints (e.g. only Eclipse Foundation projects can use the org.eclipse namespace, and be part of the release train)": Sounds like there will be a clear distinction between Eclipse projects on one side and Eclipse Labs projects on the other side. There are many good reasons why you may want to run a project at a less restrictive software forge, for example:
   • minimal overhead to get started
   • use whatever process you like for releases, adding and removing committers, adding dependencies to other software, etc
   • no mandatory IP review
   Likewise, there are many good reasons why projects find it attractive to be Eclipse projects hosted at eclipse.org:
   • benefit from the Eclipse brand and Eclipse marketing efforts
   • use the same meritocratic principles and practices as every other project, making it easy to build trust across projects
   • approved IP cleanliness, to ease adoption by large organizations and governments

So while the "Foundation as a Service" idea is an interesting thought experiment, I think a reasonable next step is to create Eclipse Labs as a place to start Eclipse-related open source projects easily. This will establish two Eclipse-branded places for hosting projects, at opposite sides of the fast-and-loose vs. regular-and-dependable spectrum.

Yet another non-eclipse.org Lab, click on the image!

Eventually, it will become important to handle the transition between Eclipse Labs and eclipse.org. For example, a project at Eclipse Labs may want to move to eclipse.org at a later point in time when it is more mature. Anything that can be done to ease this transition will be to the benefit of Eclipse, and it may make sense that projects make the transition in several steps. For example, an Eclipse project may want to depend on software from an Eclipse Labs project, at which point an IP review will have to be conducted on the eclipse.org side. Or a project at Eclipse Labs may want to become an incubating eclipse.org project, which would mean adopting the Eclipse processes but not necessarily a full IP review until the project makes a release at eclipse.org.

I hope this was useful information^H^H^H^H^H^H^H speculation. ;-)

P.S. I have used some words of Miles Parker's excellent blog post for the reasons why you would choose Eclipse Labs vs. eclipse.org as the place to run an open source project.