Organising Your Eclipse Open Source Project Team

Originally posted on January 27, 2020

The Eclipse Foundation Development Process (EDP) says nothing about how teams should organise.

The EDP defines a committer role: committers are those developers who have the ability to make decisions for the project (e.g., push commits to project Git repositories and configure build servers). We often say that the committers are the ones with the real power: they’re the ones that hold all of the keys to all of the project resources. With great power comes great responsibility, so we have a well-defined process by which a contributor may demonstrate to the existing project committers that they are worthy of joining them as a peer.

The EDP also defines a project lead role: project leads are responsible for ensuring that the processes are being followed. So, for example, project leads need to ensure that committers are engaging in the IP due diligence process. But they are also responsible for ensuring that committers are “playing nice”. That is, they need to ensure that the level playing field and vendor neutrality bits in the EDP are being observed, but the EDP does not explicitly grant project leads any special powers to make technical decisions on behalf of the project team.

As the first link in the project leadership chain, one important power granted to project leads by the EDP is the ability to retire committers who are working against the interests of the team. This is essentially the nuclear option (per Merriam-Webster, “an extreme option regarded as a drastic step or last resort”) and it should be used with care.

Other than defining committers and project leads, the EDP says nothing about how teams organise. We expect that project teams sort this out for themselves.

While it is natural to have one or more committers become technical leaders in the project team, there is no formal technical lead role defined in the EDP. Likewise, while it is natural for certain members of a specification project team to become leaders in the specification process, there is no formal notion of specification lead (or “spec lead”) defined in the Eclipse Foundation Specification Process (EFSP). Any de facto technical or specification lead does not have any special authority beyond that which is granted to them by the other project committers.

So the committers in a project team have some say over who their leaders are and what powers they grant to those leaders. While the role is not specifically defined for this sort of thing, the project lead role could be granted decision making powers. It is completely reasonable for a project team to decide, for example, that somebody in the project lead role must approve of all commits and anybody with that role can mitigate potential rogue actions by rolling back commits. One of the key benefits of organising in this manner is that project lead is an elected position, so project committers have a build-in process for capturing the decision to grant those extra powers.

So how does all of this work?

For many open source projects, the committers follow the natural leaders, and that’s the end of it. But when a more formal relationship is desired, it must be arrived at by consensus of the project team (via public channels) and documented clearly so that everybody can understand how the project team works (making it very clear how a project team works is a critically important aspect of growing diversity in your project team). If the project team decides, for example, that all committers must contribute their updates as pull requests that may only be merged by a project lead, then that must be documented (it’s fairly common for project teams to require that pull requests from one committer be merged by a different committer). When the role is formally defined, it’s also important to document how a committer ascends to into that role (to be clear, in the spirit of vendor neutrality, this criteria cannot be based on employment status).

Note that any rules that a project team decides to adopt don’t have to apply homogeneously across the entire project; a specification project team could decide, for example, that all contributions of text to a specification document must be approved by project lead before they can be merged, but that all committers can just merge their contributions to an API.

While I have your attention… I’d like to also highlight that the Eclipse Development Process says nothing about day-to-day development within a project. It is the project team’s responsibility to decide things like development methodology, merit criteria for new committers and project leads, etc.