InnerSource
Applying open-source collaboration practices inside an organisation, so that teams can contribute to code they do not own rather than waiting or duplicating.
The problem it addresses is a queue: team A needs a change in team B's service, B has other priorities, and A either waits for a quarter or builds a duplicate. Both outcomes are common and both are expensive.
InnerSource lets A make the change and B review and accept it. The practices that make that workable are borrowed directly from open source: discoverable code with a clear README and contribution guide, published standards for tests and style, a defined review and acceptance process with named maintainers, automated verification so a contribution can be evaluated mechanically, and good first issues to lower the barrier.
The obligations fall on the owning team, which is why adoption is uneven: maintainers must review contributions promptly, which is real work, and must accept that code they own will be changed by people they do not manage.
Where it works best: platform and shared libraries, where demand for change is high and the owning team is a bottleneck by construction.
Where it does not: code requiring deep domain knowledge, where a well-meaning contribution costs more to review and correct than to write. Being explicit about which category a repository falls into is what keeps the practice credible.