The Scaling Problem
A popular InnerSource project with two Maintainers and fifteen contributing teams will eventually hit a wall. The Maintainers become a bottleneck: Pull Requests sit unreviewed for weeks, contributors get frustrated, and the Maintainers burn out. The project's success becomes its biggest threat.
The Trusted Committer pattern is the standard solution to this scaling problem, borrowed directly from mature open source projects.
What a Trusted Committer Is
A Trusted Committer is a contributor from outside the core team who has demonstrated consistent, high-quality contributions over time and has been granted elevated repository permissions as a result.
Specifically, a Trusted Committer typically has:
- Write access to the repository (can merge Pull Requests).
- Triage access (can label issues, close stale tickets).
- A seat in architecture discussions that affect the project's direction.
They do not have the same authority as a core Maintainer — they typically cannot make unilateral decisions about major architectural changes or deprecations. But they can handle the day-to-day review and merge work that was previously bottlenecked on the core team.
The Promotion Path
The path to Trusted Committer status should be transparent and merit-based:
New Contributor
│
▼ (2-3 merged PRs, follows guidelines)
Regular Contributor
│
▼ (consistent quality, helps review others' PRs, understands architecture)
Trusted Committer
│
▼ (deep architectural knowledge, long-term commitment)
Core Maintainer (rare, usually requires joining the owning team)
Publishing this path in the CONTRIBUTING.md gives ambitious contributors a clear goal and signals that the project values long-term engagement.
Why This Works
A Trusted Committer from Team C has two advantages over a core Maintainer from Team A:
- They understand Team C's use case — they can evaluate whether a contribution from Team C's perspective actually solves the right problem.
- They are invested in the project's health — they use it daily and have skin in the game.
This creates a distributed ownership model where multiple teams feel genuine responsibility for the shared codebase, rather than one team feeling burdened by everyone else's requests.
If asked "How would you scale an InnerSource program as it grows?" the Trusted Committer pattern is the key answer. Explain the bottleneck problem (core team overwhelmed), the solution (promote high-quality external contributors to merge authority), and the mechanism (transparent, merit-based promotion path documented in CONTRIBUTING.md). This demonstrates you understand InnerSource at an operational level, not just as a concept.