Open Source Management Operations
Management operations is where individual good decisions become an institutional capability. This domain tests the policies, tooling, and ownership model an enterprise needs to consume and produce open source at scale.
What an OSPO runs
An Open Source Program Office owns policy, inventory, approval workflow, compliance automation, security response, contribution approval, and training. Typical artifacts:
- A license policy with tiers: green (MIT, Apache-2.0, BSD) auto-approved; amber (MPL, LGPL, GPL for internal tools) requiring review; red (AGPL for distributed or SaaS products, unlicensed code) prohibited without executive sign-off.
- An intake workflow: request, automated license and vulnerability scan, project health check, decision, owner assignment, SBOM registration.
- CI enforcement, so policy applies to every build rather than to a quarterly audit.
- Patch SLAs by severity and a defined exit strategy for abandoned components.
- A contribution policy covering which projects employees may contribute to, who signs CLAs, manager and legal approval, and an upstream-first default.
Worked example
A team requests an AGPL-3.0 library for a SaaS product. Section 13 extends the source-offer obligation to users interacting with the software over a network, so the SaaS boundary does not avoid copyleft. Because the tier is red, the default answer is no; the team can seek a commercial license from the vendor, replace the library with a permissively licensed equivalent, or escalate to legal with a documented architecture that keeps the component out of the served process.
Traps
- Publishing a policy with no automated enforcement.
- Running a one-time license audit instead of continuous scanning and SBOM refresh.
- Overlooking that employee contributions raise IP and export-control questions.
- Confusing SBOM generation with compliance; the SBOM is evidence, not a decision.