Speculation Surrouds Forthcoming Eclipse Labs
Back in December, Eclipse Executive Director Mike Milinkovich revealed that the Eclipse Foundation were considering building an Eclipse Foundation-affiliated forge in 2010, called ‘Eclipse Labs.’ Eclipse Labs will provide a software development management system for projects based on the Eclipse platform, but where the developers do not wish to host at eclipse.org. Milinkovich set a tentative date for an official Eclipse Labs announcement as EclipseCon in March.
This has led to much speculation in the blogosphere. Eclipse Platform UI committer Boris Bokowski has dedicated a blog post to dissecting the Eclipse Labs paragraph in Milinkovich’s ‘Project Community Enhancements for 2010’ post. Bokowski speculates about the finer points of the proposed Eclipse Labs project.
He examines Milinkovich’s claim that Eclipse Labs would be “an Eclipse Foundation affiliated forge where projects … can [be] run” and comes to the conclusion that Eclipse Labs would be “a concrete place for project hosting, i.e. a URL like eclipselabs.org.” He investigated this further, and discovered that eclipselabs.org is already registered by the Eclipse Foundation.
Bokowski interprets Milinkovich’s hope that eventually Eclipse Labs would form “a powerful complement to the projects hosted at Eclipse” as meaning “existing projects at eclipse.org will not be affected.” Bokowski’s hope is that Eclipse Labs will pull “together open source projects that currently would have to be started or hosted elsewhere,” for example on management systems such as Sourceforge and Github.
Bokowski then moves onto the “constraints” Milinkovich mentions, for example, only Eclipse Foundation projects will be able to use the org.eclipse namespace and be included in the Eclipse release train. Bokowski theorises that there will be a clear distinction between Eclipse projects and Eclipse Labs projects. He weighs up the arguments for and against Eclipse Labs hosting, acknowledging that there are several reasons why a developer would “want to run a project on a less restrictive software forge.” In his opinion, these include “minimal overhead to get started;” the freedom to “use whatever process you like for releases,” such as “adding and removing committers, adding dependencies to other software” and “no mandatory IP review.”
However, he acknowledges there would be some benefits to hosting your Eclipse project at eclipse.org. These include the benefit of the Eclipse brand and Eclipse marketing efforts and “approved IP cleanliness, to ease adoption by large organizations and governments.”
Bokowski concludes that Eclipse will have to create a model for moving projects between Eclipse Labs and eclipse.org. He proposes a several-step process, for example:
“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.” Boris Bokowski.
Bokowski’s blog has prompted yet more speculation, with Rafael Chaves founder of Abstratt Technologies, theorising that “EclipseLabs.org (would be) the best place to host an Eclipse-related project if the infrastructure understands Eclipse” and defining two “killer features” that would get them to switch from their current Source Forge management system as: “hosting of update sites” and “plug-in friendly continuous build farm.”
Meanwhile, Dann Martens was more wary, warning that:
“open(ing) up Eclipse itself makes a lot more sense, than simply adding another infrastructure next to it which can use an ‘Eclipse’ sticker.” Dann Martens.
Hopefully, the promised announcement at EclipseCon in March, will clear up a few of the many Eclipse Labs questions currently buzzing around the blogosphere.