You maintain an internal library used by 60 teams. Your team of five also owns two products. Two teams have each opened a pull request adding something you do not want in the library - one a caching layer with its own configuration surface, the other a second serialisation format. Both teams are blocked on the outcome and both say innersource means they can contribute. Walk me through how you run this.

What the interviewer is testing

Whether you understand the maintainer's side of the economics. Most candidates can recite what makes innersource work for contributors. The harder judgement is that openness is not the constraint; review and long-run support capacity is, and that a maintainer who cannot say no produces a library that is the union of every caller's local need.

The clarifying questions that change the answer

• Is the need general or local? One team wanting a second serialisation format is a local need. Nine teams wanting it is a roadmap item you should fund yourselves.
• Who operates the consequence? A caching layer inside a library is debugged by whoever gets paged for stale data, and that is the 60 calling teams, not the contributor.
• What does the contribution cost after merge? Reviewing a first contribution to unfamiliar code typically costs the maintainer one to three times what writing it would have cost, and that is the cheap part. The expensive part is that every future change must keep it working.
• Is the caller blocked, or blocked on this shape of the change? Usually there is a version that unblocks them this week and does not enter the library.

A strong answer's arc

1. Answer fast, in public. Within two working days, on the pull request, name the decision and the reason. Silence is what actually kills innersource: a contribution sitting for three weeks teaches 60 teams not to try.
2. Separate the need from the implementation. Caching belongs in the caller, where invalidation is that caller's business logic. A second serialisation format belongs behind a codec interface.
3. Offer the extension point instead of the feature. Accept a pull request that adds a pluggable codec boundary — small, testable, no new configuration — and let the contributing team own its format as a separate module. You take the seam and they keep the feature. That converts a rejection into a smaller accepted change.
4. Write the contract down once. A CONTRIBUTING file that states what the library is for, what is accepted (bug fixes, adapters at existing seams, tests, docs), what is not (configuration surface for one caller, features with no second consumer), and a response commitment: first response in 2 business days, decision within 10.
5. Escalate the funding question, not the technical one. If both features are genuinely needed by many callers, a five-person team owning two products and a 60-consumer library is under-resourced, and that belongs in front of whoever set the allocation.

Common weak answers

• Merge both to be a good citizen. The library acquires a configuration surface and a second format, your team inherits support for both, and the next 12 contributions cite these as precedent.
• "Fork it if you disagree." Two versions of shared behaviour in the estate, diverging quietly, with security patches applied to one of them.
• Close with "not aligned with our roadmap." True and useless. It gives the contributor nothing to do next and reads as a status difference rather than a design position.

What a strong answer adds

That maintainer review time is platform cost — budget 10 to 20% of the owning team's capacity for external contributions, and report it, because an unfunded review queue is the failure that innersource programmes mistake for cultural reluctance. And that the health metric is time to first response rather than contributions merged, since that is the number every prospective contributor experiences.

When this is the wrong answer

If the library is small, stable and the team is about to hand it over, taking the contributions and the divergence may be cheaper than maintaining a seam nobody will extend again. The contract is worth writing when the library has years of life and many callers; for a component being retired next quarter, merge what unblocks people and move on.