For 1,000 or more engineers, a hybrid usually fits: a small central office sets standards and builds automation, while local reviewers decide most requests near the code. Routing every open source request through one team creates a queue that developers will route around.
The three models
| Model | How it works | Strength | Weakness |
|---|---|---|---|
| Central | One office approves every request | Consistency | Becomes a bottleneck, teams defer to it |
| Federated | Each business unit decides alone | Speed | Rules drift, duplicate effort |
| Hybrid | Central standards and tooling, local decisions | Speed with a shared baseline | Needs clear escalation rules |
What large programs report
The Linux Foundation guide gives concrete examples from large companies. One software company with some 60,000 engineers found that sending the details of every project through one office would have been overwhelmed and unworkable. Its office instead lets engineers make local decisions, with requests answered by local reviewers drawn from roughly 300 business and legal reviewer groups. It also uses an executive council made up of vice presidents from the major business units to guide policy and set priorities.
A search company's office, with about 15 team members serving a company of roughly 72,000 employees at the time the guide was written, describes its role as facilitating and advising. Business units decide whether to open source a project. The office includes a compliance team with two lawyers, an outreach team and an engineering team that builds tooling to automate compliance checks. Those figures are from the guide's snapshot and will have changed, so treat them as illustrations of shape, not current staffing.
A third company ran no central office at all and used a volunteer cross-functional working group instead. That worked for its decentralized teams, which shows that the right model depends on culture.
Principles that survive across sizes
- Eliminate, automate, delegate. The guide describes repeatedly asking why each policy exists, then removing it, automating it or handing it to local owners.
- Keep policy minimal. Every stakeholder wants to add a rule. Someone has to say no.
- Measure. One large program tracks statistics on what must be built to be compliant and how long code takes to be released or brought in.
- Train once, early. The guide mentions a one hour open source class for all new engineers at one company.
Escalation rules for a hybrid
A hybrid fails without a clear path upward. Write down:
- What local reviewers may approve alone (allowed licenses, common libraries).
- What must go to the central office (new license types, code that ships to customers in a new way, anything touching a regulated product).
- Who breaks a tie.
- How long each step may take. A queue with no clock is a refusal.
Tooling the central team owns
At this size the center earns its keep by building shared services: an inventory that spans every repository, policy checks that run in pull requests, a feed of advisories matched to what is actually deployed, and an evidence trail. Developers will accept a rule that runs for them in seconds far more readily than one that needs a form.
Safeguard offers SBOM and dependency scanning, reachability analysis, policies and gates, and asset discovery that a central team can run across many repositories. See a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how continuous checks replace a manual review queue.
Quick check
Is federated governance riskier than central?
It can be if rules drift. A shared baseline of standards, tooling and escalation rules reduces that risk without a central queue.
Who sets the standards in a hybrid?
A small central office, ideally with an executive council to settle priorities and policy changes.
Sources
Last reviewed: 19 October 2026.
