When the Meeting Is the Product: How Open Source Teams Get Buried in Their Own Process

There's a joke that circulates in open source communities every few months: the best way to kill a feature request is to ask for community consensus on it. Everyone laughs. Then everyone goes back to their GitHub threads and keeps debating.

It's funny because it's true — and it points to something that doesn't get talked about enough in conversations about open source sustainability. We spend a lot of time discussing burnout, funding gaps, and documentation problems. But there's a quieter drain happening in parallel: the sheer weight of running a distributed, community-governed project in the first place.

Call it the collaboration tax.

What the Collaboration Tax Actually Looks Like

In a traditional software company, someone with authority makes a call. Maybe it's the wrong call, but it gets made. Work proceeds. In an open source project — especially one without a clear benevolent dictator or a well-funded foundation behind it — that same call might live in a pull request comment thread for six weeks before anyone reaches a conclusion.

This isn't hypothetical. The Python community famously spent years navigating PEP processes that, while thoughtful and democratic, created real lag between good ideas and shipped features. The Node.js/io.js fork of 2014 was partly a response to a governance structure so slow that a chunk of the community decided starting over was faster than waiting. Even Linux, arguably the most successful open source project in history, has Linus Torvalds doing a job that exists specifically because someone needs to cut through the noise.

For smaller projects without that kind of central authority, the overhead compounds fast. Think about what a single contested architectural decision actually costs: the initial proposal, the counter-proposals, the async comment threads across time zones, the IRC or Discord debates, the revised proposal, the vote or rough consensus check, the documentation of whatever was decided, and then — finally — the implementation. By the time code gets written, a team of three full-time engineers at a startup would have shipped and iterated twice.

The Hidden Cost Nobody Budgets For

Most open source contributors are volunteers, which means their time is genuinely finite. A maintainer who spends four hours on a Saturday reviewing governance discussions is not spending those four hours fixing bugs or mentoring new contributors. That tradeoff is invisible in any project health dashboard, but it's very real.

Researchers studying open source project velocity have found that communication overhead scales nonlinearly with team size. Double the contributors, and you don't double the coordination cost — you might triple or quadruple it. Every new voice in a discussion adds potential value, but it also adds noise, edge cases to consider, and the social complexity of managing disagreement without anyone having formal authority to end it.

There's also the emotional labor dimension. Maintainers in distributed communities often describe feeling like unpaid community managers as much as engineers. Keeping discussions civil, helping newcomers understand context, mediating between factions with different visions for a project — that's real work, and it drains the same finite reservoir of energy that coding draws from.

When Process Becomes the Product

Some projects reach a point where governance discussions start to feel like the main output. RFCs get written about how to write RFCs. Working groups form to decide how working groups should operate. Contributors spend more time in meta-conversations about how decisions get made than in the actual decisions themselves.

This isn't always bad — early-stage projects genuinely need to build governance infrastructure, and getting it right matters. But there's a tipping point where process accumulates like technical debt: each individual layer seems reasonable, but the stack becomes so heavy that moving anything requires excavating through layers of prior decisions.

The Rust programming language community is an interesting case study here. Rust uses an RFC process that's genuinely rigorous and has produced a remarkably coherent language design. But contributors have openly acknowledged that the RFC process creates a significant barrier to contribution, and that some good ideas die not because they're bad, but because shepherding one through the full process is exhausting. The community is aware of this tension and actively debates it — which, somewhat ironically, is itself more process.

Patterns That Actually Work

None of this means distributed governance is doomed. Some projects have found real solutions, or at least workable compromises.

Lazy consensus — the practice of treating silence as agreement after a reasonable window — dramatically reduces the overhead of low-stakes decisions. Instead of requiring active approval, a proposal moves forward unless someone objects. It's not perfect for high-stakes choices, but it clears the queue of the dozens of small decisions that would otherwise clog a community's bandwidth.

Tiered decision authority gives different types of decisions different processes. Typo fixes and minor patches might need only one reviewer. New features might need a small working group. Major architectural changes might need full community input. This keeps the heavy machinery reserved for decisions that actually warrant it.

Async-first, but time-boxed. Some communities have started putting hard deadlines on discussion windows — a proposal is open for comment for two weeks, then whoever is responsible makes a call based on what came in. It's not fully democratic, but it prevents the indefinite-discussion death spiral.

Clear ownership without hierarchy. Projects like Kubernetes have module owners who have real authority over specific subsystems. You can still contribute anywhere, but there's a named human who makes the final call in their domain. It preserves community input while eliminating the paralysis of pure consensus.

The Deeper Question

Underlying all of this is a genuine tension that open source communities haven't fully resolved: the values that make open source meaningful — transparency, inclusion, collective ownership — are structurally in conflict with the values that make software ship fast — decisiveness, clear authority, reduced friction.

That's not a reason to abandon open governance. It's a reason to be honest about the tradeoffs. When a community chooses a fully democratic process, it's choosing to pay the collaboration tax. That might be absolutely worth it, depending on what the project is trying to be and who it's trying to serve. But pretending the tax doesn't exist, or that it's costless, leads to maintainers quietly burning out while wondering why nothing ever gets done.

The projects that seem to navigate this best are the ones that name the problem explicitly. They talk openly about process overhead, experiment with governance structures, and treat coordination as a real engineering challenge rather than an administrative nuisance.

Because at the end of the day, the goal isn't better meetings. It's better software — built by communities that are still standing when it ships.