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.
Depending on the InnerSource project, usage of the project could look something like:
Inclusion of a module in a build.
Calling and API.
Visiting a UI.
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.
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.