The OSPO book uses four stages of open source engagement: consumer, participant, contributor and leader. Dependency governance work belongs mostly to the consumer stage, such as an inventory, usage rules and license tools, and it carries on as a company moves up the stages.
The four stages
The OSPO book's day-to-day operations chapter uses an activity engagement model, credited to Ibrahim Haddad, as a map of what an OSPO does at each stage. Here is the table, condensed, with the dependency angle added.
| Stage | Example activities from the book | Dependency governance angle |
|---|---|---|
| Consumer | Define compliance rules, define rules on using open source, manage an inventory, train staff, introduce license tools, clarify support | The core of dependency governance |
| Participant | Financially support communities, join open source organizations, try InnerSource | Support the projects you depend on |
| Contributor | Create contribution policy and process, qualify contributors | Send fixes upstream safely |
| Leader | Open source proprietary projects, adopt an upstream-first policy, support maintainer autonomy | Shape the projects you depend on |
The consumer stage in detail
For anyone worried about dependencies, the consumer stage is where to start. The book lists these activities, with the value it attributes to each:
- Define compliance rules and practices. An explicit consensus between legal and business stakeholders, and a managed approach to the legal side of consumption.
- Define rules on using open source. Criteria related to project health, so consumption is judged on more than compliance. The book mentions the Secure Supply Chain Consumption Framework as a basis.
- Manage an inventory of open source. The OSPO is aware of the surface area, and the company has a base for risk management.
- Train staff. More awareness of value, licensing and contribution.
- Introduce tools for license compliance. Structure and visibility, and automation that makes risk manageable.
- Clarify how to support open source. Awareness of hidden costs of production use.
How to place yourself
Be honest about where you are. A company that has no inventory is not yet a mature consumer, whatever its contribution record looks like. Ask three questions:
- Can we list the open source in each product?
- Is there a written rule for adding a dependency?
- Do we know who supports each critical component?
If any answer is no, finish the consumer stage before investing in later ones. The later stages are valuable, but they assume a stable base.
Moving up without losing the base
The book frames later stages as additions, not replacements. A participant still needs an inventory so it knows which projects to support. A contributor still needs the usage policy, since contributed fixes often start as local patches. A leader still checks intake for everything it depends on.
For a practical first step in each stage, see the first 90 days of an open source program.
Try it yourself
Click through it at your own pace, or open it full screen. Try answering question one above with this view.
How Safeguard fits
Safeguard provides SBOM and dependency scanning, policies and gates, and compliance and evidence automation, which support the consumer stage. Try gold.safeguard.sh/scan.
Quick check
Do we have to pass through every stage?
No. The model is a map for conversation. Many companies are consumers for years, and that can be the right choice.
Which stage covers dependency governance?
Mostly the consumer stage, though inventory and usage rules support every later stage.
Sources
Last reviewed: 19 October 2026.
