Why Open Source Bounties Always Failed – And How to Finally Fix Them

Posted by

–

Open source powers the modern software economy. A 2024 Harvard Business School study put the replacement cost at $8.8 trillion – 3.5× what companies currently invest in it.[1] Yet the people who maintain it are mostly unpaid volunteers. The irony is brutal: trillion-dollar companies run on goodwill.

Bounty platforms wanted to fix this. The idea was elegant. Let companies post money on specific GitHub issues, let developers compete to solve them, and pay out when the code ships. Everybody wins. So why did the most prominent attempt, Bountysource, end in bankruptcy, unpaid developers, and community trauma?

Bounties aren’t a bad idea. The execution, however, had deep structural flaws – in trust, incentives, and accountability. Let’s break each one down.


1. The Bountysource Collapse: What Actually Happened

Bountysource was the largest open source bounty platform ever built. At its peak, it touched over 55,000 GitHub issues and powered bounties for projects like Nextcloud, Elementary OS, and Borgbackup.[2] It had real momentum and genuine community goodwill.

Then it changed hands. CanYa, a cryptocurrency company, bought it in 2017. The Blockchain Group, a French firm, acquired it again in 2020.[3] Shortly after, the company quietly rewrote its terms of service to keep unclaimed bounties after two years. Effectively pocketing developer earnings. Community backlash forced a reversal, but trust was already gone.

By June 2023, developers with verified, completed claims began reporting that payouts simply stopped. Some waited seven weeks, then months, with no response.[6] By November 2023, The Blockchain Group announced bankruptcy leaving at least $21,000 in documented unpaid claims, and almost certainly much more.[2] The NewPipe project alone lost approximately €6,400.[4] The NewPipe project alone lost approximately €6,400.[4] FreeCAD had $4,279 sitting on the platform with no way to recover it.[5] Individual developers watched years of earned money evaporate.

After that, the community absorbed the loss quietly. “There has been shockingly little discussion of this event,” wrote one post-mortem. “The voices of developers who lost thousands of dollars were never amplified.”[2] That silence is part of the problem. It means the industry hasn’t properly reckoned with why it happened.

The root cause was structural. Bountysource held developer funds in a pool it fully controlled. When the business collapsed, creditors – not developers – had first claim on that money. Nothing guaranteed the funds belonged to the people who earned them.


2. Crypto Complexity Made It Worse, Not Better

Gitcoin was the other major bounty platform. It was built from the ground up on Ethereum (ETH) and positioned as the crypto-native alternative to Bountysource. Rather than fixing the trust problem, it doubled down on it by making crypto payments the only option.

The result was friction, volatility, and exclusion. Earning ETH sounds modern until a developer in Europe needs to cover rent, deal with taxable crypto events, and navigate wallet management just to receive $400 for a bug fix. The developer community, which skews toward practical, cash-positive contributors, largely bounced.

Gitcoin then pivoted away from bounties entirely toward grants and quadratic funding for Web3 projects. As one GitHub thread noted after Bountysource’s collapse: “gitcoin => has stopped taking bounties – not a loss, was dysfunctional and issuer-centric.”[7]

In short, both platforms, from opposite directions, failed the same fundamental test: making it simple and safe for a developer to earn normal money for normal work.


3. The Deeper Problem: Structural Misalignment

Beyond the individual collapses, academic research reveals systemic design problems that no single company could fix on its own.

Crucially, maintainers, the people whose merge decision determines whether any bounty gets paid, were cut out of the value chain entirely. They absorbed all the cost: reviewing PRs, managing contributors, gatekeeping quality. Meanwhile, 100% of the bounty reward went to the developer. The incentives were backwards.

A 2017 IEEE study found that the closing rate of bounty-attached issues was actually lower than non-bounty issues, and they took longer to close.[8] Money on a ticket attracted developers who didn’t understand the codebase, produced low-quality PRs, and created review overhead for maintainers who had no stake in the outcome.

Moreover, research shows that bounty size alone doesn’t attract the right contributors.[9] Some developers actively refused bounties. One Brython contributor declined, saying he “wanted to keep Brython free from monetary motivations.”[9] No platform ever solved how to route work to developers already skilled in that specific codebase.

On top of that, bounty amounts were routinely miscalibrated. Backers had no systematic way to price requests, which led to constant adjustments.[10] Many rewards sat too low to justify the ramp-up time – and no platform helped funders set better numbers.


4. The Stakes Are Getting Higher, Not Lower

A 2024 OpenLogic survey found that 95% of organizations rely on open source.[14] The Linux Foundation’s Census III (December 2024) analyzed over 12 million data points across ten thousand companies. Its finding is stark: tiny teams, often anonymous individuals with no sustainable income, maintain our most critical infrastructure.[11]

According to Gartner, the cost of software supply chain attacks is going to grow from $46 billion in 2023 to $138 billion by 2031, driven directly by unmaintained and unfixed open source vulnerabilities.[13] The Sonatype 2024 State of the Software Supply Chain report found that paid maintainers implement 55% more critical security and maintenance practices than unpaid ones – and resolve vulnerabilities up to 45% faster.[12]

The data is unambiguous – funding maintenance works. What’s been missing is a mechanism that’s actually trustworthy.


5. What a Working Model Actually Needs

The failure of past platforms points to a clear checklist for what has to be different.

Payment-at-delivery, not payment-at-pledge. Funds must be escrowed against a verifiable event: a merged pull request. Not a developer’s claim, not a funder’s satisfaction survey – a merge. This removes counterparty risk from both sides and makes settlement objective.

Maintainers must be inside the incentive structure. Gatekeepers of code quality, they carry enormous responsibility. Yet under the old model, reviewing a PR paid nothing. A split that gives maintainers a direct share of every bounty finally aligns their interests with successful completion.

Normal money, normal processes. Developers need to receive USD or their local currency equivalent via Stripe or similar, not ETH. Crypto payments add tax complexity, volatility risk, and friction that the average OSS contributor shouldn’t have to absorb.

Refund guarantees, not just policies. Expired deadlines and “won’t fix” decisions must trigger automatic, full refunds. No support tickets, no negotiations. Make it the structural default, not the exception.

No spam PRs forced on maintainers. Maintainers must retain full control over what gets merged. A bounty on an issue is not a purchase order for any particular PR. Any platform that doesn’t guarantee this will be rejected by the projects that matter most.


The Opportunity

The collapse of Bountysource wasn’t the failure of an idea. It was the failure of a specific implementation that put developer funds at risk, excluded maintainers from value, and got distracted by crypto. The need it was trying to address – connecting the companies who depend on open source with the people who maintain it, at the level of specific fixable issues – is more urgent today than it was in 2013.

The problem is real, the market is massive, and the structural lessons are well documented. Nobody has taken all of them seriously at once – until now.

That’s what OtterSource is building.


Sources

  1. Frank Nagle et al. – Value of Open Source Software, Harvard Business School, 2024 https://www.library.hbs.edu/working-knowledge/open-source-software-the-nine-trillion-resource-companies-take-for-granted
  2. Evan Boehs – Bountysource Stole at Least $21,000 from Open Source Developers, 2024 https://boehs.org/node/bountysource
  3. Wikipedia – Bountysource https://en.wikipedia.org/wiki/Bountysource
  4. NewPipe project – We have lost access to approximately €6,000 in bounties, 2023 https://newpipe.net/blog/pinned/announcement/we-have-lost-access-to-bountysource/
  5. GitHub – Unpaid bounties #1595, bountysource/core https://github.com/bountysource/core/issues/1595
  6. Git Hub – Bountysource is Insolvent #1586, bountysource/core https://github.com/bountysource/core/issues/1586
  7. GitHub –Alternatives to Bountysource #1594, bountysource/core https://github.com/bountysource/core/issues/1594
  8. Kanda et al. – Towards understanding an open-source bounty: Analysis of Bountysource, IEEE, 2017 https://ieeexplore.ieee.org/document/7884685/
  9. Zhou et al. – Studying the Association between Bountysource Bounties and the Issue-addressing Likelihood of GitHub Issue Reports, 2020 https://www.researchgate.net/publication/332263736
  10. ScienceDirect – Studying the association between Gitcoin’s issues and resolving outcomes, 2023 https://www.sciencedirect.com/science/article/abs/pii/S0164121223002303
  11. Linux Foundation / OpenSSF – Census III of Free and Open Source Software, December 2024 https://openssf.org/press-release/2024/12/04/open-source-usage-trends-and-security-challenges-revealed-in-new-study/
  12. Sonatype – 2024 State of the Software Supply Chain https://www.sonatype.com/state-of-the-software-supply-chain/2024/risk
  13. InfoWorld – Open source trends for 2025 and beyond https://www.infoworld.com/article/3800992/open-source-trends-for-2025-and-beyond.html
  14. ITPro – Open source risks threaten all business users, 2025 https://www.itpro.com/software/open-source/why-open-source-risks-threaten-all-business-users

OtterSource is a bounty marketplace for open source issues. Rewards are escrowed and released only on merged PRs. 80% to the developer, 20% to the project. No merge, no payment.