Seems obvious doesn’t it? They have to be a good thing surely? They are paying people to work on Open Source software – isn’t that increasing the sustainability of open source?
Except the money isn’t going to open-source development; it’s going to a cottage industry of hacking that will likely sell the defects to the highest bidder. Even if the highest bidder is part of a white-hat bug bounty program the community that owns the code may well not have members who can fix the problem readily. Even if the community has got commercial contributors they may not have the income necessary to fix all these bugs found by people who are not buying their product.
Even assuming they want to (screenshot):
Bugs and Knowing
It’s good to have bug reports and know about defects, but there can be down sides. If the defects are exploitable vulnerabilities – CVEs – the reports are kept on a private security list until fixed to avoid informing black-hats. But in projects that can’t fix the defects fast enough they may well end up being disclosed before there is a resolution.
They also show up on CVE databases and become a cause for support calls and demands for resolution from volunteer community members, increasingly so as automatic scanning tools spread. Some of the bugs are rejected by the developers who own the software because in some cases being a bug or a feature is truthfully a matter of opinion, resulting in “will not fix” false positives.
A case can be made for bug bounty programs run for a company seeking low-cost penetration testing to be handled by their professional development team for a commercial product. It can also be made for an administration seeking community testing of public systems, like the Swiss government. But community-focussed programs like the European Commission’s Open Source bug bounty are well-meaning but surely miss their mark, creating work for communities and their commercial backers without generating donations or revenues to pay for bug resolution.
Who Can We Fund?
Specifically to that example, there’s nothing in the EU program that actually leads to any maintainers being paid, which is because that’s “software procurement” and has stringent rules. There’s a 20% uplift for bug reports who propose fixes for their bugs, but the on-ramp for maintainers of the targeted code is usually substantial and a 20% premium is unlikely to be enough to incent someone to come on board as a maintainer.
The EU has built outbound funding programs for Open Source at NL Net and NGI, but they are all earmarked for “the next big thing”, not for the boring job of keeping Open Source maintained. Edgy new features have indeed been paid for by them, but they have no regard for funding bug-bounty burdens. One fix would be to associate an earmarked grant with a matched bug bounty award so the maintainer could go claim it, giving a concrete incentive to invest the time.
Ideally, the grant to the reporter would be at least partly tied to the bug getting fixed as well. But even if the community has members able and willing to take on bounties, haggling with one or multiple unknown parties over acceptance of a solution after the investment has been made is huge risk for small rewards for implementors.
Conclusion
In the sense they reflect a growing realisation by software consumers that strip-mining Open Source is not sustainable, bug bounties are definitely welcome. But they are not the solution to creating sustainability. Open Source in the supply chain is not mainly or even largely about security. Rather, it has the same profile as Open Source elsewhere – a collaborative matter where beneficiaries share the sunk costs in proportion to the benefits gained.
Bug bounties prioritise the non-contributor’s worldview – the quality of the strip-mined commodity – and neglect the true community view – pooled innovation and shared costs. They are a good first step, but need to be rapidly followed by enlightened self-interest expressed by funding and enabling of the maintainers rather than just rewarding their users.
Meshed Insights Ltd 
