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.
Posts
