Most of the open source projects that I’m familiar with don’t tend to take significant contributions unless they come with development resources. Taking on significant new functionality can be pretty daunting for development teams that are already stretched.
But how do you on-board new developer (committers) while observing the open source rules of engagement (especially the part about meritocracy)?
Let me back up a bit. Before we even get to the point of wanting to bring on some new developers, we need to consider the contribution. Any decision to accept a significant contribution into an open source project should follow a certain amount of transparent due diligence. The actual amount varies based on many factors including the nature of the contribution, composition of the development team, source of the contribution, etc. The important point here is that some amount of due diligence must occur before a decision to accept a significant contribution of code is made.
During the due diligence, existing project developers get a feel for how well the contribution integrates with the existing code base, and the sort of quality that they can expect from the contribution’s developer(s). The due diligence process also provides a good opportunity for the contributors to learn about (i.e. experience) at least part of the Eclipse Development Process (EDP).
By the end of this process, a development team should have a good feel for whether or not a contribution’s developers are a good fit on the team. A development team may opt to accept the code, but not the developers; they may just decide that the contribution is not a good fit; or they may decide that the contribution’s developers are not a good fit and throw out the baby with the bathwater (ie. reject the contribution). Ultimately, it’s up to the project’s existing developers to decide what to do.
At Eclipse, we have a very well-defined process for electing developers (committers) onto a project. They must first be nominated and then all existing project developers have to vote in the resulting committer election.
The nomination can happen immediately following the point when the decision is made to accept the contribution and add contribution’s developers to the project. Since the due diligence process has occurred transparently, the contribution itself–along with the related conversation–can be cited as the merit for the nomination.
In parallel with the committer election, existing project developers can start the intellectual property (IP) due diligence process on the contribution.
Here’s what the process looks like for an Eclipse project:
- A contributor provides a code contribution (either through Gerrit or Bugzilla);
- Existing project committers review and transparently discuss the contribution (using a public forum like the project mailing list or Bugzilla);
- Existing project committers decide to accept the contribution and the contributors as new committers;
- An existing project committer nominates the contributor(s) for committer status on the project (citing the contribution as the nomination criteria);
- An existing project committer opens a contribution questionnaire (CQ) and attaches the contribution for review by the IP team;
- The election runs for at most one week (or until all existing project committers vote);
- The contribution works through the IP due diligence process
For projects that can leverage the parallel IP process (i.e. incubating projects), the IP due diligence process will generally grant a project permission to “check in” the code in about the same amount of time it takes to run the election. For projects that cannot leverage the parallel IP process, it’s a pretty good bet that the committer elections will conclude well in advance of the code contribution being cleared for “check in”.
