An organisation has published an innersource contribution guide, opened every internal repository, and added a company goal for cross-team contributions. Six months in there have been eleven contributions across 200 repositories. Review the programme.

What is actually required

Innersource fails for a reason that has nothing to do with willingness. A contribution costs the contributing team roughly 2x what the same change costs the owning team - unfamiliar code, unfamiliar tests, unfamiliar review standards, and a review cycle they do not control. Against that, the contributing team's alternative is to wait, or to work around it locally, and the local workaround ships to production the same week. Waiting is often cheaper for them even when it is worse for the company.

So the binding constraint is not culture and not tooling. It is maintainer response time, and the thing that buys it is funded maintainer capacity, because an unbounded review wait makes waiting the cheaper option for every contributor every time.

What I would remove

• The company goal for contribution count. It measures the wrong thing and it will be satisfied with trivial changes. Worse, it converts a diagnostic signal into a target.
• The generic contribution guide, if it is one document for 200 repositories. It cannot say the thing a contributor needs: how to run this service locally, what the review bar is here, who merges.

The one change that matters

Fund maintainer time explicitly on the repositories that block other teams - a named percentage of a named person's week, with a published response-time commitment (for example: first review within 2 working days). Then measure that, not contributions.

Identify which repositories those are from data you already have: which teams filed the most cross-team requests, and against which repositories. Usually it is 6 of 200 repositories, and they carry 80% of the cross-team waiting. The programme was scoped to the estate when the problem lives in a handful of chokepoints.

What I would leave alone

Open repositories. Read access across the estate is cheap, is useful even with zero contributions - people answer their own questions by reading code - and removing it now would signal retreat. It is doing quiet good; the contribution goal attached to it is what is failing.

How I would argue this in the review

Not as "innersource failed". As a capacity problem with a measurable constraint: eleven contributions is not apathy, it is the rational response to an unbounded review wait. Ask for two things: the response-time commitment on six repositories, and permission to drop the contribution target. Offer a measurable outcome - median wait for a cross-team change, today versus in one quarter.

When this is the wrong model entirely

When the wait is caused by disagreement about direction rather than by capacity. A pull request cannot resolve a dispute about what a service should do. If the owning team keeps rejecting changes on design grounds, choose either an extension point that makes the change unnecessary or a boundary change that moves the capability - not a contribution process.

Common weak answers

• "Teams need to be more collaborative." Eleven contributions is a rational response to an unbounded review wait, not a character flaw.
• "Make contribution mandatory." Forced contributions are worse than none: they arrive from people with no context and consume the maintainer time that was already the constraint.