One Brain Shouldn't Hold the Keys: Rethinking How Open-Source Projects Survive Their Own Success

The Most Dangerous Sentence in Open Source

It usually sounds something like this: "Oh, you'll want to ask Jamie about that."

Maybe Jamie wrote the original networking layer. Maybe Jamie is the only one who remembers why the config file is structured the way it is, or why that one function has three redundant checks that nobody has touched in four years. Whatever the reason, when Jamie becomes the answer to every hard question, your project has a problem—even if Jamie is brilliant, dedicated, and going absolutely nowhere right now.

The issue isn't Jamie. The issue is that your project has quietly built a single point of failure into its most critical system: the people who understand it.

This is one of the most common ways successful open-source projects quietly set themselves up to collapse. Not through bad code or lack of contributors, but through knowledge that lives in one person's head and nowhere else. And unlike a broken build or a failing test suite, this kind of risk doesn't show up in your dashboards.

Why This Keeps Happening

It's not laziness and it's not negligence. Usually it's the natural result of how projects grow.

Someone starts a project, makes a thousand small decisions over months or years, and accumulates context that never gets written down because—why would it? They're right there. They can answer any question in a Slack message or a GitHub comment. Documentation feels redundant when the source of truth is always online and always helpful.

Then life happens. Burnout hits. A new job shows up. A family situation changes everything. And suddenly the project is left trying to reconstruct years of architectural decisions from commit messages and half-finished wikis.

The contributors who remain aren't incompetent. They're just working without a map.

What You're Actually Trying to Protect

Before you can fix the problem, it helps to name what's actually at risk. There are roughly three layers of institutional knowledge that tend to concentrate in a single maintainer:

Operational knowledge — How do you cut a release? Who has credentials to push to the package registry? What's the process for handling a security disclosure? This is the stuff that needs to happen on a schedule or in a crisis, and it's often the least documented because it feels too "obvious" to write down.

Architectural context — Why does the project work the way it does? What were the alternatives that got rejected, and why? What constraints shaped the early decisions that everything else now depends on? This is the hardest to transfer because it's not just facts—it's judgment.

Community knowledge — Who are the reliable contributors? Who has tried to cause problems before? Which long-running issues are actually political landmines? This social layer is almost never written down anywhere.

If any of these layers lives primarily in one person, you have a fragility problem.

Practical Ways to Spread the Knowledge Around

You don't need a formal governance structure or a DAO to fix this. What you need is intentional redundancy, built into your normal workflow.

Make Decision-Making Visible by Default

When the lead maintainer makes a significant call—merging a controversial PR, rejecting a feature request, choosing one library over another—that reasoning should live somewhere searchable. Not as a formal record, but as a natural byproduct of how the project communicates.

One low-friction approach: use Architecture Decision Records (ADRs). These are short markdown files, kept right in the repo, that document what was decided and why. They don't have to be long. Even a paragraph capturing the tradeoffs considered is infinitely more useful than nothing. Tools like adr-tools make this easy to standardize.

Rotate Who Does the Scary Stuff

If only one person has ever cut a release, that process is undocumented by definition—even if there's a runbook. The runbook only covers what that person thought to write down, not the fifteen small judgment calls they make without noticing.

The fix is to have a second person actually do the thing, with the first person available to answer questions. Then a third. This surfaces gaps in your documentation faster than any audit, and it builds a bench of people who can handle critical tasks without a safety net.

Create a "Bus Factor" Audit

This is blunt but useful: go through your project's critical functions and ask, for each one, "if this person got hit by a bus tomorrow, what breaks?" You're not being morbid—you're being honest about where your dependencies are. List the functions, list the people, and look for the names that appear on every line.

Then prioritize getting those specific areas documented or cross-trained. You don't have to fix everything at once. Even reducing your bus factor from one to two on your most critical systems is a meaningful improvement.

Build Onboarding That Assumes Nothing

Your contributor onboarding docs probably assume more than you think. Go back and read them as if you'd never seen the codebase. Better yet, have a new contributor follow them and watch what happens. Every time they get stuck and have to ask someone a question, that's a documentation gap.

The goal isn't a perfectly comprehensive wiki. It's a document that lets someone get oriented without requiring a personal tour from the one person who knows everything.

Give Other People Authority, Not Just Access

There's a difference between giving someone commit access and actually empowering them to make decisions. A lot of projects do the former without the latter, which means the key maintainer still has to sign off on everything—just with extra steps.

If you want institutional knowledge to spread, you have to let other contributors exercise judgment. That means accepting that some decisions will be made differently than you'd have made them. That's not a bug. That's what a resilient project actually looks like.

The Mindset Shift That Makes All of This Work

Here's the thing that doesn't get said enough: being the person everyone depends on feels good. It's validating. It's a sign that you've built something real and that your expertise matters.

But that feeling can quietly work against the project's long-term health. If deep down you're comfortable being the linchpin, you'll unconsciously resist the changes that would make you less essential.

The shift is recognizing that a project which can survive your absence is a more successful project than one that can't—not less. The goal of building in public, in community, is to create something that outlasts any single contributor's involvement. That includes yours.

Distributing knowledge isn't giving something away. It's the whole point.

Start Small, Start Now

You don't have to overhaul everything this week. Pick one thing: write the ADR for a decision that's been living in someone's head. Shadow the next release process instead of just reading about it. Ask a newer contributor to walk through your onboarding docs and report back.

Small moves, made consistently, are how you turn a single-point-of-failure project into something that can actually grow—and survive—without any one person holding all the keys.