How to measure innersource across your organization

Measuring collaboration

Breaking down silos is a goal constantly on the roadmap of large enterprises. Innersource is defined as using open source techniques within an enterprise, which can serve as an effective metric in successfully increasing collaboration. But how does anyone measure progress when it comes to innersource contributions across the enterprise? Here are a few examples of what those metrics could look like:

• Increase innersource activity or innersource contribution percentage.
• Cultivate a sense of shared ownership for existing innersource projects.
• Grow developer collaboration across silos.
• Develop a set of reusable projects to be utilized across the organization, or across multiple organizations under a parent enterprise.

The innersource contribution percentage–the rate of contributions from people outside the team that originally authored the software–is a crucial metric to look at.

However, different enterprises may have their own definition as to what a reasonable innersource contribution percentage is. Let’s look at some examples in order to get grounded in the meaning of the metric.

0% innersource contributions

A measurement of 0% for a project would mean that nobody outside of a team has made any contributions over a given time period. This project may still be utilized by several other teams, or perhaps just visible to them, but no contributions are coming in. This can be used as a foundation to get started, or even a destination if your goal is reuse versus collaboration.

5% innersource contributions

This level of contribution indicates that other teams are now contributing important but minimal changes, like bug fixes and documentation additions or corrections. The percentage is low enough that we can assume that the authors still maintain control over the project direction and that contributors are not completing entire features.

20% innersource contributions

When reaching a level of 20% innersource contributions, developers from other teams are making substantial changes to packages they do not own, but want to use. Imagine a company with multiple product lines has a software package that handles user authentication. That package has basic username and password functionality, but does not have two factor authentication. A new product at this company is being developed, and the engineering team wants to use the authentication package, but their customers need the extra layer of protection two-factor authentication provides.

Because the company has a strong innersource practice, the engineering team that owns the new product can simply add two-factor authentication to the login package themselves, get approval from the initial authors of the package, and put it in the new product—all within the enterprise.

This saves time and headaches by avoiding the need to go up and down the corporate chain of command and organizational structure to get anything done. These large types of feature contributions lead to innersource contribution percentages that fall in this range.

50% innersource contribution

Let’s change the scenario above to assume the company does not have an authentication package at all. The company has decided to build a solution and two of the product teams both need to use it. They build the project collaboratively together and the ownership spans across the organizational structure. In this case, one could say that 50% of the contributions came from outside the immediate team.

How do your projects stack up?

Now that we have covered the innersource contribution metric, how do you feel like this applies at your organization? Are you aiming for full on joint ventures between teams, or perhaps just getting other teams to use something that already exists? Either way, I encourage you to reach out to peers on your journey and check out the resources that are at innersourcecommons.org and opensource.guide. There are also hundreds of tools available to use with GitHub that can help your team work better, from GitHub Actions to automated security tools like Dependabot.

If your organization would like support on your innersource journey, reach out to us at https://services.github.com/#contact.

Written by

Zack Koppert

@zkoppert