Why measure innersource contribution?

Large enterprises often struggle to break down silos between teams. Innersource — applying open source practices inside a company — is one way to encourage cross-team development. But if you're going to invest in innersource, you need a way to track whether it's actually working.

Common goals for innersource initiatives include:

  • Raising overall innersource activity or contribution rates.
  • Building shared ownership of existing innersource projects.
  • Encouraging developers to collaborate across organizational silos.
  • Creating reusable components that serve multiple teams or business units.

The innersource contribution percentage

The key metric is the innersource contribution percentage: the share of contributions to a project that come from people outside the team that originally owns it. Definitions of a healthy rate will vary by organization, but looking at concrete levels helps clarify what the number actually tells you.

0%: single-team ownership

A 0% rate means no one outside the owning team has contributed during the measured period. The project may be used by other teams, or simply visible to them, but with no external contributions coming in. This can be a starting point for collaboration — or a perfectly acceptable end state if your goal is reuse rather than shared development.

5%: minor external fixes

At this level, other teams are making small but meaningful changes, such as bug fixes or documentation edits. The rate is low enough that the original maintainers still retain control over direction. External contributors aren't implementing full features at this stage.

20%: full feature work from outside

A 20% rate signals that developers from other teams are making substantial modifications to packages they want to use. Consider an enterprise with several product lines that shares an authentication package. The package covers basic username/password login, but lacks two-factor authentication. A new product team needs that extra security layer, and because the company has a mature innersource culture, that team can add two-factor authentication itself, get approval from the original maintainers, and ship the feature — all without navigating layers of corporate hierarchy.

Feature-level contributions of this kind typically push the contribution percentage into this range.

50%: shared ownership

Now suppose the same company has no authentication package at all. Two product teams both need the capability, so they build the solution collaboratively from the start, sharing ownership across organizational lines. In that scenario, roughly half of the contributions come from outside each team's immediate members.

Applying this at your organization

Deciding your target depends entirely on what you're trying to achieve. Are you aiming for joint development between teams, or just getting others to adopt and lightly maintain something that already exists? Both are valid. The percentage gives you a concrete way to measure your progress against whichever goal you set.

Organizations interested in starting or improving an innersource practice can find guidance at innersourcecommons.org and opensource.guide. Enterprises already on GitHub have access to hundreds of tools for collaboration and automation, including GitHub Actions and automated security tools like Dependabot.