Openbounty

Most bounty platforms bolt a payment layer onto open source and hope the incentives sort themselves out. Openbounty started from the opposite end: what is the single event that everyone already trusts? On GitHub, that's the merge. A maintainer merging a pull request is an unambiguous, tamper-proof signal that work was accepted. So I made that the only thing that can mark a bounty paid.

Everything else in the system is built to protect that one invariant.

The problem

Bounties have a trust problem in both directions. Contributors worry they'll do the work and the maintainer will ghost them. Maintainers worry they'll pay for a drive-by PR that breaks their codebase. And a new problem is arriving fast: some of that work is now done by AI agents, which maintainers have every reason to be nervous about letting near their repos.

I wanted a design where nobody has to trust the platform's judgment — where GitHub itself is the referee, and the rules for who is allowed to touch what are explicit and enforced up front rather than argued about after the fact.

What I built

Openbounty is a GitHub App plus a web platform that mirrors — never replaces — GitHub state. A maintainer installs the app on a public repo, runs an "agent readiness" wizard, and drops a /bounty $200 comment on any issue. That bounty appears on a public feed anyone can browse without logging in.

A contributor claims it, does the work, opens a PR that references the bounty, and the moment the maintainer merges, the bounty flips to completed and a payout is calculated. For this first version every payment is mocked — no real money moves — so the entire flow can be validated end to end before payment rails are ever connected. That was a deliberate scoping call: prove the mechanics first, add the risky money part once the mechanics are boring.

The interesting part: agents as first-class contributors

The design decision I'm most attached to is treating AI agents as real participants without pretending they're people.

Every agent belongs to exactly one human operator who is the legally accountable party — agents don't get their own accounts. An operator's agent claims a bounty through an API key, does its work locally, and uploads a PR draft rather than pushing straight to GitHub. The platform runs a sensitive-path check against the repo's policy (auth files, anything matching payment*, .env, keys) and surfaces exactly what the change touches. Only after the human operator reviews and approves does the branch actually get pushed and the PR opened — with an auto-comment disclosing which model produced it.

So the maintainer still owns the merge, the operator still owns their agent's output, and nobody is surprised by an AI quietly editing their secrets. The repo's policy — allowed contributor tier, sensitive paths, max files changed — is checked at claim time, not after the work is already done.

Earning trust instead of assuming it

Reputation is a three-tier ladder: new, verified, trusted. A brand-new account can only take small bounties on repos that allow newcomers. Fifteen clean merges and a near-zero dispute rate later, the cap comes off. Tiers are recomputed after every merge, dispute, and rating, so standing is always a function of actual shipped work rather than a profile you can decorate.

Maintainers get a matching signal in the other direction — an agent readiness score that rewards having a real README, a runnable test command, and CI, because those are exactly the things that let a contributor (human or not) succeed without a back-and-forth.

Where it stands

Right now Openbounty is a fully specified v1 with the data model, GitHub webhook handling, tier logic, and mock-payment flow designed and being built out. Real payment processing, private repos, and competitive multi-PR mode are deliberately out of scope for this pass — the goal was to get the trust mechanics right first. When real money is added, only two touch points change: funding initiation and payout dispatch. The rest of the machine stays exactly as it is.