Governance is the unsexy answer to the question of why some design systems thrive for a decade while others ship beautifully and die quietly within two years. The system that survives has clear answers to: who decides what ships, how external teams propose changes, when components get retired, and who pays for the maintenance.
There's no single right governance model. There's a model that fits your org's politics and one that doesn't.
Three governance models
Centralized: a single core team owns everything. Carbon, Lightning, Cloudscape. Pros: high coherence, fast decisions. Cons: bottlenecks, the team becomes a service org for the rest of engineering.
Federated: a core team owns the canonical components; product teams contribute through a public RFC process. Polaris, Atlassian. Pros: distributes the work, surfaces real product needs. Cons: requires real RFC discipline or you get drift.
Open: components are public, anyone can fork, the maintainers are upstream from any single product team. shadcn/ui, Radix UI. Pros: no organizational constraints, broad adoption. Cons: every consumer maintains their own version forever.
RFCs aren't optional
Every non-trivial change should start as a written proposal — what's changing, why, what alternatives were considered, what the migration looks like. Reviewers comment on the doc, not the PR.
Skipping the RFC layer feels faster in the moment and costs you 5x in the next twelve months when the same conversation has to happen three times.
Deprecation policy
Every component you ship gets a deprecation path before you ship it. Six months minimum notice. A console.warn() the first time someone uses it after deprecation is announced. A linter rule by month four. A removal in the next major after that.
Without a policy, components accumulate. Carbon and Polaris both publish deprecation status in their component docs — adopt the same discipline.
Funding the team
Headcount, on-call rotation, support tickets, design hours, eng hours. All of it gets allocated, all of it shows up in the org chart, all of it has someone accountable.
Systems that get funded out of someone's 20% time die. Systems that have a director and a roadmap don't.
- 01Three governance models — centralized, federated, open. Pick the one that fits your org's politics.
- 02RFCs before code. Reviewers comment on the doc, not the PR.
- 03Every component ships with a deprecation path. Six months minimum notice, console warning, lint rule, removal.
- 04Fund the team like a product team. 20%-time systems die.
Carbon Design (IBM)
Centralized governance with public RFCs and explicit deprecation discipline.
Polaris (Shopify)
Federated governance — central core, public contribution model, versioned ship discipline.
shadcn/ui
Open governance taken to its logical end — copy-paste, zero coupling, you own the code.