At 50 to 200 engineers, split open source governance across five named roles: a program owner, a legal reviewer, a security owner, team leads who decide locally, and an executive sponsor. The owner sets the rules, teams make most decisions, and legal and security step in on exceptions.
Why this size is different
Below 25 people, one person can hold the whole picture. Above a thousand, central review cannot keep up. In between, ad hoc habits stop working but a full office is overkill. The Linux Foundation guide describes the same tension: a program must offer structured policy but stay flexible, acting like a consultancy when developers need help, and avoid becoming a bottleneck.
The five roles
| Role | Typical holder | Owns |
|---|---|---|
| Program owner | A senior engineer or engineering manager, partly dedicated | Policy text, intake rules, the monthly report |
| Legal reviewer | In-house counsel or outside counsel on call | License tiers, contribution terms, release approvals |
| Security owner | AppSec lead | Advisory triage, patch timelines, exceptions on risk |
| Team leads | Each engineering manager | Day to day choices inside the rules |
| Executive sponsor | VP engineering or CTO | Resolves disputes, funds tooling |
The guide also describes a core compliance group, often called an open source review board, with engineering and product representatives, legal counsel and a compliance lead. At this size, treat that as a monthly meeting of the same five people, not a standing committee.
Who decides what
A responsibility table avoids arguments later. Adjust it to your company.
| Decision | Decides | Consulted |
|---|---|---|
| Add a library on the allowed list | Team lead | None needed |
| Add a library on the review list | Program owner | Legal |
| Use a not allowed license | Executive sponsor, by exception | Legal, security |
| Ship a vulnerable component with a documented risk | Security owner | Team lead |
| Publish company code as open source | Program owner | Legal, security, product |
| Contribute a fix upstream | Team lead | Program owner if beyond a small fix |
Notice that most rows resolve without a meeting. That is deliberate.
What to automate first
The guide's advice from large programs is to keep process streamlined and automate as much as you can. For this size, the first three automations are:
- A dependency inventory generated on every build.
- A pull request check that blocks components from the not allowed list.
- An advisory feed that opens tickets for components you actually ship.
Each removes a recurring question from the owner's inbox.
Common failure modes
- The owner becomes the approval queue. Fix it by widening the allowed list and trusting team leads.
- Legal is only called at release. Bring counsel into the license tier design early.
- No sponsor. Disputes then stall. Pick one person with authority.
- Policy written once. Put a six month review on the calendar.
Where Safeguard fits
Safeguard's SBOM and dependency scanning supplies the inventory, reachability analysis helps the security owner decide which advisories matter, and policies and gates enforce the rules in pull requests. Compliance and evidence automation helps collect proof for buyers. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a security owner triages findings without opening each one by hand.
Quick check
Do we need a dedicated open source person at 100 engineers?
Often a part-time owner is enough. If most of their week goes to repeat questions, consider making the role full time, as the Linux Foundation guide notes for programs that outgrow part-time management.
Who should the owner report to?
Engineering is a common home, with a legal partner. The right place depends on whether your main concern is IP, productivity or community.
Sources
Last reviewed: 19 October 2026.
