Innersource: Open Source Practices Inside the Enterprise

Most innersource programmes consist of making repositories internal and then wondering why nothing changed.

Visibility is a precondition, and it is the easy one. What actually determines whether a developer on one team fixes a bug in another team’s library is whether their pull request will be reviewed this week or ignored for a month — and no setting controls that.

Before you start

• Internal repositories — the visibility level this depends on
• Visibility and forking policies — the contribution path

The short answer

Innersource is applying open-source collaboration patterns inside an organisation. GitHub documents internal repositories as existing precisely so an enterprise can practise it.

Four preconditions, in order of how often they are missing:

1. Visibility — people can find and read the code. This is what internal repositories provide.
2. A contribution path — forking works, or write access is grantable. Usually forking.
3. Responsive maintainers — contributions are reviewed in days, not weeks. This is the one that fails.
4. A reason to contribute — the contributor gets something, and their manager tolerates the time.

The first two are settings. The last two are how the organisation works, and no configuration produces them.

Why it is worth doing

Duplication is the expensive symptom. Three teams writing the same client library because none could see the others’ work is a cost that compounds — three implementations, three sets of bugs, three maintenance burdens, and three different behaviours that integration teams then have to reconcile.

Bottlenecks are the visible symptom. A team depends on another team’s library, needs a small change, and waits. The change is two lines. The wait is six weeks. Innersource means they make the change and the owning team reviews it.

Knowledge distribution is the underrated benefit. People who read other teams’ code understand the system. Organisations where every team only sees its own code develop a shape where nobody understands the whole.

Recruitment and retention, less measurably. Engineers prefer working somewhere they can see and fix things.

Be honest about the cost, though. Innersource asks maintaining teams to review contributions from people they do not manage, which is work they were not resourced for. A programme that does not acknowledge that is a programme that will fail on precondition three.

The roles that make it work

Borrowed from open source, and they need naming.

Maintainer. The team that owns the repository. They review contributions, they decide what is accepted, and they are accountable for the result. This role must be resourced. A team asked to maintain an internal-source library on top of their own roadmap, with no allowance, will deprioritise reviews — correctly, from their perspective.

Contributor. Anybody making a change. Their obligations are to follow the project’s conventions, to write the tests, and to be responsive to review.

Trusted committer. A contributor who has earned write access, usually after several accepted contributions. This is how a project scales beyond its original team, and it is the mechanism most enterprises skip — with the result that the original team remains the bottleneck forever.

The trusted committer role is the difference between a library with one maintaining team and a library with a community. Making it explicit — with a stated path to it — is one of the highest-value things an innersource programme can do.

What a repository needs to receive contributions

The concrete list, and each item removes a specific reason people give up.

A README that says what it is and how to use it. Without this, a would-be contributor cannot tell whether they are in the right place.

A CONTRIBUTING file. How to set up, how to run the tests, what the review expectations are, how long review takes. The review-time expectation is the item people omit and the one contributors most want.

CODEOWNERS. So a pull request automatically reaches somebody. Without it, contributions sit unassigned. See CODEOWNERS.

Working CI that runs on fork pull requests. A contribution blocked by a check the contributor cannot make pass is a contribution abandoned.

Issues enabled, with some labelled as good starting points. The open-source convention works internally for the same reason.

A stated support level. “Maintained, contributions welcome, reviewed within three working days” or “stable, security fixes only” — both are useful; silence is not.

Tip

The single highest-return item is the review-time commitment in CONTRIBUTING. It is the question every potential contributor is silently asking, and answering it honestly — even with a long number — is better than leaving it unstated. A contributor who knows review takes a week can plan around it; one who does not know assumes never.

CI and fork contributions

The technical obstacle that stops more innersource programmes than any policy.

Workflows triggered by pull requests from forks run without repository secrets and with restricted permissions. This is correct and necessary — otherwise anyone who could fork could exfiltrate every secret by opening a pull request.

The consequence: if your CI needs secrets, fork pull requests fail, and the contribution is blocked by something the contributor cannot fix.

Split the workflow. Tests requiring no secrets run on every pull request. Tests requiring credentials run after a maintainer’s approval, or on merge to a branch. This is the correct fix and it takes real work.

Danger

Never write a workflow that checks out and executes fork pull request code while holding secrets or write permissions. Any enterprise member could then extract those secrets by opening a pull request. If a job needs both untrusted code and privilege, split it: one job runs the untrusted code without privilege, another acts on its output without executing it.

Test this before launching an innersource programme. Have somebody from another team open a pull request from a fork and see what happens. Doing this first, rather than after the announcement, is the difference between a launch and an apology.

Discovery: the precondition nobody plans for

Visibility means people can find code. It does not mean they do, and the gap between the two is where most of the duplication benefit is lost.

The failure is concrete. A team needs a rate limiter. Three exist in the enterprise, all internal, all readable. The team searches, finds nothing useful because they searched for the wrong words, and writes a fourth.

Search is not discovery. Code search finds code you know exists. It does not tell you that a library solves your problem, whether it is maintained, or whether anyone else uses it.

A catalogue is the answer, and it does not have to be sophisticated. A list of the shared libraries in the enterprise — what each does, who maintains it, its support level — solves most of the problem. Many organisations already have a service catalogue and have never extended it to libraries.

README quality is the other half. A library whose README opens with “Utilities” is undiscoverable regardless of visibility. One that opens with a sentence naming the problem it solves is findable by somebody searching for that problem.

Topics and repository descriptions matter more than they appear. They are what search matches against, and they are usually empty.

Assign discovery to somebody. In practice this means a person or a small group who curates the catalogue, notices duplication, and connects teams. It is unglamorous and it is the role that produces the measurable benefit.

Which is worth stating plainly: an innersource programme with no discovery mechanism will produce some cross-team bug fixes and almost no reduction in duplication, because duplication is caused by not knowing, not by not being able to read.

Governance for innersourced repositories

A repository open to contributions from the whole enterprise needs slightly different controls from one only its team touches.

Required reviews still come from CODEOWNERS. Contribution being open does not mean merge being open. The owning team still approves, and this is what makes maintainers comfortable with the model.

Branch protection is unchanged. Fork contributions arrive as pull requests and go through the same gates.

Push rules apply to the fork network, which is the useful property here: a file-size or path restriction on the parent reaches every fork, so a contributor cannot introduce a problem the parent forbids.

Secret scanning and push protection matter more. A larger contributor population is a larger chance of an accidental credential commit, and the contributor may not know the repository’s conventions.

Consider a lighter ruleset for contribution, not for merge. Some enterprises apply strict metadata rules — commit message format, signed commits — that a casual contributor from another team will fail. If signing is enforced and the contributor has never signed a commit, their first contribution fails for a reason unrelated to the change. Decide deliberately whether that friction is worth it on repositories you want contributions to.

Document the requirements in CONTRIBUTING. Whatever the rules are, a contributor who reads them before starting has a much better experience than one who discovers them at push time.

Why programmes fail

The patterns, in rough order of frequency.

Visibility without process. Repositories are internal, nothing else changed, nothing happens.

Maintainers are not resourced. Reviews are unpaid work on top of a roadmap. They lose.

Review latency. A contribution reviewed in three weeks teaches the contributor not to bother, and they tell their team.

No trusted committer path. The original team remains the only reviewer forever, and the bottleneck never moves.

CI blocks fork contributions. Technical, fixable, and frequently unnoticed until somebody tries.

No discoverability. Everybody can read everything, and nobody can find anything. Visibility is not a catalogue.

Contributions rejected on style. A change that works, rejected because it does not match unwritten conventions. Write the conventions, or accept the change and fix the style yourself.

Measured by the wrong number. Counting internal repositories measures the setting, not the outcome. Count cross-team pull requests merged.

No executive tolerance for the time. A manager whose team’s velocity dips because they reviewed three external contributions will stop them doing it, unless somebody senior has said that this work counts.

A contribution, end to end

Walking one through makes the failure points obvious.

A developer on the payments team needs a new option in the shared HTTP client. Two lines, a config flag.

They find it. Search for the package name, land on the repository. Failure point: if the repository description says “utils”, they never get here.

They read the README and CONTRIBUTING. They learn how to run the tests and that review takes three working days. Failure point: no CONTRIBUTING, so they do not know whether contributions are welcome and guess not.

They fork. Failure point: forking of internal repositories is disabled, so their only path is asking for write access — a request that takes a week and may be refused.

They make the change and run the tests locally. Failure point: the test suite requires a service they cannot reach, and the CONTRIBUTING does not say how to work around it.

They open a pull request. CI runs. Failure point: the workflow needs a secret, fails on the fork, and shows a red check with an error the contributor cannot interpret.

CODEOWNERS assigns a reviewer. Failure point: no CODEOWNERS, so the pull request sits unassigned until somebody happens to look.

The reviewer responds in two days, asks for a test, approves. Failure point: the reviewer is at capacity with their own roadmap, and this sits for three weeks.

It merges and is released. Failure point: releases are manual and happen quarterly, so the fix the payments team needed is available in April.

Nine steps, nine ways to fail, and only two of them are settings. This is why “we made the repositories internal” is not a programme — and why walking one real contribution through end to end, before announcing anything, finds more problems than any amount of planning.

What to measure

Cross-team pull requests opened and merged. The primary metric — pull requests where the author is not on the owning team. Everything else is a proxy.

Median time to first review on those. The number that predicts whether contributions continue. Above a week and the programme is dying.

Merge rate for external contributions compared with internal ones. A large gap means external contributions are being treated as lower priority, which contributors will notice.

Repositories receiving external contributions. Is it three libraries or thirty? A programme concentrated in a few repositories has not spread.

Trusted committers appointed. The measure of whether ownership is distributing.

Duplicate implementations found and consolidated. Hard to measure, and the actual business case.

Do not measure internal repository count. It measures a setting somebody flipped.

Starting from a private-by-default estate

If everything is private today, the sequencing question is where to begin, and the answer is not “make everything internal”.

Start from the duplication you already know about. Ask three or four senior engineers where the enterprise has built the same thing twice. They will know, and the answers will overlap. That list is your candidate set.

Make those repositories internal first, after the history scan that any visibility change requires.

Bring them up to contribution-ready standard before announcing anything. A repository people can see but not contribute to teaches the wrong lesson.

Then run the discovery step. Publish what exists, with a sentence each on what problem it solves. This alone frequently prevents a duplication that was about to happen.

Widen by demand, not by decree. When a team asks to contribute to something that is not yet internal, that is the signal to make it internal. Demand-driven expansion means every repository you open is one somebody wanted open.

Do not set a target for the proportion of internal repositories. It measures a setting, it will be met by flipping visibility on repositories nobody looks at, and it will produce exactly the appearance of an innersource programme with none of the substance.

Rolling it out

1. Pick three repositories, not the whole estate. Widely used, actively maintained, with teams willing to be the example.

2. Make those three genuinely ready. README, CONTRIBUTING with a review commitment, CODEOWNERS, CI that passes on fork pull requests.

3. Resource the maintainers explicitly. An allowance for review time, agreed with their manager. If you cannot get this, stop — the rest will not work.

4. Seed contributions. Ask a team with a known need to make a real change. The first contribution proves the path works and finds what is broken.

5. Publish what happened. Time to review, whether it merged, what the contributor said. Concrete beats aspirational.

6. Then widen, using the three as templates and their maintainers as advocates.

7. Appoint the first trusted committers as soon as somebody has earned it. This is the signal that the model is real.

8. Review the metrics quarterly, and be willing to say it is not working.

The economics, stated honestly

Innersource is usually pitched as free collaboration. It is not, and pretending otherwise is why programmes lose support in their second year.

The contributing team saves. They needed a change, they made it, they did not wait. Clear benefit, easy to quantify: the six weeks they did not spend blocked.

The maintaining team pays. They review a change they did not need, from somebody they do not manage, in code they are accountable for. The change may be wrong in ways only they can see. They will carry it forever.

The organisation gains — one implementation instead of two, knowledge distributed, a bottleneck removed. But the organisation is not the entity whose sprint is affected.

This asymmetry is the whole problem, and it explains behaviour that otherwise looks like obstruction. A maintaining team deprioritising external contributions is responding rationally to their incentives.

Three ways to fix it, in increasing order of effectiveness:

Acknowledge review as work. Explicit time allowance, agreed with the maintaining team’s manager. The minimum viable intervention.

Make maintainership visible in performance conversations. If reviewing external contributions is invisible at review time, it will not happen. If it is a recognised contribution, it will.

Fund shared libraries centrally. For the small number of libraries that genuinely everybody depends on, a platform team owning them removes the asymmetry entirely — the maintainer’s job is to serve other teams.

And accept that not every repository should be innersourced. A team’s internal service, which nobody else has reason to change, gains nothing from a contribution process. Concentrate the effort on the shared libraries where the duplication cost is real.

Innersource and open source

Many enterprises run both, and the relationship is worth thinking about.

Innersource is good practice for open sourcing. A library that already receives contributions from strangers-within-the-company, with a working CONTRIBUTING, responsive review and a trusted committer path, is one that can be published without the process being new.

The reverse also happens. An open-source project the company uses heavily may be worth contributing to rather than forking internally, and the skills are the same.

Do not conflate them. Open sourcing carries obligations innersource does not — licence review, security disclosure handling, community management, and the permanence of publication. See visibility and forking policies for the publishing path.

But the cultural work transfers. An organisation where engineers routinely review contributions from other teams is one where open-source maintainership is a smaller step. An organisation where every repository is a private fiefdom will struggle with both.

A useful framing for leadership: innersource is the practice ground. The habits it builds — writing for an external reader, reviewing unfamiliar contributions, maintaining a contract with consumers — are the habits that make an engineering organisation legible to itself.

Common mistakes

Treating visibility as the programme. It is precondition one of four.

Not resourcing maintainers. Review is work; unfunded work loses.

Ignoring review latency. It is the number that determines whether anyone contributes twice.

No trusted committer path. The bottleneck never moves.

CI that fails on fork pull requests. Technical, fixable, usually undiscovered until launch.

Measuring internal repository count. Measures a setting.

Launching across the whole estate. Nothing is ready and nothing works.

Rejecting contributions on unwritten conventions. Write them or fix them yourself.

Mental model

Innersource is a process and a resourcing decision wearing a visibility setting. Making repositories internal is the first ten percent. The programme succeeds or fails on whether a maintainer reviews a stranger’s pull request within a few days, and that is a management decision, not a configuration one.

What you learned

• Internal repositories exist to enable innersource, and visibility is only the first of four preconditions
• The contribution path is usually forking, which requires forking to be permitted
• Responsive review is the precondition that fails, and it is a resourcing decision
• Trusted committers are how a project scales past its founding team, and the role is usually skipped
• A repository needs a README, a CONTRIBUTING with a stated review time, CODEOWNERS and CI that passes on fork pull requests
• Fork pull requests run without secrets, which blocks contributions unless the workflow is split
• Never run fork code with secrets or write permissions in the same job
• Measure cross-team pull requests merged and time to first review, not internal repository count
• Start with three ready repositories rather than the whole estate

Exercise

Use an organisation with internal repositories.

1. Pick a widely used internal library. Check whether it has a README, a CONTRIBUTING, and CODEOWNERS.

2. Look for a stated review-time expectation. Predict: is there one?

3. Fork it and open a trivial pull request. Predict: does CI pass?

4. Time how long it takes to receive a first review. Record the number.

5. Count pull requests merged in the last quarter where the author was not on the owning team. Predict: what fraction?

6. Ask a maintainer whether reviewing external contributions is accounted for in their team’s workload.

7. Identify a capability implemented more than once in your estate. Estimate the cost of the duplication.

8. Write the CONTRIBUTING review-time commitment you would want your own team to make.

Related lessons

Internal RepositoriesThe visibility this depends on.

Visibility & Forking PoliciesThe contribution path.

CODEOWNERSRouting contributions to reviewers.

Pull Request Best PracticesWhat makes a contribution reviewable.