Open Source PR Backlogs: Why Your GitHub Contribution Sits Unreviewed for a Year

Key Takeaways

• A 49-line PR has sat unreviewed for over a year in Jellyfin's backlog
• CPython has 2,200+ open PRs with only ~30 core devs to review them
• 60% of open source maintainers have quit or considered quitting according to 2024 Tidelift survey
• Only 6% of a contributor's 368-day wait involved actual review activity
• The fix isn't more maintainers but changing how work flows through existing ones

Here's a number that should make you uncomfortable: 345 days. That's how long one developer spent waiting. Not coding. Not responding to feedback. Just waiting for someone to look at their work.

The developer, Arman Ckeser, has been trying to add a simple feature to Jellyfin Web for over a year. The feature? A timeline that shows you which subtitle appears when you're adjusting offset. You know, so you're not just blindly guessing. Pretty reasonable ask. Small scope. Isolated code.

They opened three PRs. Got two approvals. Zero merges. The smallest PR is 49 lines added, zero deleted. It has never received a single human review.

This Isn't Just a Jellyfin Thing

Look, I get it. You might be thinking this is some niche media server drama. But pull back the camera and the same pattern shows up everywhere.

CPython. The reference implementation of Python. The language that powers half the internet's backend. They have over 2,200 open pull requests right now. At the 2022 Python Language Summit, a core developer gave a presentation specifically about this backlog nightmare. The chicken-and-egg problem is brutal: no active reviewer for a module means no reviews happen, which means no new reviewers get trained on that module.

Evan You, the creator of Vue.js, has talked publicly about how the issue volume became impossible to manage as the project scaled. And he's one of the lucky ones with actual funding.

“The backlog sucks… for everyone. Every second I'm not reviewing makes it worse.”

— Jellyfin maintainer

The Burnout Numbers Are Brutal

A 2024 Tidelift survey dropped some stats that should concern anyone who depends on open source software. Which is, you know, everyone.

A Ford Foundation report found that the vast majority of open source projects are maintained by one or two people. Not teams. Not organizations. Individual humans who probably have day jobs and families and the audacity to want weekends off.

So when Jellyfin's maintainer says there's only one person doing reviews, that's not an excuse. That's the norm. And that's terrifying when you realize how much critical infrastructure runs on these projects.

The Queue Math That Explains Everything

Here's where it gets interesting. Ckeser didn't just complain about wait times. They brought receipts from queuing theory.

Think about it like a highway. When traffic is at 50% capacity, everything flows fine. At 80%? Things slow down but work. At 95%? Total gridlock. Small increases in load cause exponential increases in wait time.

Open source review queues work the same way. When a single maintainer is already at capacity, every new PR doesn't just add linearly to the backlog. It compounds. The death spiral kicks in.

And here's the kicker: slow feedback wastes everyone's time. That contributor who waited 345 days? They could have spent that time contributing elsewhere. The maintainer who eventually reviews a year-old PR? They're reviewing code written against an old codebase that might need complete rewrites to merge cleanly.

What Could Actually Fix This

The obvious answer is "hire more maintainers." But that's not really an answer. Most projects can't pay anyone. And even if they could, onboarding new reviewers takes time from... existing reviewers. The chicken-and-egg strikes again.

Ckeser proposed some process changes that don't require more humans:

• Cap PR size so reviews are faster and less intimidating
• Gate quality before it reaches the bottleneck with automated checks and proposal requirements
• Limit work in progress so partially-reviewed PRs don't pile up
• Prioritize by value over size because a 10-line security fix matters more than a 500-line feature
• Set a review cadence so contributors know when to expect feedback
• Build reviewer tiers where experienced contributors can handle initial reviews
• Require proposals for features so big changes get discussed before code is written

None of these are revolutionary. They're borrowed from manufacturing, from Kanban boards, from literally any field that's thought about throughput and bottlenecks. But open source projects rarely adopt them because "we've always done it this way" is a powerful force.

The Real Point

Ckeser ends their post with something important. This isn't really about their Jellyfin feature. They can live without fancy subtitle offset visualization. The point is that open source has a structural problem that's burning out maintainers and wasting contributor effort at massive scale.

When 60% of maintainers are thinking about walking away, that's not individual burnout. That's a systemic failure. The code that powers your phone, your car, your medical devices, your bank? A lot of it depends on people who are one bad week away from deleting their GitHub account.

“I think the fix is not 'find more maintainers.' It is changing how work flows through the one maintainer you have.”

— Arman Ckeser

Companies that depend on open source need to think harder about this. Not just throwing money at projects, though that helps. But investing in tooling, in process improvements, in anything that reduces the cognitive load on that one person standing between your infrastructure and chaos.

What Can Contributors Do?

If you're someone who contributes to open source, a few things might help your PRs move faster:

1. Keep PRs small. Really small. Smaller than you think.
2. Front-load context. Explain what the PR does, why it matters, and how to test it.
3. Respond to feedback fast. Stale PRs sink to the bottom of the mental priority list.
4. Consider opening an issue or proposal first for anything non-trivial.
5. Be patient but visible. A polite ping after a few weeks is fine. Daily messages aren't.
6. Offer to help review other PRs. Reduces maintainer load and builds trust.

But honestly? Sometimes you do everything right and your PR still sits for a year. That's not your fault. The system is broken, and individual actions can only do so much against exponential queue math.

Open source built the modern internet. But the way we maintain it hasn't scaled with its importance. Until that changes, your PR might be waiting a while. Grab a coffee. Maybe two. Actually, grab a subscription to a coffee service. You're gonna be here for a bit.

Source: Hacker News: Front Page