Who Should Own Your Shared Component Library

A shared component library needs exactly one owner, and that owner has to be accountable for the whole thing, not just their favorite parts. Ownerless libraries do not stay neutral. They rot. Every team adds a slightly different button, nobody deletes anything, and within a year the "shared" library is a museum of five ways to do the same thing. The fix is not more process. It is a single named owner with the authority to say no.

I own mine, because I run the portfolio solo, so this is easy for me to say and hard for a team to implement. But the principle holds at any size: shared code is a product, and products without an owner die.

Why ownerless libraries become dumping grounds

The failure mode is predictable. Team A needs a date picker. They build one and, feeling generous, drop it in the shared library. Team B needs a slightly different date picker. Instead of changing Team A's, which might break Team A, they add a second one. Now there are two. Multiply across every component and you have a library that is bigger than the sum of the apps that use it, which defeats the entire purpose.

This happens because contribution is easy and curation is nobody's job. Adding is rewarded. Deleting is scary. Saying "no, use the existing one" requires authority nobody has. So the library grows without pruning, which is the opposite of what belongs in a shared foundation. A foundation is defined as much by what you keep out as what you put in.

What ownership actually means here

Owning the library is not writing every component. It is being accountable for four things.

• The intake decision. Does this belong in the shared library at all, or should it stay in the app that needs it? Most proposed components fail this test. The owner enforces the rule of three instead of accepting every donation.
• The API. One button, with a considered set of props, not five buttons that drifted apart. The owner guards the interface so consumers can trust it.
• Deprecation. When two components overlap, one has to go. Someone has to decide which, mark the loser deprecated, and drive the migration. That is rolling out breaking changes across a portfolio, and it does not happen without an owner.
• The docs. A component nobody can find gets rebuilt. The owner keeps the self-serve docs current so consumers reach for what exists.

Notice none of that is "write more components." Ownership is mostly curation and refusal.

The bottleneck objection, and how to avoid it

The obvious worry: if one person owns the library, do they become the bottleneck every change waits on? They do, if you set it up wrong. The fix is to separate two rights. Anyone can propose and contribute. Only the owner can approve into the shared surface and only the owner can define the API. Contribution stays open. Curation stays centralized.

You also lower the pressure on the owner by keeping the shared surface small. The more you share, the more the owner has to govern. Share the stable, universal parts, and let the apps own their own quirky, fast-moving UI. This is the same balance as where to let portfolio apps diverge: centralize what benefits from being identical, decentralize what benefits from being free. An owner governing a tight core is not a bottleneck. An owner trying to govern every screen in every app is.

The owner's real job is saying no

The hardest and most valuable thing the owner does is reject good-faith contributions. Someone built a nice component. It works. It is just not general enough, or it duplicates something, or it will make the library harder to hold in your head. Saying no there feels ungrateful. It is the job. Every "no" keeps the library small enough to stay an asset instead of becoming the thing that slows everyone down.

A library that accepts everything is not shared, it is aggregated, and aggregation without curation is just a bigger mess in one folder.

If you are a team, name the owner today

Do not run this by committee. Committees add and never delete, because deleting requires someone to be wrong and nobody volunteers. Name one person. Give them the authority to reject and to deprecate. Make curation their explicit job, not a thing they do between real work.

I keep the shared component layer under one owner inside the build workflow at Bootspring, which is why a new product inherits a clean, single-answer library instead of a decade of accumulated variants. The library is only worth having if it stays smaller than the problem it solves. That takes an owner who will say no. Find that person and give them the pen.