Days 61–90 / Operate
Governance: who owns what
The contribution model, the deprecation policy, and the funding question that keeps the system alive.
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.
1 owner · low variance
Centralized
Carbon · Lightning
core + contributors
Federated
Polaris · Atlassian
many forks · no center
Open
shadcn · Radix
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.
- 01
Centralized
ProsHigh coherence, fast decisions.ConsBottlenecks, the team becomes a service org for the rest of engineering.
- 02
Federated
ProsDistributes the work, surfaces real product needs.ConsRequires real RFC discipline or you get drift.
- 03
Open
ProsNo organizational constraints, broad adoption.ConsEvery 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.
- 01What's changing
- 02Why
- 03What alternatives were considered
- 04What the migration looks like
Reviewers comment on the doc, not the PR.
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.
console.warn()The first time someone uses it after deprecation is announced.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.
Takeaways
- 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.