Thursday, January 30, 2014

It is time to reboot Eclipse Development Process

Eclipse Foundation has a reputation for being heavy on process, especially among up-and-coming projects that compare us unfavorably to other open source communities, such as GitHub. Eclipse Development Process (EDP) is very prescriptive on what must be done by member projects at various stages with little regard for the fact that there is not a one true way of developing software. Perhaps it doesn’t have to be this way?

Creation Review

To create a project, the team must find an existing project willing to host it and create a document to sell the idea to the PMC and EMO. If the team succeeds in convincing the gatekeepers, there is a waiting period for the creation review and another waiting period while the project name is reviewed for potential trademark issues. It can take many months to get a project created.

I propose that we automate the creation process and remove all of the reviews. A developer should be able to create a project after entering a name, a short description and the initial set of committers. The trademark review can be done asynchronously and the status publicized with a badge on the project dashboard. To make this manageable, project termination must be similarly automated. Any project with no measurable activity is given a few notices and then automatically archived.

IP Review

Each third-party dependency and a non-committer contribution must be reviewed by Eclipse Foundation’s legal team to ensure IP cleanliness. This is a valuable differentiator that draws many projects to Eclipse Foundation, but why should EDP mandate it for all projects and force it as a requirement for every release?

I propose that we replace the IP Review prior to a release mandate in EDP with an “IP Reviewed” badge that can be awarded to a release. For maximum flexibility, the badge can be earned either before or after the release date. This would allow projects to decide if their specific community requires the extra degree of safety afforded by the review. Maybe IP cleanliness is something that a project achieves after a few releases instead of being stuck unable to make a release until all the issues are sorted out.

Incubation

When a project is created, it enters an incubation phase where the team must learn how to be a good project and get all the initial IP ducks in the row. Once the project team feels they’ve suffered the indignity of the egg for long enough, they petition for a graduation review and another document must be prepared. Then a small group of individuals will review the state of the project and hopefully confer upon the project the “mature” mantle.

This process assumes that once a project matures, it stays mature, but in practice many mature projects regress after the graduation review to the point that they operate worse than some incubating projects.

As an adopter of many open source projects, I find the incubation bit of little value when evaluating a project. Instead, I head to Ohloh to check on the project activity, I head to the project’s forum to see if adopter questions are answered in a timely manner and I head to the releases page to see if the project has been making regular releases.

We could easily replace the incubation and the graduation review with a better project dashboard and automated badges keyed to various aspects of project vitality. I’d love to see Eclipse Foundation partner with Ohloh for the source repository analysis.

Release Reviews

For each release, a project is required to produce a plan in a tightly-prescribed format with milestones, themes and other such content. At the end of the release, the project is required to produce a release review document, which frequently repeats much of the content from the plan, just using a different verb tense. Then the project must seek approval from the PMC and EMO, a release review must be scheduled and a waiting period must be observed.

I have nothing against projects that find this approach valuable, but this is mandated for all projects.

I propose that all of this is scrapped and replaced with a much less prescriptive system. In the portal, the project lead adds a release by specifying a version, a description, a release date and a set of links to various relevant resources. The portal then displays a release dashboard showing this information and a Bugzilla report. The release dashboard should be sufficient for the community to get a very good understanding of the purpose of the release and the progress, but if necessary the project can always augment with links to the wiki. Once the release is ready, the project lead presses the big “release” button and the release is marked as completed. There is no need to seek approval from anyone and no waiting period.

Conclusion

We need to ask ourselves why Eclipse Foundation exists. I don’t believe that EDP as it exists today is central to Eclipse Foundation’s mission. We should scrap it and replace it with a much smaller set of rules, where only those rules that are justified as absolutely essential are included. This will make life less frustrating for the existing community and ensure that Eclipse Foundation remains competitive to become a home for the next big thing.

6 comments:

Jilles said...

... or you could just go to Github, benefit from the superior tools and community there, and release when you are ready according to your own terms and process. What exactly is the added value of the eclipse foundation these days other than having big old corporate IBM written allover it? Btw. same goes for Apache these days, which is sort of the grand daddy of the eclipse foundation.

Jérémie Bresson said...

It really depends what you are looking for. For me the Eclipse Foundation needs to care about all the stuff around your open source code (Intellectual property, vendor neutrality, legal issues, trademark…). If you do not want all this, nobody force you to host your project at the fundation: you can just go to a platform like sourceforge, github or bitbucket.

If you use one of these platforms and you are a company that cares about the stuff around the code and around the project, you will also have to add some processes on top of the platform. This additional layer will somehow be an answer to the same problem addressed by the Eclipse Fundation (CLA, release schedule, trademark, audit of source code and of dependencies to ensure IP…). Have a look at how RedHat/JBoss is using GitHub and you will figure out that they are no longer a GitHub only project.

That said, I agree with you on the incubation phase: when you have a look at the projects in incubation phase and the projects “not in incubation” (because this is different from “mature”), it is really hard to tell if a project is production ready or not (for example: Tycho is in incubation)


@Jilles:
Comparing the Eclipse Fundation with GitHub does not make sense to me. They do not address the same question. I agree with the fact that for a lot of projects a platform like GitHub is a better choice than a foundation like Eclipse. But it depends on what you need.


Konstantin Komissarchik said...

To be clear... I am not opposed to all process, but I do believe that every project should be free to define their own process as is appropriate for their specific community, instead of having a single process imposed on all projects.

For instance, turning IP due-diligence into a service offered by Eclipse Foundation to member projects instead of an imposed process would allow projects to decide how to best utilize this feature instead of struggling against it.

Markus A. Kuppe said...

+1 for the IP as-a-service idea.

E.g. for ECF we have several different providers for certain APIs. Right now all have to be IP checked regardless of type of user base (corporate vs. rest of world). Then for another set of providers we are forced to host at gh (incompatible license, no IP possible). This is less than idea due to fraction.

John Arthorne said...

Your suggestions for changes to release reviews are already been implemented. Projects no longer need to create a plan in XML format and then prepare release review slides. These are replaced by creating a release entry in the projects portal that acts as both plan and release record, similar to what you describe.

Konstantin Komissarchik said...

John, I am proposing a drastic reduction in documentation requirements. Simply using the portal to provide the same plan and release review content previously mandated in a different format does not accomplish that.