A Letter to Every Open Source Maintainer
Before we talk about code, bots, or AI — let's talk about you.
You're at your day job. You have your own targets to hit, your own deadlines to meet, your own features to ship. And somewhere between all of that — you open GitHub to review a stranger's PR.
Not because someone pays you extra for it. Not because your manager told you to. But because you care about the project and the community around it.
You review PRs while balancing your own sprint work. You explain the same thing for the 50th time to a new contributor. You close duplicate issues politely between meetings. You do code reviews during your 8-hour workday while still being expected to deliver on your own targets.
That's not overtime. That's dedication squeezed into an already full day.
And lately, it's gotten harder. The AI era brought an explosion of contributions — some genuine, some... not so much. As Kevin Alemán beautifully put it in his blog post "In the AI Era, Code Is Cheap. Reputation Isn't.":
"Maintainer capacity did not increase. Review cost did not decrease."
"The cost of opening a PR is now near zero. The cost of reviewing it is not."
This post is about one solution I discovered — a tiny bot that quietly protects maintainers. And what we, as contributors, can learn from it.
The Problem: More Code, Same Humans
Let's be honest about what's happening in open source right now:
- AI makes it easy to generate PRs, issues, and even vulnerability reports in bulk
- Maintainers are still human — they have the same 24 hours, the same energy, the same patience
- Good contributions get buried under a pile of duplicates and low-quality PRs
- Duplicate work happens when 3 people unknowingly work on the same issue
Kevin shared something that hit hard — curl's maintainer had to ban AI-generated vulnerability reports because they were drowning in fake ones that looked legit but wasted hours of manual review time.
This isn't a problem with AI itself. It's a workflow problem. And one project solved it beautifully.
Meet Zulipbot 🤖
Zulip — the open-source team chat platform — built a small GitHub bot called zulipbot. It's open source (Apache 2.0), written in Node.js, and does something simple but powerful:
It puts structure around contributions.
How It Works
1. Issue Claiming
Instead of 3 people racing to PR the same bug, contributors comment:
@zulipbot claim
The bot assigns them and marks the issue in progress. Others can see it's taken. No duplicate work. No wasted effort.
2. One Issue at a Time
Here's the genius part — you can only claim 1 issue at a time. This means:
- No hoarding 10 issues and delivering nothing
- You finish what you start before taking more
- Maintainers deal with focused, completed work
3. Automatic Check-ins
Life happens. Sometimes you claim an issue and get busy. After 7 days of no activity, the bot gently asks:
"Hey, are you still working on this?"
If no response in 3 more days — it auto-unassigns, freeing the issue for someone else. No hard feelings. No awkward conversations.
4. Democratic Labeling
Normally on GitHub, only people with write access can add labels to issues — even the person who created the issue can't label it. That means maintainers have to manually label everything — more work on their plate.
Zulipbot changes this. Contributors can add labels to issues they've opened:
@zulipbot add "bug" "help wanted"
It's a small thing, but it adds up. When contributors can properly categorize their own issues, maintainers spend less time on triage and more time on what actually matters — reviewing code.
Why This Matters — A Maintainer's Perspective
Think about what this bot does from a maintainer's eyes:
| Without Bot | With Bot |
|---|---|
| Review 3 duplicate PRs for 1 issue | Review 1 focused PR |
| Manually chase inactive contributors | Bot handles it automatically |
| Explain "someone's already working on this" | Bot shows in progress label |
| Get flooded with notifications | Area-based teams filter alerts |
The bot doesn't replace maintainers. It protects their time.
And time is the most precious thing a maintainer has — because they're volunteering it.
What I Learned as a Contributor
Reading Kevin's blog and studying zulipbot changed how I think about contributing. Here are my takeaways:
1. Every PR Has a Hidden Cost
Kevin said it perfectly:
"Every PR has overhead: CI runs, notifications, review time, merge time, mental context switch."
Every contributor should ask themselves before opening a PR: "Am I reducing work for the maintainer, or adding to it?"
2. Claiming Prevents Chaos
A friend of mine — Vedant Gupta — recently started contributing to open source. He told me how he'd see an issue, start coding, and submit a PR — only to find 2 other people had done the exact same thing. That's 3x the review work for maintainers, and 2 contributors whose time was completely wasted.
A simple claiming system prevents this entirely. When you can see an issue is already claimed, you move on to something else. No wasted effort on either side.
3. Inactivity Tracking Is Kind, Not Harsh
At first, auto-unassign sounds aggressive. But it's actually the kindest thing for everyone:
- The contributor doesn't feel guilty about dropping something
- The issue doesn't stay stuck for months
- Someone else gets a chance to contribute
It's better than the awkward silence of a claimed issue with no activity for 6 months.
4. Structure Empowers New Contributors
When new contributors join Zulip and claim their first issue, the bot sends a welcome message with links to docs, community chat, and guidelines. It feels organized. It feels like the project wants you there and wants you to succeed.
Compare that to repos where you open a PR and... silence. For weeks. That silence is what kills contributor motivation.
A Proposal: Every Large OSS Project Should Have a Workflow Bot
Here's my honest take — every open-source project with 100+ contributors should consider a workflow bot.
Not because contributors are bad. But because good contributors deserve a structured environment.
Zulipbot is:
- Open source — github.com/zulip/zulipbot
- Apache 2.0 licensed — fork it, adapt it, use it
- Built on Probot — GitHub's official framework for bots
- Battle-tested — running in production across all Zulip repos for years
Any project can fork it and adapt it to their needs. The core features — claiming, inactivity tracking, labeling — are universally useful.
To the Maintainers Reading This
Thank you.
Thank you for squeezing PR reviews between your own deadlines. Thank you for explaining things patiently to beginners while your own sprint tasks are piling up. Thank you for keeping the lights on in projects that millions of people depend on.
You don't get paid extra for this. You don't get promoted for this. Your manager doesn't count it as a deliverable. Most of you don't even get a "thank you" in return.
Your work matters. And if a little bot can give you back even one hour a week — that's worth fighting for.
To the Contributors Reading This
Before you open that PR:
- ✅ Did you check if someone's already working on it?
- ✅ Did you run tests locally?
- ✅ Did you read the contributing guide?
- ✅ Is your PR solving ONE clear problem?
- ✅ Would you want to review your own PR?
As Kevin said:
"High quality contributions get reviewed faster. Low signal contributions accumulate."
In the AI era, anyone can generate code. But reputation is built by humans who care.
Links & Resources
- 🤖 Zulipbot Source Code — Fork it, study it, use it
- 📖 Zulipbot Usage Guide
- 🔥 Kevin's blog: In the AI Era, Code Is Cheap. Reputation Isn't.
- 💀 curl's AI slop ban — Why curl bans AI-generated vulnerability reports
- 🌟 Zulip Contributing Guide
If this helped you, share it with your open-source community. And next time you see a maintainer online — say thank you. They deserve it. ❤️
Connect with me: @NAME-ASHWANIYADAV
Top comments (0)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.