How to Run a Bounty Program for a Developer Community at Every Size

📌 How to run a bounty program for a developer community: keep four parts in every bounty, scope, acceptance criteria, reward and a decision deadline. Then expect a different failure at each size. Definition fails first, review capacity second, coordination third, payout operations last. Track the share of bounties that reach paid and treat a recurring bounty as a product gap or an unposted job.

---

What a bounty actually is

A bounty is a scoped task with a written standard for acceptance, a published reward and a date by which somebody decides. Four parts, every time, no exceptions for small ones. Most programs launch with two of the four. There is a task, roughly described, and a reward. The acceptance standard lives in somebody's head and the decision happens whenever a maintainer has an afternoon free. That combination is not a pipeline, it is an invitation to a disagreement, and the disagreement happens in public in front of the people you are trying to recruit. The useful way to think about a bounty program is as a contribution pipeline. Contribution comes in, review happens, value comes out, payment closes it. Every failure below is a stage of that pipeline breaking under load.

Around a hundred members: definition breaks

At this size everything is a conversation, which is exactly the problem. Everyone in the room shares so much context that nobody writes anything down. So the first bounty gets posted as a sentence. Somebody builds something adjacent to what you meant, submits it with genuine effort, and now you are choosing between paying for work you cannot use or declining work you arguably asked for. Both outcomes cost more than the bounty was worth.

Write acceptance criteria before posting, and write them as a list somebody could check without asking you a question. If you cannot express the standard as a checklist, the task is not ready to be a bounty.

What this stage needs is small and non negotiable. A one page template. Scope in two sentences, criteria as a checklist, reward stated in plain terms, decision date. That template is the entire program at this size and it is enough.

Around a thousand members: review capacity breaks

The program works, word spreads, and submissions start arriving faster than anyone looks at them. This is the failure that kills the most bounty programs, and it never looks like a failure while it is happening. Everything appears healthy. Bounties are posted, people are submitting, engagement is up. Meanwhile three submissions from last month have had no response, and the developers who wrote them have quietly concluded that this program is decorative.

What to add	Why it holds
One named reviewer per bounty	A team is not an owner, and shared ownership means nobody reviews first
A published review window	Contributors plan their time around it, and it makes lateness visible internally
A cap on open bounties	Never post more than your reviewers can judge in a week, no matter how many good ideas exist

The cap is the part teams resist. It feels like limiting growth. It is actually the only way to keep a promise, and a program that keeps promises grows faster than one that posts more.

An unreviewed submission does more damage than a bounty you never posted, because it converts a willing contributor into a person with a story.

Around ten thousand members: coordination breaks

Now you have volume, and volume produces two new problems that have nothing to do with quality. The first is duplicate work. Four developers see the same open bounty, four developers build it, one gets paid and three are annoyed, and two of those three will not come back. Nobody did anything wrong, they simply had no way to know. The second is reward farming. A minority will submit the smallest thing that might qualify, at volume, hoping something lands. This is a natural response to loose criteria, not a character flaw, and it is fixed structurally rather than by moderation. Both are solved by making state visible. BOUNTY BOARD STATES

OPEN	anyone may claim
CLAIMED	one person, expires after a stated period, then returns to OPEN
IN REVIEW	submitted, named reviewer, decision date shown
PAID	closed, contributor credited publicly
DECLINED	closed, reason published against the criteria

RULES
- one active claim per person
- claims expire automatically, no negotiation required
- criteria cannot change after a bounty is claimed
- declined submissions cite the specific criterion that failed

That last rule does quiet, important work. A decline that points at a checklist item is a technical judgement. A decline without one is an opinion, and opinions get argued with.

Around a hundred thousand members: payout operations break

At this size the hard part is no longer technical review. It is money, identity and trust. Payments across regions with different requirements. Verifying that the person being paid is the person who did the work. Disputes that need a real path rather than a conversation with whoever answers first. And the reputational asymmetry that defines this stage: one unpaid or badly handled bounty becomes a permanent, portable story about your company, told in rooms you are not in. Three changes carry the weight.

1. Move payouts to a function whose job is payouts. Finance or operations, with a defined process. A community team improvising payments is a risk to the community team and to the company.
2. Publish a dispute path. Who reviews a contested decision, in what window, and what evidence they consider. Publishing it prevents most disputes from escalating, because a visible process reads as fairness.
3. Cap individual bounty size and use contributor tiers. Small scopes for new contributors, larger scopes unlocked by a track record. That way no single bounty can become an incident, and your most reliable people get access to the work worth doing. A bounty program at this size is a payments operation with a technical review attached, and treating it as a community activity is how companies end up with a public grievance instead of a contributor pipeline.

The number that proves it works

Share of bounties that reach paid. Not bounties posted, not submissions received, not participants. The percentage that made it all the way through the pipeline to a paid, credited outcome. That single figure captures definition quality, review capacity, coordination and payout function at once, because a failure in any of them shows up as work stuck before paid. Run median days from submission to decision alongside it. Together they tell you whether the pipeline moves and whether it delivers.

When a bounty is the wrong tool

Two signals worth watching for. If the same bounty keeps recurring, it is not a bounty. It is either a product gap that should be on a roadmap or a role you have not posted yet. Paying repeatedly for the same missing thing is more expensive than fixing it once. And if you are using bounties to compensate for missing documentation, stop and write the documentation. A bounty asks somebody to do work. Documentation removes the work permanently, for everyone, and it does not need a reviewer every time.

Where this layer sits

Contribution is one layer of a community operation. Onboarding decides whether a developer ever reaches a bounty board. Support routing keeps confused questions out of the submission queue. Recognition and roles are what make a paid contributor stay after the payment clears. Reporting is what turns all of this into something leadership will keep funding. A bounty program built without those around it produces transactions. Built inside them, it produces contributors, which is a considerably better return on the same budget.

Do this before your next bounty

• Write the four part template and use it for every bounty, including small ones
• Name a reviewer and a decision date on each open bounty
• Cap open bounties to what your reviewers can judge weekly
• Publish a board with the five states visible
• Add a claim step with an automatic expiry
• Write the dispute path before you need it
• Start measuring the share of bounties that reach paid

---

Developer communities are unusually good at spotting a process that does not respect their time. The programs that earn contribution are the ones where the standard was written first and the decision arrived when promised. Build that, and the rewards become the smaller part of why people show up. More at danieljeong.org.