An OSPO should talk to five groups about dependencies: individual contributors, management, legal, the wider business, and the open source ecosystem. The OSPO book calls this the flower diagram, with one petal per group. Mapping each group to a message and a channel keeps governance from living in one team.
The flower diagram in short
The OSPO book's chapter on creating an OSPO says stakeholders are all the people affected by the work. The flower diagram helps to visualize the groups, with each petal representing a stakeholder group and its associated activities. It can also map the communication channels and documentation used with each group. The OSPO itself is one more petal.
The chapter's petals are individual contributors, management, legal, business, the open source ecosystem and the OSPO.
A dependency governance version
Here is how we would apply each petal to dependencies. The petal names and descriptions follow the book. The examples are ours.
| Petal | What they care about | What to bring them |
|---|---|---|
| Individual contributors | Getting work done without friction | A short usage policy, a fast request path, training |
| Management | Alignment with business strategy | One-page report on risk and progress |
| Legal | Legal requirements and obligations | Scan reports and license decisions to review |
| Business | Teams fitting together, sharing practices | Shared inventory and common process |
| Ecosystem | Healthy upstream projects | Plan for contributions, reports and support |
Questions to ask each group
Contributors. Where do you look for libraries? What makes our request process slow? The book describes this petal as needing a cultural change effort, so listen before you prescribe.
Management. Which products depend most on open source? What risk are you comfortable carrying? The book says this petal is about finding alignment between open source and overall business strategy.
Legal. What obligations do you need to see before release? Which license types need your direct review? Legal opinions belong to counsel, not the OSPO.
Business. Which teams build on each other's code? Who owns shared libraries?
Ecosystem. Which projects do we rely on that we have never talked to? The book says an OSPO engages with the ecosystem to exchange ideas, collaborate and contribute.
Do not forget regulators
The chapter treats external regulators as a special case outside the diagram. It lists government agencies, industry regulators and consumer protection agencies, and recommends planning how to approach and communicate with them and defining the roles they play in policymaking. If you work in a regulated sector, add a row to your map and ask your compliance team who owns that contact.
Turn the map into a calendar
For each petal, pick a channel and a cadence. For example, a monthly note to management, a quarterly session with legal, and a standing channel for contributors. Without a calendar, a map is just a diagram. See what an open source program office does for security for related context.
Try it yourself
Click through it at your own pace, or open it full screen. It shows how one set of evidence maps to several audiences, which is the same idea as a stakeholder map.
How Safeguard fits
Safeguard provides compliance and evidence automation and SBOM and dependency scanning, producing material you can share with legal, management and engineering. Try gold.safeguard.sh/scan.
Quick check
Do small companies need a stakeholder map?
A one-page version is enough. Even five names and five channels beat none.
Is the flower diagram required?
No. It is a tool from the OSPO book to visualize groups. Adapt or rename the petals.
Sources
Last reviewed: 19 October 2026.
