Loading...
Loading...
Loading...
Loading...
Loading...
Why should be build things more than once? We're already busy and behind where we'd like to be. We want to build just once software that solves common problems and then share it widely throughout the company.
Synopsis: Count how many times the InnerSource project is used. Gain additional insight by gathering metadata on these usages such as business unit or time frame. With this additional metadata we can see how lopsided or even the usage is spread across the company and across time.
Unit of Measurement: Ordinal number.
Interpretation: Higher absolute usage count is generally better. Higher diversity of usage across business unit or time frame is generally better.
Measuring
If the project is an API and requires caller authentication, then read the API logs to determine the list of callers.
If the project is a module (or package), then scan your source control system for files that list out dependencies for a package manager to install. Here is a list of . Look in those dependencies for usage of your InnerSource project.
The project will parse out these dependencies for you.
is a security tool that your organization may already use. As part of its operation, it already parses out these dependencies. This information is exposed via .
Question
How it relates to the goal
Gotchas
Every instance of reduced duplication will show up as an increase in usage.
The converse is not necessarily true that every instance of increased usage is an instance of reduced duplication. It's always possible that some shared usage would have happened even without InnerSource.
Metric | How it answers the question | Gotchas |
We can see how many times an InnerSource project is reused. If there is extra information attached to that usage (like which business unit is the user) then we can see how widely across the company an InnerSource project is used. |
An overview of the Goals, Questions, and Metrics (GQM) catalog.
Right-click on any node representing a goal, question, or metric to open a new tab with more detailed information.
Add your goals, questions, and metrics into this graph! It will help you to see how others approach and interact with what you are doing. You may get new ideas of what metrics answer the questions you have or what additional goals your questions can support. See CONTRIBUTING.md#metrics.
This section aims at providing a strategy for your InnerSource metrics that help to understand the path from your initial process till a full InnerSource organization.
It is important to remark that metrics useful for some organizations are not that useful in other contexts. This is similar to the open source projects where a project is not that similar to other in terms of governance, licenses, infrastructure or detailed process, but they are producing open source software and working as a community. This handbook has a similar goal, to detail how an ideal InnerSource project would be, but there are not two organizations using the same InnerSource approach.
Thus, metrics useful for some contexts, for example technological organizations, might not apply to other context such as banks due to external factors such as legal regulations that are even different from country to country.
In addition to all of this, when measuring InnerSource, there are three main purposes to use metrics: check on going work, lead process improvement[^5] and motivational aspects.
Check on going work: this helps to understand where the development is right now. To be aware of the status helps to understand how fast things are changing when a new process is in the pipeline. This also helps to go from A to B and even trying several approaches to the same problem and have tests for this.
Lead process improvement: InnerSource means a change in how process works in the following. From a hierarchical way to a flatter way of working, InnerSource needs indicators to help to determine if that process improvement is properly working. And if this is not working, then using another approach or apply other policies.
Motivational aspects: InnerSource also means cultural change, and this is not usually taken into account in other methodologies. Indeed, this cultural change is identified in InnerSource as key. This should be the type of actions that will help to migrate from a traditional way of working to a more transparent and community- oriented way to work. And metrics can help to lead this process. First, to let developers know where they are and how their process is working, but also to have some fun within the work and competitions through challenges, hackathons and other measurable activities that lead to a more community-oriented organizations.