Forem: Ashwani Yadav

The Unsung Heroes of Open Source — And the Bot That Has Their Back

Ashwani Yadav — Sun, 08 Mar 2026 12:08:22 +0000

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

How Background Jobs Actually Work in Rocket.Chat — A Deep Dive into Agenda

Ashwani Yadav — Sat, 07 Mar 2026 14:04:25 +0000

You know that feeling when you look at an open source codebase for the first time and think, "Wow, this is massive, where do I even start?"

That's exactly how I felt when I started exploring Rocket.Chat. I was curious about one specific thing: how does Rocket.Chat handle background tasks? Things like cleaning up old files, syncing users from LDAP, sending scheduled reports — all the stuff that happens behind the scenes while you're busy chatting.

Turns out, the answer is a library called Agenda, and how Rocket.Chat uses it taught me a lot more than I expected.

Why not just use `setInterval`?

This was my first question. Node.js already has setInterval. Why bring in a whole library?

Think about it:

Server crashes? Your setInterval is gone. The job never runs again until someone manually restarts things.
Running multiple instances? Great, now the same job runs 3 times simultaneously on 3 different servers. That's not a feature, that's a bug.
No history? Good luck figuring out when something last ran, or why it failed.

Agenda solves all of these by storing jobs in MongoDB. The database becomes the single source of truth. If a server goes down, another one picks up the job. If two servers try to grab the same job, MongoDB's atomic operations ensure only one wins.

It's basically setInterval that survived the chaos of distributed systems.

Rocket.Chat doesn't use Agenda directly

Here's something I didn't expect: Rocket.Chat maintains its own forked version of Agenda. Check packages/agenda/package.json:

"description": "Fork of https://github.com/agenda/agenda"

This fork lives locally in the monorepo, which means Rocket.Chat has full control over the scheduling behavior without depending on upstream releases.

The Three Layers

After reading through the code, I noticed Agenda is used in three distinct layers:

Layer 1: The Engine (`packages/agenda`)

This is the raw scheduling engine. The core Agenda class in Agenda.ts handles everything: database connections, job definitions, polling MongoDB every minute to find due jobs, locking them with atomic findOneAndUpdate, executing them, and managing concurrency limits.

Layer 2: The Wrapper (`packages/cron`)

Rocket.Chat built a wrapper called AgendaCronJobs on top of the engine. It does two key things:

1. Simplifies the API:

cronJobs.add('VideoConferences', '0 */3 * * *', async () => {
  await expireOldConferences();
});

2. Records execution history:

Every time a job runs, the wrapper logs it to rocketchat_cron_history:

const { insertedId } = await CronHistory.insertOne({
  intendedAt: new Date(),
  name: jobName,
  startedAt: new Date(),
});
// job runs...
await CronHistory.updateOne(
  { _id: insertedId },
  { $set: { finishedAt: new Date(), result } }
);

This is invaluable for debugging — you can see exactly when a job ran, how long it took, and whether it failed.

Layer 3: The Actual Jobs

These are spread across the codebase. They don't care about MongoDB or locking. They just say "run this function on this schedule" and the layers below handle the rest.

A good way to think about it:

Layer 1 = the postal system (handles delivery logistics)
Layer 2 = the post office (accepts your letter and tracks it)
Layer 3 = you writing the letter (just defines the content)

The `IJob` Interface — What Gets Stored

Reading packages/agenda/src/definition/IJob.ts was eye-opening. Every job in MongoDB has these fields:

interface IJob {
  name: string;              // Job identifier
  nextRunAt?: Date | null;   // When it should run next
  type?: 'once' | 'single' | 'normal';
  repeatInterval?: string;   // Cron expression
  lastRunAt?: Date;          // When it last started
  lastFinishedAt?: Date;     // When it last completed
  lockedAt?: Date | null;    // Lock timestamp
  disabled?: boolean;        // Can disable without deleting!
  failedAt?: Date;           // When it failed
  failReason?: string;       // Error message
  failCount?: number;        // Cumulative failure count
  priority?: number;         // Execution priority
  data?: Record<string, any>;
}

A few things stood out:

disabled: There's already built-in support for disabling jobs without removing them. The engine checks disabled: { $ne: true } when finding the next job to run.
lockedAt: This is how Agenda prevents duplicate execution across servers. Once a server locks a job, others skip it.
failCount + failReason: Error tracking is built into the data model. You don't need external monitoring to know how often something fails.

The Job Class Has More Than I Expected

Looking at Job.ts, I found methods I wasn't expecting:

// Built-in disable/enable
disable(): Job { this.attrs.disabled = true; return this; }
enable(): Job { this.attrs.disabled = false; return this; }

// Status check
isRunning(): boolean {
  if (!this.attrs.lastRunAt) return false;
  if (!this.attrs.lastFinishedAt) return true;
  if (this.attrs.lockedAt && 
      this.attrs.lastRunAt.getTime() > this.attrs.lastFinishedAt.getTime()) {
    return true;
  }
  return false;
}

So the infrastructure for checking job status and toggling jobs on/off already exists at the engine level. That's pretty cool.

How a Job Actually Runs — End to End

Following a job from schedule to execution was one of the more interesting exercises:

1. Registration — cronJobs.add() calls agenda.define() to register the handler, then agenda.every() to set the schedule.

2. Polling — Every minute, Agenda queries MongoDB for jobs where nextRunAt <= now AND disabled !== true AND lockedAt is null or expired.

3. Locking — findOneAndUpdate atomically sets lockedAt = new Date(). Because it's atomic, even if two servers query simultaneously, only one gets the lock.

4. Execution — The handler runs. Events fire: start → success/fail → complete.

5. Cleanup — lockedAt is set to null, nextRunAt is recalculated from the cron expression.

6. Lock Expiry — Default lock lifetime is 10 minutes. If a server crashes while holding a lock, after 10 minutes another server can reclaim the job. Self-healing.

Jobs Are Everywhere (Not Just `server/cron/`)

This was my biggest surprise. I assumed all background jobs lived in apps/meteor/server/cron/. That folder has 6 files — NPS surveys, OEmbed cache cleanup, video conference expiry, etc.

But when I searched the entire codebase for cronJobs.add(, I found 19 distinct jobs registered across many different modules:

Core (6): NPS, OEmbed cleanup, usage reports, video conferences, temp file cleanup, user data exports
System (4): Version checking, cloud workspace sync, retention policy pruning, Smarsh compliance exports
Authentication (5): CROWD sync, LDAP sync (with 4 sub-jobs: user sync, avatar sync, auto-logout, attribute-based access control)
Apps (2): Marketplace update checks, app request notifications
Livechat (2): Business hour scheduling, daylight saving time adjustment

Each module has its own patterns too. Some jobs have fixed schedules (run at 2 AM daily), some are setting-driven (admin changes frequency from the UI), and some use random offsets — like Cloud Workspace Sync which picks a random minute to prevent all Rocket.Chat instances from hitting the cloud API at the same time:

const minute = Math.floor(Math.random() * 60);
await cronJobs.add(licenseCronName, `${minute} */12 * * *`, ...);

There Are Actually Two Scheduling Systems

Here's something that took me a while to piece together. Rocket.Chat doesn't have just one scheduling system — it has two:

1. Core Cron Jobs → Use the AgendaCronJobs wrapper → Store jobs in rocketchat_cron → History goes to rocketchat_cron_history

2. Apps Engine Scheduler → Uses its own separate Agenda instance via AppSchedulerBridge → Stores jobs in rocketchat_apps_scheduler

The Apps Engine (Rocket.Chat's app framework) has a completely independent scheduler. When a marketplace app registers background tasks, those go into a different MongoDB collection entirely. Different Agenda instance, different collection, different lifecycle.

This means if you ever wanted a complete picture of all background tasks running in a Rocket.Chat instance, you'd need to look at three separate collections, not two.

What I Learned

1. Read the code, not just the docs.
I understood locking by reading _findAndLockNextJob(), not by reading about it. Documentation gives you the "what." Source code gives you the "how" and "why."

2. grep is your best friend.
I only found 19 jobs because I searched the entire codebase for cronJobs.add( instead of just browsing one folder. Assumptions about where code lives will mislead you.

3. Layered architecture makes complexity manageable.
The person writing an NPS job doesn't need to know about MongoDB locking. The layers abstract that away beautifully.

4. Background jobs are invisible infrastructure.
Users never see them, but without them, files don't get cleaned up, licenses don't sync, old messages don't get pruned, and LDAP users fall out of date. They're the unsung heroes of the application.

If you're exploring a large open source codebase, I'd recommend picking one system and following it end-to-end. Don't try to understand everything at once — just pick a thread and pull it.

Happy exploring! 🚀