InnerSource
Applying open-source collaboration practices inside an organisation, so teams can contribute to code they do not own instead of waiting for it.
Definition
InnerSource makes internal code discoverable, readable and contributable across team boundaries. A team needing a change in another team's service submits it rather than filing a request and waiting.
The problem it addresses
The blocking dependency. Team A needs a small change in Team B's service. B has different priorities, so A waits weeks — or works around it, duplicating functionality or building an unnecessary abstraction.
Multiply across an organisation and this coordination cost dominates delivery. It is the same bottleneck that platform teams face, appearing between any two teams.
InnerSource converts waiting into contributing, which is a substantial throughput improvement where it works.
What it requires
- Discoverability. Code searchable across the organisation, with clear ownership.
- A contribution guide per repository: how to build, test, and what will be accepted.
- Maintainers who review external contributions with a defined response expectation. This is the hard part — it is real work and must be resourced, or contributions rot in review and the practice dies.
- Tests good enough that a maintainer can accept a change from someone unfamiliar with the code.
- Recognition. Maintaining a widely-used internal library must be visible and valued, or nobody does it.
Where it works and where it does not
Works well for shared libraries, platform components, tooling, and services with many consumers and a stable interface.
Works poorly for code with deep domain complexity where an outside contributor cannot reason about correctness, and for components under rapid architectural change where contributions conflict continuously.
The failure to avoid
Declaring InnerSource without funding maintainership. Contributions arrive, nobody reviews them, they go stale, contributors stop trying, and the practice is discredited — while the original bottleneck remains and now has a failed initiative attached to it.
Review capacity is the constraint. Everything else is tooling.
Failure scenarios
- Contributions unreviewed, so the practice dies quietly.
- No ownership, so a repository becomes a shared mess.
- Quality standards abandoned to accept contributions, degrading the component.
- Used to avoid fixing team boundaries that are genuinely in the wrong place.
Interview question
"Team A is blocked for three weeks waiting on a small change from Team B. What are the options and what does each cost?"