intermediate 2 min answer

An organisation wants shared internal libraries maintained collaboratively across teams. What must be true for innersource to work, and when does it fail?

gustoinnersourceownershipcontributionlibraries
Show the full answer Hide the answer

What must be true

  • A named owner with capacity to review. Innersource without an owner is a repository where contributions accumulate unreviewed, and contributors stop after the second unmerged pull request.
  • Documented contribution standards: how to build, how to test, what will be accepted, how long review takes. Contributors need to know the cost before starting.
  • A stable interface and a compatibility commitment, because consumers who fear breakage will fork.
  • Genuine consumer benefit from contributing rather than forking. Forking is always faster in the short term, and innersource competes against it on total cost.
  • Recognition for contribution in whatever the organisation actually rewards, or contributions come only from people whose own work requires them.

When it fails

  • When the owning team treats contributions as interruptions, which is rational under delivery pressure and fatal to the model.
  • When the component is on a critical path and the owner cannot accept the risk of external changes — legitimately, and the answer is a request-and-implement model rather than direct contribution.
  • When the domain requires deep context, so a well-intentioned contribution is subtly wrong and the review costs more than the implementation.
  • When there is no consequence to forking, so teams take the fast path and the shared component decays.

The realistic scope

Innersource works best for shared infrastructure and utility code — clients, tooling, templates, common libraries — where the domain is shallow, the interface is stable and the contribution is usually a small addition.

It works badly for core domain logic, where correctness requires context the contributor lacks.

The organisational precondition that is usually missing

Reviewing time in the owning team's allocation, explicitly. If review competes with the team's own delivery commitments it loses, and the model fails through neglect rather than through disagreement — which is the common outcome and is entirely predictable from the funding model.