Every design system team eventually has the same conversation about contribution.
It usually happens after a reorganization, or after a new VP arrives with strong opinions about platform teams being enablers rather than gatekeepers. The argument sounds reasonable: if product teams can contribute to the design system, the system grows faster, the DS team is less of a bottleneck, and adoption follows naturally from ownership.
All of this is true. It is also the fastest way to create a design system that is technically open and operationally ungoverned. The two outcomes are not mutually exclusive. They happen simultaneously, in the same sprint, with the best intentions.
Why Open Contribution Fails Without Structure
Open contribution fails for one reason: it solves the wrong problem.
The problem it appears to solve is throughput. Too many requests, not enough DS team capacity. Open contribution distributes the work.
The problem it actually creates is coherence. Distributed contribution without a shared standard produces components that solve specific problems brilliantly and integrate into the broader system poorly. Every contributor optimizes for their squad's use case. Nobody optimizes for the system's architectural integrity.
Six months later, the design system has forty-seven components, twelve of which overlap in purpose, seven of which contradict the token architecture, and three of which were built by people who have since changed teams and cannot be reached for questions.
I watched a contribution model arrive in an organization fully formed — documented, shared, announced. And then watched everyone proceed to treat it like a sidekick. Not because the model was wrong. Because nobody would admit they didn't actually know who does what, when, and where. So everyone used their best judgment and called it contribution governance. Side conversations replaced the process. Decisions happened in hallways and Slack threads and retrospectives where the model was politely not mentioned.
Thanks to WebMD, everyone is a doctor. Thanks to an underdefined contribution model, everyone is a design systems architect. The results are roughly comparable.
Open contribution is not a scaling strategy. It is a throughput strategy that creates a governance debt you will pay later, with interest.
What a Contribution Model Actually Requires
Four things. In this order. Before the first external PR is merged.
Requirement 1 — A Contribution Criteria
What qualifies as a candidate for the design system versus what belongs in a squad-specific component library?
The answer is usually: used by three or more squads, generic enough to work without squad-specific modifications, and aligned with the system's existing token architecture. Write this down. Make it public. Reject contributions that don't meet it — not with a Slack message, with a written decision that references the criteria.
A criteria that isn't written down isn't a criteria. It is a mood.
Requirement 2 — A Contribution Template
Every contribution submission must answer the same questions: What problem does this solve? Which squads use it? How does it map to the existing token architecture? What accessibility requirements does it address? What are the known edge cases?
The template does two things. It filters out contributions that haven't been thought through. And it standardizes the information the DS team needs to review a contribution efficiently.
Requirement 3 — A Review Process
Who reviews contributions? On what timeline? With what criteria? What happens to a contribution that is declined?
If the review process is undefined, every contribution becomes a negotiation. The loudest contributor wins. The most persistent contributor wins. The contributor with the best relationship with the DS team lead wins.
A review process that depends on relationships is not a review process. It is a favoritism model with extra steps.
The hybrid model that actually holds: assign the pre-merge review to a design manager who is already working on a related design task within the same scope. Not a random reviewer pulled from a list. Someone already context-loaded — aware of what the system is doing in that area, aware of what a conflict would look like before it lands. The review happens before the merge request is opened, not after. By the time it reaches the merge, the structural risk has already been assessed by someone with the right frame of reference to catch it.
This is not peer review. It is scoped review. The distinction matters. A peer can tell you whether the component works. Only someone already inside the relevant scope can tell you whether the component conflicts with something already in motion.
Requirement 4 — A Maintenance Agreement
Who maintains a contributed component after it ships? The contributing squad? The DS team? A shared responsibility model that nobody has defined?
Undefined maintenance is how design systems accumulate components that work until they don't, and nobody knows whose problem that is.
Turning Critics Into Contributors
The teams most likely to build workarounds are the teams with the highest-complexity use cases. They are also, if engaged correctly, the teams most likely to build the best contributions.
When a squad builds a workaround, the default DS team response is to document it as a known issue and add it to the backlog. The better response is to contact the squad and say: you identified a gap we didn't see. Would you like to help us close it?
Not every squad will say yes. Some will. The ones that do become the system's most credible advocates — because they built part of it, and they can say so.
The part most teams underestimate: the model alone is not enough. I have watched a contribution framework built by four design system managers — not one, four — specifically because making it function required a communication and accountability layer that no single person could hold. They called it a keep-me-honest framework. Not a governance document. An active commitment between people to call out when the process was being bypassed, when judgment was replacing criteria, when the model was becoming a sidekick again.
It is hard to be disciplined and creative at the same time. Most practitioners are better at one than the other. A contribution model works when someone in the room is willing to say: color between the lines. Not because the lines are sacred. Because without them, everything drifts — including the people who built the lines in the first place.
The Quick Win: Write the Contribution Criteria
Before accepting or rejecting the next external contribution — write the criteria. Three conditions that must be true for a component to qualify for the design system.
Share it with the contributing squad alongside the decision on their submission. Ask them:
"Does this criteria make sense to you? What would you add?"
Their response will either validate the criteria or improve it. Either outcome is useful. A criteria that survives challenge from the people it affects is a criteria that will hold.
The Argument
A contribution model is not a feature of a mature design system. It is a governance decision. Open it too early and you accelerate drift. Open it with structure and you scale the system through the people who use it most.
Disagree loudly. Inspire boldly.
And remind me — falsely if needed — that somewhere a contributed component passed review on the first submission and the criteria held.
Does your design system have a written contribution criteria, or a set of unwritten expectations that only the DS team fully understands? 🤔
