An organisation adopts an innersource model so teams can contribute to each other's services. It mostly does not happen. What conditions does innersource require?

Why it mostly does not happen

Contributing to another team's service is harder than asking them to do it, and nobody is rewarded for the harder path.

The specific barriers:

1. Discoverability. A contributor must find the code, understand it, and know it accepts contributions. Most internal repositories offer none of that.

2. Onboarding cost. If building and testing another team's service takes a day, a contributor with a small change will ask the owning team instead — and be right to.

3. Review latency. A contribution sitting unreviewed for three weeks teaches the contributor not to try again. This is the most common killer.

4. Unclear acceptance criteria. Without knowing what will be accepted, contributors either over-engineer or have work rejected after doing it.

5. Incentives. Teams are measured on their own delivery. Time spent reviewing external contributions or contributing elsewhere is invisible in that measurement.

The conditions it requires

• A documented contribution path per repository: how to build, how to test, what is accepted, who reviews, expected turnaround.
• Fast local setup. If it takes more than minutes, contribution does not happen.
• A committed review turnaround, treated as an obligation of ownership rather than as a favour.
• Ownership that remains clear. Innersource does not mean shared ownership; the owning team still owns the service, its quality and its operation. Contributions are proposals, not transfers.
• Explicit recognition for both contributing and reviewing, or the incentive gradient defeats the policy.
• Good first issues and templates, lowering the barrier for the first contribution — after which subsequent ones are far more likely.

Where it genuinely helps

Innersource works best for shared platform components, libraries and tooling, where many teams have small needs and the owning team cannot serve them all. It works poorly for complex domain services, where a contributor lacking domain context is more likely to introduce subtle defects than to help.

The honest assessment

Innersource is a capacity multiplier for shared components and not a substitute for adequately staffing platform teams. Organisations adopting it because the platform team is under-resourced find that the barriers above are exactly the ones an under-resourced team cannot remove — no documentation, no fast setup, no review capacity — so the model fails for the same reason it was needed.