An organisation wants shared internal libraries and services to be improvable by any team. What conditions make innersource work, and when does it fail?

The problem it addresses

A team depends on another team's library or service and needs a change. The owning team has its own priorities, so the change is queued behind their roadmap. The consumer's options are to wait, to fork, or to work around it — and all three are bad, with forking being the worst and the most common.

Innersource proposes a fourth: the consuming team makes the change themselves, and the owning team reviews and merges it.

The conditions that make it work

• The code must be discoverable and readable by an outsider, with a working local setup that does not require tribal knowledge. If it takes a day to get the tests running, nobody contributes.
• Contribution guidelines that state what is wanted, what will be rejected, and how to propose a design before writing code. The most demoralising outcome is a completed contribution rejected on architectural grounds, and a lightweight design conversation first prevents it.
• Review capacity that is genuinely allocated. This is the condition most often missing: the owning team must have time to review external contributions, and if reviews take three weeks the practice dies quietly.
• Tests good enough that an outsider's change is safe, which is what allows a maintainer to accept work from someone who does not know the system.
• Clear ownership retained. Innersource is not shared ownership — the owning team still decides direction, still maintains it, and still says no. Diffusing ownership produces a library nobody maintains.
• Recognition for contribution and for review, since both are work performed for another team's benefit and will not survive without being valued.

When it fails

• The owning team is under-resourced, so reviews are slow, contributions rot, and consumers learn that forking is faster.
• The library is core to the owning team's product, where they reasonably want tight control and external contributions create risk they carry.
• The contribution is a fundamental design change rather than an increment. Innersource handles additive changes well and architectural ones badly, and pretending otherwise wastes everyone's effort.
• Highly specialised code, where an outsider's contribution costs more to review than to write.
• Regulatory or security-sensitive components with restricted change processes.
• As a substitute for staffing. A platform team that cannot keep up and is told to rely on contributions is being asked to review as much work as it would have written, at higher cost.

The alternatives that are sometimes better

• Extension points, so consumers add behaviour without modifying the core — usually the better answer for a widely-used library, because it removes the coordination entirely.
• A well-defined request path with a real service level, where the owning team commits to a response time.
• Genuinely transferring ownership to the team that cares most.
• Accepting a fork, deliberately and with a documented reason, when the consumer's needs have diverged enough that shared code is a fiction being maintained at cost.