A bounty list, ten rows deep

A repository that is one Markdown table

The whole project is a README and a licence. The top level of the repository contains exactly two entries, LICENSE and README.md, and the README is a heading, a paragraph of intent and a table. The intent is worth quoting closely, because it defines the entry criteria: the goal is to make open source a better place by incentivizing people to work on it, and anyone who knows of another project that pays for contributions is invited to open a pull request. The rule that follows is short and strict, open-source only and must be paid. The table has seven columns, name, description, link, tech used, details, payment and getting started, and it currently holds ten rows with a comment at the bottom inviting the next addition. There is no tooling, no API, no website and no automation, which is worth stating plainly before anyone pictures a searchable bounty index.

What the payment column actually records

The amounts vary by three orders of magnitude, and the units are not consistent, which matters more than the range itself. RudderStack is listed at $2,000 USD per bounty for miscellaneous issues and bounties, and the BusKill row shows a $2,340 USD bounty less fees for a QubesOS contrib package. BountyBoard is a directory of multiple open source projects with a range of $10 to $5,000 per bounty. Expensify shows $250 to $500 per bounty, and tscircuit shows $5 to $300 per bounty through Algora. Trigger.dev shows $50 to $200 depending on the bounty. At the smaller end, openScale lists $30 for supporting a scale connection over MQTT and Etherpad lists $80. Appflowy is the outlier in structure rather than in size, since its payment is $500 per month under a mentorship program rather than a per-pull-request sum, and the Conquest of Our Ancestors row says $50 for the first bounty and more to be announced.

Reading the other columns without over-reading them

The tech column gives you a rough sense of the languages involved, and the range is wide: Go and TypeScript for RudderStack, Java and C++ for openScale, JavaScript for Etherpad, C++ for Conquest of Our Ancestors, Flutter and Rust for Appflowy, Next.js and TypeScript for Trigger.dev, JavaScript with Android and iOS for Expensify, QubesOS packaging with shell and Python for BusKill, and TypeScript with React for tscircuit. BountyBoard is marked as covering multiple programming languages, and its link goes to the site rather than a source repository. The details column describes the kind of work in loose terms, with several rows reading as miscellaneous issues and bounties, and one, tscircuit, describing bug fixes, features and improvements across a multi-repository ecosystem. The variation in the details column is the tell that this is a hand-maintained list rather than a taxonomy, which is fine for its purpose and a problem if you want to filter by task type.

The links point outward, and some are aggregators

Each row links to a getting started page, and those pages are of several kinds. Some point at a specific bounty issue, such as the openScale row pointing at a Bountysource feature request for scale support over MQTT, and the Appflowy row pointing at its mentorship programme documentation. Some point at a project's issue tracker in general, which is how Etherpad and Trigger.dev are listed, and Expensify points at a contributing guide in its repository. Three rows point to bounty aggregators rather than to the project directly: BountyBoard has its own site and an FAQ link, tscircuit routes through Algora's community bounties page, and BusKill links to a dedicated bounty page for the QubesOS package. That split is useful, because aggregators are where a search for available work actually happens, but it also means the list mixes a first-party process with a third-party marketplace without distinguishing them.

What the list does not record

Read the columns and notice what is absent. There is no date column, so nothing tells you when a bounty was posted or whether it is still open. There is no status column, so nothing distinguishes a live bounty from one that was paid out last year. There is no verification column, so the table asserts that each project pays without recording the evidence beyond the link. There is no note about payment terms, such as whether the amount is gross or net, whether it is paid per merged pull request or per completed task, or how long a contributor should expect to wait. The entry criteria themselves are minimal, which is a deliberate choice for a list that anyone can extend, and it is also the reason a reader should treat each row as a lead to check rather than an offer to accept.

The contribution model is a pull request to the table

Extending the list is the only way the project changes, and the mechanism is a pull request with a new row. The last line of the table is a comment inviting the next project to be added there, so a contributor adds a row and opens the pull request against a README. The licence is MIT and the default branch is main. The last push was on 2026-06-01, and the repository publishes no GitHub releases, which fits a repository whose unit of content is a row rather than a version. For a maintainer, that means the interesting work is curation, since a list that grows without review eventually becomes a directory of stale links, and the pull request process is the only filter available. There is no CI configuration, no linting of table syntax and no link checker in the top level entries, so nothing mechanically catches a dead link or a malformed row.

Where this list is the wrong tool

Three cases. The first is anyone who needs certainty about payment, because the list asserts rather than verifies, and the amounts and conditions live on the linked pages, which is where you have to go anyway. The second is a contributor who wants a steady pipeline of work, because a list of ten entries with no freshness signal is a set of one-off leads, and the aggregator links are the only part of it that behaves like a queue. The third is a search use case, since a Markdown table is fine for a human reading it in one sitting and useless for a tool that wants to filter by language, amount or task type. Against a bounty aggregator such as Algora or BountyBoard, the difference in approach is scope and context: an aggregator knows what is open right now and can be queried, while this list knows which projects are willing to pay and tells you where to look, which is a different question that a search engine answers badly and a hand-curated table answers well.

Editorial conclusion

paid-open-source-projects is a good fit for someone who wants a short list of places where a merged pull request can earn money, and who is willing to treat every entry as a lead rather than a fact. It is a poor fit for anyone who needs a curated, verified, current directory, because the table carries no dates, no verification and no status column, and an entry that was accurate in June can be dead in October. Check three things before you plan a contribution around it: that the linked bounty still exists on the project's own tracker, since the table points at issue pages and dashboards that change independently of this repository, that the payment is still on the terms described, which range from a flat thirty dollars to five thousand dollars per bounty and from fifty to two hundred dollars on Trigger.dev, and that the work fits the project's definition of open source and paid work, since the list's stated rule is open-source only and must be paid. Then treat the last push date, 2026-06-01, as the real expiry date on every row.

Frequently asked questions

Official sources

1. Issues
2. kunovsky/paid-open-source-projects on GitHub
3. License: MIT
4. README