Organising Your Eclipse Open Source Project Team

By Wayne Beaton

The Eclipse Foundation Development Process (EDP) clearly defines the roles of contributors, committers, and project leads. It deliberately refrains, however, from dictating internal team organisation, thereby granting project teams significant autonomy in establishing their own leadership structures and decision-making processes. As always, these practices, like all of an Eclipse open source project’s practices, must align with the Open Source Rules of Engagement defined in the EDP, should be clearly documented, and applied consistently.

Standard Roles

The EDP defines a contributor role: contributors are individuals who have made valuable contributions to the project but do not yet have the decision-making authority of a committer. They typically submit their work via pull requests or patches, which are then reviewed and merged by existing committers. The contributor role serves as an important entry point for new community members to demonstrate their skills and commitment to the project, often as a stepping stone towards becoming a committer.

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 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 and are implementing the Eclipse Foundation Security Policy. But they are also responsible for ensuring that committers are “playing nice”. That is, they have responsibility to ensure that the entire project team is engaged in practices that are consistent with being open, transparent, and meritocratic as described in the Open Source Rules of Engagement. To wit, project leads are responsible for ensuring that the project is maintaining a level playing field that is open to all comers and that the project is operating in a vendor-neutral manner. The EDP does not explicitly grant project leads any special power or authority to make technical decisions on behalf of the project team.

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

Other Roles

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 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.

Other project roles may emerge. The committers may decide, for example, that they will not merge contributions unless they are approved by a UX expert.

The committers in a project team have considerable influence 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 contributions 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 built-in process for capturing the decision to grant those extra powers.

Any special authority that is granted to an individual only persists for as long as the committers support the individual. It is natural for individuals to cease to be recognised as technical leaders after some period of inactivity, or when committers disagree with their decisions.

How Does 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 an open source project or organisation formally defines a role, they must clearly document how someone actually earns that elevated status. This documentation should lay out the specific requirements and steps involved in becoming a committer, keeping things transparent and fair. The criteria should be based around earned authority: publicly demonstrated competence through contribution.

It’s absolutely essential that these criteria for ascending into a custom role have nothing to do with someone’s employment status. To keep things vendor-neutral and encourage a truly open and welcoming environment, the qualifications for a role must only be based on their proven contributions, technical know-how, community involvement, and alignment with project values. Linking status to employment gives an unfair advantage to employees of a particular vendor and will inevitably erode the collaborative, independent spirit of an open source project.

Examples

Here are some examples of custom roles, and the criteria by which an individual might earn those roles.

A project team might decide to define a notion of code owner, that grants specific individuals or groups responsibility for particular modules or components of the codebase. Code owners would be tasked with reviewing and approving all pull requests affecting their designated code, ensuring quality, consistency, and adherence to project standards. They would also serve as the primary point of contact for issues or questions related to their owned code. The criteria for becoming a code owner could include a deep understanding of the specific codebase area, a history of significant contributions to that area, and demonstrated expertise in its design and implementation.

A project team might decide to define a release manager role, responsible for coordinating release cycles, ensuring all necessary testing is completed, managing version numbers, and overseeing the final deployment of new software versions. The release manager would not have any special technical authority beyond what is granted by the committers, but their decisions regarding release readiness and timing would be respected and followed by the project team. The criteria for becoming a release manager could be based on demonstrated organisational skills, attention to detail, a thorough understanding of the project’s development and deployment processes, and a history of reliable contributions to previous release efforts.

A project team might define a user experience (UX) lead role, responsible for guiding the overall user experience strategy of the project. The UX lead would focus on understanding user needs, conducting usability testing, creating user flows and wireframes, and ensuring that the project’s design aligns with best practices and user expectations. This role would involve collaboration with committers to integrate UX considerations into technical implementations. Criteria for becoming a UX lead could include a demonstrated history of contributing UX advice and designs to the project, expertise in relevant UX areas, an understanding of the project’s user experience architecture and design principles, and a proven ability to collaborate effectively within the project community.

The pattern should be clear from these examples: formal roles require some public demonstration of skills and competence. These examples also demonstrate progressive responsibility: individuals take on greater responsibility and leadership roles as they demonstrate their capability and commitment to the project over time.

Conclusion

While the Eclipse Foundation Development Process defines core roles like contributor, committer, and project lead, it deliberately empowers project teams to establish their own internal leadership structures and decision-making processes. This autonomy, however, comes with the responsibility of ensuring all practices align with the Open Source Rules of Engagement, are clearly documented, and applied consistently. Whether through formal consensus or the natural emergence of technical and specification leaders, the committers ultimately hold the authority to define and grant special powers within their teams, always prioritising open contribution and a vendor-neutral environment to foster a truly open and collaborative open source project.

We’ve created this issue as place to post comments and discuss this article. If you have questions about Eclipse Project Governance, contact emo@eclipse-foundation.org.