Challenges of a federated contribution model

WHAT THIS TESTS Whether you understand that federation is not just opening a repo, but building the process and tooling that keep distributed contributions coherent.

A GOOD ANSWER COVERS Contrast the models: centralized gives a core team full ownership, strong consistency, and a single quality bar at the cost of throughput and product responsiveness; federated invites product teams to contribute, scaling velocity and grounding the system in real needs. The challenges of federation are mostly scaffolding. Technically you need automated quality gates: token-usage linting, accessibility tests, visual regression, API-convention checks, and CI that blocks non-conforming PRs. Organizationally you need an RFC or proposal process so new components are vetted before code, contribution guidelines, design and engineering review by the core team, and clear long-term maintenance ownership so contributed components do not rot. You also need to manage review load and incentives so teams contribute upstream rather than fork.

COMMON WRONG ANSWERS Assuming open PRs alone create consistency. Skipping the RFC step, leading to duplicated or off-pattern components. No automated gates, so quality depends on manual vigilance. Ignoring who maintains a contributed component after merge. Underestimating review throughput as a new bottleneck.

LIKELY FOLLOW-UPS How do you keep core review from becoming the new bottleneck? How do you enforce token and a11y standards automatically? How do you decide what gets accepted into core versus stays local? How do you handle maintenance of contributed components?

ONE CONCRETE EXAMPLE A product team needs a new Stepper. They file an RFC; the core team aligns it with existing patterns. Their PR runs CI gates for token usage, accessibility, and visual regression, then gets core review. On merge, the team is listed as co-maintainer, and the component appears in docs with the same quality bar as core-built ones.