A new OSPO should deliver one meaningful result in its first 3 to 6 months while working on longer projects, and keep the active list short. The OSPO book recommends this to counter doubts about whether the office is needed. For dependency governance, a usable inventory and a usage policy are good first deliveries.
The problem the book describes
The OSPO book's day-to-day operations chapter lists a common problem: a new OSPO is slow to make recognizable progress, and doubts creep in about whether it is needed. Its recommendation is to maintain a focus on meaningful impact in both the short and long term. Short-term impact reassures stakeholders that the OSPO is needed and competent. Long-term impact creates sustainable value and embeds the OSPO in the organization.
It suggests identifying something important that can be delivered within the first 3 to 6 months, while also working on longer projects that deliver in 6 to 12 months, 12 to 24 months and 2 to 5 years. It also advises keeping the list of active projects short at first so they are delivered with quality and on time. Once the OSPO has a track record, it can ask for more resources.
A roadmap for dependency governance
The horizons are from the book. The contents are our suggestion for a company whose main concern is dependencies.
| Horizon | Deliverable | Why it fits |
|---|---|---|
| 3 to 6 months | A current inventory for the top products, and a one-page usage policy | Visible, useful, and the base for everything else |
| 6 to 12 months | Automated checks on new dependencies, and a request form | Moves policy into the workflow |
| 12 to 24 months | Reporting to management, supplier bills of materials, health checks for critical dependencies | Extends reach beyond your own code |
| 2 to 5 years | A consumption framework assessed across teams, contribution policy, sponsorship plan | Builds long-term resilience |
Where you place a framework such as S2C2F is up to you. The book points to it as a basis for open source guidelines. See S2C2F maturity levels.
Picking the first deliverable
Choose something that is hard to argue with. A list of the open source in your main product, with the ten riskiest items flagged, is concrete. A policy that engineers can read in five minutes is concrete. A new committee is not.
Check each candidate against three tests:
- Will a stakeholder outside the OSPO notice it?
- Can we finish it in one quarter?
- Does it make the next project easier?
Keep the active list short
The book is explicit about starting small. Write the roadmap for all horizons, but limit work in progress to two or three items. Finishing and reporting on two projects builds more credibility than half-starting six.
Report progress
At each milestone, publish a short note: what changed, what it enabled, what is next. This is how you earn the resources the book says a strong record can justify. See five numbers an open source program should report monthly.
Try it yourself
Click through it at your own pace, or open it full screen. It shows the kind of inventory that works as a first deliverable.
How Safeguard fits
Safeguard provides SBOM and dependency scanning, asset discovery and policies and gates, which can shorten the path to the first two horizons. Try gold.safeguard.sh/scan.
Quick check
How many projects should a new OSPO run at once?
The book says to keep the active list short at first. Two or three is a sensible limit.
What is a good first deliverable?
An inventory for the main product plus a short usage policy. Both are visible and useful.
Sources
Last reviewed: 19 October 2026.
