Committer Status for a New Hire
By Wayne Beaton
Every once in a while, we get a request to make somebody a committer on one of our open source projects. These often come from companies that are already contributing to the project, and have either hired a new developer or reassigned an existing developer to work specifically on the project. At face value, this sounds like a good thing: open source projects are starving for resources, and adding a whole new committer can have a massive impact on the ability of the project team to deliver. Our answer to this sort of request, however, is “no” (that’s not the full answer: we try very hard to be much more polite than that).
Operating in a vendor-neutral manner is a goal for all Eclipse open source projects, and requires a clear separation between decisions made by participating companies and collaborative development in open source projects.
Open Source Rules of Engagement
This isn’t a matter of gatekeeping or an indication of a lack of trust. Rather, it’s a direct consequence of the foundational principles that govern the health and sustainability of open source projects. The Open Source Rules of Engagement defined in the Eclipse Foundation Development Process describes fundamental principles—openness, transparency, and meritocracy—that form the foundation of everything that we do. The Open Source Rules of Engagement ensure that projects remain fair, vibrant, and vendor-neutral.
Let’s discuss these in reverse order.
Meritocracy
An individual’s standing and influence within the community are earned through the quality and quantity of their contributions, not by their job title, employer, or reputation from a different sphere. Committer status, the ultimate recognition of a project member’s trust and responsibility, is not a gift or reward.
What does this “merit” actually look like? It’s far more than just writing code. A developer can demonstrate their value to the community in a multitude of ways:
- High-Quality Code Contributions: Submitting well-written, thoroughly tested patches or pull requests that solve real problems or add valuable features. This is the most direct form of merit.
- Constructive Code Reviews: Providing insightful feedback on others’ contributions, helping to improve the overall quality of the project.
- Issue Triage and Support: Actively participating in discussions on issues, offering advice, and guiding new users through common problems.
- Documentation and Tutorials: Improving the project’s documentation, writing clear examples, or creating tutorials that make the project more accessible to newcomers.
- Community Leadership: Engaging in project discussions, participating in design debates, and helping to steer the project’s direction.
The key is that these contributions must be visible to everyone. The community must be able to see the work and collectively agree that this person is a valuable and trusted member who deserves greater responsibility. Committer status isn’t about being a good programmer; it’s about being a good community member. A new developer, no matter how talented, has not yet had the opportunity to demonstrate this on a public stage. They need time to build their reputation and earn the trust of the existing committers.
Transparency
The process for becoming a committer must be open for all to see. This means there can be no “backroom deals” or special exceptions made behind closed doors. The entire journey of a candidate, from their first contribution to their nomination, must be a matter of public record.
This is where the importance of tools like Git and public forums comes into play. Every pull request, every issue comment, every mailing list discussion—these all contribute to a public, transparent record of an individual’s engagement and merit. The commit record provides a clear, immutable history of who has contributed what to the project.
Transparency holds the community accountable. When a new committer is proposed, everyone can review their contributions and voice their support or concerns. This peer review process is a powerful check against favouritism or cronyism. Transparency builds trust. A community that operates in the open is one that developers, both corporate-sponsored and independent, feel safe participating in. They know that the rules are the same for everyone and that their efforts will be recognised on their own merits.
Openness
The final, and perhaps most subtle, principle is openness. This means that the path to committer status is open to anyone, regardless of who they are or who they work for. The playing surface must be level, and the rules must apply equally to all participants. This is the core reason why a company’s hiring decision cannot directly translate to committer status. If an employer could simply appoint a committer, it would inject corporate bias into a meritocratic system. The project would risk becoming a tool for a single company’s agenda, rather than a community-driven effort. The open source model thrives on diversity of thought and contribution. It benefits from input from individuals at different companies, from independent developers, and from academics. By ensuring that committer status is based purely on a person’s demonstrated contributions to the project, the community safeguards itself from the undue influence of any one entity.
Earning Committer Status
So, what is the right way for a new hire to become a committer? The answer is to follow the same path that every other committer has taken: demonstrate their value publicly.
This isn’t a silly or unnecessary hoop to jump through. It’s a practical, essential part of professional development within the open source world. If a developer is truly ready for the responsibilities of a committer, they should be able to produce a few high-quality contributions, participate in discussions, and generally engage with the community in a way that is visible and valuable. This process might take a few weeks or a few months, but it’s an invaluable period of acclimation. It’s during this time that they learn the project’s code base, its community norms, and its technical direction. They get to know the people, and the people get to know them.
Committer status is not a symbolic title. It comes with real, practical responsibilities and powers: the ability to merge code, to approve releases, and to make binding decisions on the project’s future. It is a position of trust, and that trust must be earned and demonstrated. The moment a new hire demonstrates that they have the trust of the existing community, they can be nominated, and the committers can vote on their promotion with confidence. This process is what ensures the project’s long-term health and independence.
The open source world is built on a foundation of trust and shared responsibility. That trust is not a given; trust is earned through open, transparent, and meritocratic engagement. The goal should not be to shortcut this process but to support their new team member in navigating it successfully. The right way to grant committer status for a new hire is to empower them to become one by their own merits, demonstrating to the community that they are a truly valuable asset—not just to their employer, but to the project itself.