The Eclipse Architecture Council is in the process of making a change to how the Eclipse Development Process (EDP) defines the Reviews that Eclipse open source projects are required to engage in. Foremost on our minds is the nature of Release Reviews which the EDP current requires ahead of all major and minor releases (service releases are excused from the requirement).

In the world of open source, Committers are ones who hold they keys. Committers decide what code goes into the code base, they decide how a project builds, and they ultimately decide what gets delivered to the adopter community.

The term Intellectual Property (IP) refers to any sort of creative work, be it literature, art, or software. In the realm of open source software, artifacts like source code, documentation, and images are considered intellectual property. Unless otherwise stated, intellectual property is the property of its creator, who may grant permission for others to use that intellectual property by providing a license.

For many open source organisations, open means the same thing as transparent: open as in open book. At the Eclipse Foundation, we regard being transparent as the practice of making sure that the community can see and understand what the project is doing; and being open as the act of giving up absolute control and welcoming the community to participate as an equal player on a level playing field (i.e. being open to participation by the others).

As part of the project creation process, the Eclipse Foundation assumes ownership of the project’s name. As a legal entity, the Eclipse Foundation owns all Eclipse project and corresponding product trademarks on behalf of the the Eclipse community. This prevents companies and others from misusing or misrepresenting their products as being the projects.

The Eclipse Development Process (EDP) regards a release as a pretty significant event. A release is similar to what other organizations might call a general availability release (GA), or ship event. A release is generally associated with some form of enhanced quality assurance testing and marketing. A release is intended for the widest possible audience of users, adopters, and downstream consumers.

For a very long time, I’ve wanted to completely rewrite our documentation for projects and committers. I finally gave it a big push last quarter and have completed a first big revision. There’s still more work to do, but I believe that the new document is very close to being the more-or-less complete “how to run an Eclipse project” document that we’ve needed for a while.