A Common Management Mistake
When leadership first hears about InnerSource, a common reaction is: "Great — other teams will improve our code for free." This misunderstands the economics of InnerSource.
InnerSource is not free labor. It redistributes labor.
When Team C contributes a feature to Team A's library, Team A's Maintainers must:
- Read and understand Team C's code (which may be in an unfamiliar style).
- Run and verify the tests.
- Provide detailed review feedback, possibly across multiple rounds.
- Ensure the contribution doesn't break existing consumers.
- Update documentation to reflect the new feature.
This is the Maintenance Tax — the overhead that Maintainers pay for every external contribution. For a small, low-traffic project, this tax is manageable. For a popular shared library with 20 contributing teams, it can consume 30-40% of the Maintainer team's capacity.
Managing the Maintenance Tax
Adjust Roadmaps
If a team's project becomes a critical shared component, their engineering manager must explicitly carve out time for maintenance work. A rule of thumb: for every 5 active contributing teams, budget roughly one engineer's worth of time for maintenance and community support.
Raise the Contribution Bar
Requiring contributors to include tests, documentation updates, and a filled-out PR template reduces the review burden. A contribution that arrives with comprehensive tests and clear documentation takes a fraction of the time to review compared to one that doesn't.
Promote Trusted Committers
The Trusted Committer pattern (covered in the next section) distributes the review burden beyond the core team.
Key Point: The Maintenance Tax is a signal of success, not failure. A project with a high maintenance burden is a project that many teams depend on. The organizational response should be to invest in it proportionally — not to shut down contributions to reduce the burden.