Make This Person We Hired a Committer

Here’s a scenario: you work for an organization that contributes to open source and you’ve hired a developer to work on your favourite open source project. You need to make them a committer. How do you do that?

I get this sort of request every so often: “we’ve hired so-and-so and we need you to make them a committer, m’kay?”. The short answer is: no.

The Eclipse Foundation Development Process, and all Eclipse open source projects by extension, work on three principles that we refer to as the Open Source Rules of Engagement which states that Eclipse open source projects must operate in an open, transparent, and meritocratic manner. All three of these rules come into play when we’re talking about making somebody a committer; I’ll discuss them in the opposite order.

To be considered for committer status a candidate must demonstrate merit. Generally, this takes the form of making high-quality contributions to a project in the form of patches or new code, but can manifest in other ways. It may make sense, for example, to nominate a committer based on a history of helping users and adopters.

The demonstration of merit must be something that everybody can see. That is, the demonstration of merit must be transparent to the general public. Again, code contributions are an obvious example of this as the commit record is open for all. This is one of the reasons that commits must be correctly attributed (i.e., the Author field in a Git commit must include the author’s name and credentials); another reason being that implementing an effective intellectual property regime requires it. With the tools available today, it’s pretty easy to point to a pattern of contribution.

The entire process must be open. That is in the sense that it is open to all comers; as I like to say (in one form or another), that the playing field must be level. That means that the means by which an Eclipse project team decides to make somebody a committer must not be biased by who that individual works for, or any criteria other than the the quality of the contributions they’ve made to the project and their demonstration that they understand their role and responsibilities as a committer.

To earn committer status, a candidate must demonstrate that they understand their responsibilities under the Eclipse Foundation Development Process as well as the project code.

If you believe that somebody is ready to go and all this public demonstration of merit is just plain silly, remember that it’s not you that you need to convince: it’s that developer that you don’t know who is watching your project, trying to figure out what they need to do to participate, and getting hired by your company can’t be the answer.

If you really believe that somebody that does not have a visible record of contribution is ready to be a committer, get them to contribute a few pull requests to prove it to everybody else. If they’re ready to be a committer, then they should be able to do this without much trouble (if making pull requests against your project is hard for some reason, then we should address that). If they don’t have anything to contribute, then why do they need to be a committer at all?

I’ll admit that I tend to think of committer status in practical terms: when somebody needs to have the powers and responsibilities of a committer in an open source project that is operating in an open and transparent manner, demonstrating merit shouldn’t be too onerous.