Committers are the developers who hold the keys for an open source project. They are the ones who get to push code directly to source code repositories, configure build servers, push the output of builds to the download server, and so on. They are the ones who make decisions that set the path of their open source project.
Committers have another important role: turning contributors into committers. All committers should plan to spend some significant amount of their time interacting with contributors to whip their contributions into shape, working community forums to court contribution to the project, and otherwise evangelize their project.
The Eclipse Foundation considers having a growing list of committers from a diverse array of organizations and interests a important health metric for open source projects.
At the Eclipse Foundation, committer status is granted on a project-by-project basis. A developer who holds committer status on one Eclipse open source project, does not automatically hold any status on other Eclipse open source projects.
There are three ways to become a committer on an Eclipse Foundation open source project:
- Get elected as a committer by the existing committers;
- Be listed as an initial committer on a new project proposal; or
- Be appointed as a participant representative for a specification project.
The most common way for somebody to join an Eclipse Foundation open source project as a committer is to be elected to an active project. The process starts with a developer establishing a record of making high quality contributions to the project (typically, but not necessarily, in the form of source code patches or code in some form). After an individual has, through contribution, demonstrated that they understand how the open source project works, and that they understand the Eclipse Development Process and are prepared to implement the Eclipse IP Policy, an existing committer will invite them to join the team and initiate an election. Committer elections start with a nomination by an existing committer that includes a statement of merit that usually takes the form of a list of the various contributions that the individual has made to the project. What constitutes a sufficient demonstration of merit varies by project team and team.
The second way to become a committer on an Eclipse open source project is to be listed as an initial committer on a new project proposal (naturally, this only makes sense if the project is still in the proposal phase). Since all new open source projects need to be bootstrapped with actual committers, the new open project creation process serves as the committer election. The community review period provides an opportunity for potential contributors to demonstrate merit and put their names forward as initial committers; it’s left to the discretion of the people who propose (proposers) the project to determine whether or not they’ll add a potential committer to project proposal (there’s no means by which anybody can force their way into committer status on a new Eclipse open source project without consent of the proposer). The creation review serves as the actual election, giving the Eclipse Foundation membership a final opportunity to challenge aspects of the new project proposal, including the initial committers.
It’s acceptable (perhaps not common, but certainly not uncommon) for the initial committers on a new Eclipse open source project to all work for the same employer. Again, the Eclipse Foundation expects that the project team will actively court contributors and committers from other organizations and interests as the project moves from the initial incubation phase into the mature phase.
Third way to become a committer is a special case: get appointed as a participant representative for a specification project operating under the purview of an Eclipse working group. A company that participates in a working group (at a particular membership level) that does not already have a committer representing their interests on a specification project may appoint one. The intent behind the notion of a participant representative is to ensure continuity of the flow of intellectual property grants when an participating organization is found to be without representation. Following their appointment, participant representatives become indistinguishable from other committers on a specification project. As such, following appointment, participant representative committers are subject to the same rules as any other committer: they do not hold any special status or formal role beyond that of committer once appointed, and they retain their committer status if they change employers.
Okay… so there’s actually four ways to become a committer. The Eclipse Development Process includes a provision that allows the project leadership–in the event that a project becomes dysfunctional (e.g., no active committers)–to add (or remove) committers to reinvigorate the project. This power is used rarely.
Your contributions are welcome.
