How to measure innersource across your organization
The innersource contribution percentage is the rate of contributions from people outside the team that originally authored the software. Let’s dive into what it can look like for your organization.
![](https://github.blog/wp-content/uploads/2022/03/Enterprise-Product@2x-3.png?resize=1600%2C850)
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.
Tags:
Written by
Related posts
![](https://github.blog/wp-content/uploads/2023/10/Enterprise-LightMode-4.png?resize=400%2C212)
GitHub Enterprise: The best migration path from AWS CodeCommit
AWS CodeCommit is discontinuing new customer access and will no longer introduce new features. Learn how to migrate to GitHub Enterprise and why it’s the best option for you.
![](https://github.blog/wp-content/uploads/2024/04/Enterprise-DarkMode-2-3.png?resize=400%2C212)
GitHub Actions, Arm64, and the future of automotive software development
Learn how GitHub’s Enterprise Cloud, GitHub Actions, and Arm’s latest Automotive Enhanced processors, work together to usher in a new era of efficient, scalable, and flexible automotive software creation.
![A schematic diagram depicting the steps an SAST tool takes to scan the source code of an SQL application under an SQL injection attack. The first step is tokenizing the source code, the second is abstracting the source code, the third conducting semantic analysis, the fourth conducting taint analysis, and the last generating a security alert about the SQL injection vulnerability.](https://github.blog/wp-content/uploads/2024/02/sast-tool-diagram.png?resize=400%2C212)
The architecture of SAST tools: An explainer for developers
More developers will have to fix security issues in the age of shifting left. Here, we break down how SAST tools can help them find and address vulnerabilities.