Open source software is often described in terms of contributions: who wrote what, which patches landed, how many commits a person has. That framing makes sense for a lot of purposes. But it leaves out a large category of work that doesn't show up in the git log and that the whole system depends on.
I spent several years as a Project Team Lead (PTL) for quality assurance projects in the OpenStack upstream community. That title meant I was one of the people with merge access across a set of repositories, responsible for keeping the review queue moving, hosting community meetings, and making the final call on whether a change was ready to land. Here's what that actually looked like.
What a PTL actually does
My scope as a PTL covered around ten to fifteen projects (think GitHub repositories), with five of them being genuinely active. Being one of the core people who could approve and merge pull requests sounds prestigious. In practice it meant living in a review queue.
My backlog was my inbox. Unread email notifications meant a patch was waiting for attention: either a new pull request, or an existing one where the contributor had pushed a new set of changes. At any given moment I had fifteen to twenty of those sitting there. Some were straightforward: CI jobs green, change clearly scoped, quick to assess. Others were structural changes that took half an hour just to reload enough context to evaluate safely.
Once a week I hosted an office hour on IRC, open to anyone in the community. Contributors showed up with questions about patches that had stalled. Engineers from other projects came when something in our testing framework had broken their CI and they needed to know if we were aware and working on it. Occasionally someone appeared with a dependency: they needed a specific change merged because their own project was blocked on it. My job in those sessions was less technical and more coordinative: figure out who owns what, route the right problem to the right person, keep things moving.
The reviews themselves were methodical. Syntax and semantics, obviously. But also: does this change break anything that was working before? Is it consistent with the project's direction and the existing codebase? Does the test coverage reflect what was actually changed? For simple patches with clean CI results, the bar was quick to clear. For anything that touched the project's structure, I needed to understand not just what the code did but why the original code was written the way it was.
The weight of the merge button
OpenStack runs in production for a significant number of organisations. When I merged something, it went into projects that other teams, other companies, and other open source projects depended on. That's not an abstract responsibility. It's a concrete one.
The thing that made it manageable was test coverage. The more CI jobs we had validating a change, the more confident I was that merging it was safe. Tests passing across the matrix didn't guarantee nothing would break, but it gave you a reasonable basis for a decision. And if something did slip through, we could always revert quickly or propose a fix and get it in fast.
I also never worked alone in any meaningful sense. If I wasn't sure about something, I'd ask on the upstream channel. Open source communities (at least in my experience) are genuinely helpful when you reach out directly. And if a change touched a part of the codebase I didn't fully understand, I didn't merge it. I'd flag it for someone who did, and ask them to weigh in. That might feel like a limitation. I think it's the right instinct: the PTL role requires being comfortable making decisions under uncertainty, but it doesn't require pretending you understand things you don't.
Why good maintainers burn out
The frustration isn't dramatic. It accumulates.
You review a patch. You leave specific, actionable feedback. The contributor comes back two weeks later with a new patchset, and the thing you pointed out is still there, unchanged, as if your comment was never read. Or the gap between your review and their response stretches to a month. By then the context you loaded the first time is gone, and you have to go back through the whole history of the patch to give a useful second review. That's not the contributor's fault, necessarily. Life gets in the way. But the cost lands on the maintainer.
Short feedback loops matter. This is something I've carried into how I manage engineers now: reviews are treated as priority work, not something you get to after everything else. A patch sitting without a review means nothing moves forward. The maintainer waiting for a revised patchset has the same problem in reverse.
The other burnout vector is continuity. When a maintainer moves on to a different project or gets pulled in a different direction, the projects they leave behind feel it. If enough people drift away, you end up with a project where nobody holds the deep context for certain parts of the codebase. Patches in those areas become hard to review not because they're bad, but because nobody left can confidently say whether they're safe.
One thing that didn't bother me, for the record: my name not appearing in commit messages. The contributor implemented the change. They deserve the credit for it. My reviews and merge decisions were tracked in Gerrit, the code review platform we used, so the work wasn't invisible to anyone who looked. But the broader point stands: the work of reviewing, coordinating, and maintaining rarely gets the same visibility as the work of building.
What would actually help
OpenStack is a specific case. It's backed by large companies (Red Hat, Canonical, IBM, and others) who pay engineers to contribute, maintain, and advance the project. That model works, when you have that kind of institutional support behind you.
But most open source projects aren't OpenStack. The ecosystem is full of small, unglamorous projects: JavaScript utilities, Python libraries, testing tools, small parsers and formatters. Many of them are dependencies for thousands of other projects, which are in turn used to build products that generate real revenue for companies that have never contributed a line back. The maintainers of those projects are often one or two people working in their spare time, and they carry the same review burden, the same merge responsibility, and the same coordination overhead as anyone else.
What would help is some mechanism for the companies and teams that depend on these projects to channel resources back toward the work they need done. Not donations to an abstract fund, but something more direct: a way to attach real value to specific problems, so that contributors have a reason to pick them up and maintainers have a reason to prioritise reviewing them. The incentive structure of open source is currently asymmetric in a way that makes this kind of sustainability hard. That asymmetry is worth fixing.