As with many things in life, motivation is everything. This also applies to the development of software, which is a field that has become immensely important over the past decades. Within a commercial context, the motivation to write software is primarily financial, in that a company’s products are developed by individuals who are being financially compensated for their time. This is often different with Free and Open Source Software (FOSS) projects, where the motivation to develop the software is in many cases derived more out of passion and sometimes a wildly successful hobby rather than any financial incentives.
Yet what if financial incentives are added by those who have a vested interest in seeing certain features added or changed in a FOSS project? While with a commercial project it’s clear (or should be) that the paying customers are the ones whose needs are to be met, with a volunteer-based FOSS project the addition of financial incentives make for a much more fuzzy system. This is where FOSS projects like the Zig programming language have put down their foot, calling FOSS bounties ‘damaging’.
Bounty Hunting
Within this absolutely volatile and inflammatory topic, it is probably a good idea to first nail down what is meant with a ‘bounty’, as there are a number of possible interpretations just within the field of software development. Perhaps the most well-known is the concept of bug bounty programs, where someone who discovers a flaw in the software product or service of a company can get some kind of (monetary) reward. This reward is supposed to be there to both motivate security researchers to discover new bugs, and to report said bugs to the company rather than to let less scrupulous individuals use them for ill-gotten gains.
In a way this makes such a bounty program somewhat into a modern equivalent of the old tradition of bounty hunters, yet it is quite distinct from bounty programs that target the development of software features rather than the discovery of bugs. When it comes to motivating the development of new features we can distinguish two major types of incentives:
- A community bounty to submit a feature patch to the project.
- A monetary reward given to the project’s developer(s) upon completion of the new feature.
In the Zig project‘s blog post we can see that they have no issue with bug bounties, which is understandable. Despite some issues with bug bounty programs over the decades, in general they are a net positive incentive which can create a healthy relationship between security researchers and developers. After all, even the best-run software project will inevitably have some bugs in the Golden Master release version that gets pushed out into the world, some of which you’d rather hear about from a reputable researcher than read about in the media.
In contrast, the notion of community bounties is branded as being essentially harmful and something the Zig developers caution against. Rather than providing a friendly, cooperative atmosphere, such bounties are bound to invite hastily developed, poorly considered implementations where the main measure of ‘success’ is whether or not all test cases light up green. Add to this the possibility of the project developers having to judge and likely reject various competing submissions, and it would seem reasonable to conclude that only the security researchers are winning out in such a scenario.
Staking Claims
The idea of putting up software bounties to promote the development of features is not a new thing by any stretch, with for example the GNU Hurd project in 2011 spelling out why they feel that bounties are a great idea. Yet the website that particular project references – FOSS Factory – appears to have been essentially dead since about 2008, or three years before the GNU Hurd project even promoted its use.
A more current example of a software bounty website is Bountysource, which currently is still actively accepting new bounties. However, after having been purchased and sold on again by a number of cryptocurrency companies it’s currently in hot water for not paying out the bounty money which it is supposed to hold in escrow. This was apparently an issue back in 2020 already, with some projects moving to GitHub Sponsors, which interestingly enough is essentially the inverse of a bounty system as it involves donating to a project.
Rather than being strictly a donationware system, however, it is duly noted by Naomichi Shimada and colleagues in a 2022 study that GitHub Sponsors turns a project into sponsorware. Although the difference between donating and sponsoring can seem academic to some, the latter has definite expectations of returns, no matter in what form. In the study by Shimada et al., these differing expectations between project managers and those who sponsor or otherwise contribute to a project other than as a developer are addressed as a potential issue that should be kept in mind by project owners before enabling sponsorships.
Commercial FOSS
A viable way to get the financial cost of developing software features settled is covered in detail by Brad Collette of the Ondsel (FreeCad) core team. Although the points raised against community bounties are pretty much the same as those raised by the Zig developers, the suggested way which does work essentially involves crowdfunding, with the Krita project provided as a shining example.
Essentially the project developers will get together to figure out which features could or should be implemented in the next major release and pitch this to the community. By running a crowdfunding campaign with stretch goals, the community can thus directly fund the new features while any stretch goals are similarly decided on by the community through their financing. Although the project is still technically FOSS, this makes the community (users) an integral part of the project by making them stakeholders in the project.
Interestingly, this isn’t far removed from how many big FOSS projects – such as the Linux kernel and the largest distributions – are funded. Although full of little pieces of hobby projects that may conceivably collapse the larger project if they ever developed an issue, these large FOSS projects are by and large sponsored and funded by the world’s wealthiest companies.
As an example, the Linux kernel is backed by the Linux Foundation’s sponsors, with in 2021 Huawei providing the most changesets and Intel contributing the most lines of code changed on the 5.10 kernel. In 2022, the 6.0 kernel saw Intel, AMD, Google and Linaro competing in the top 4 of each category. Overall, most FOSS development is directly paid for – often using in-house developers – by IT giants like Microsoft, Amazon Web Services (AWS), Intel and Google. This then clearly renders the question of software bounties moot for these kinds of FOSS projects when companies with billions of USD in revenue are footing the bill already.
Small FOSS
Reading through e.g. this 2021 discussion over at Hacker News on the topic of software bounties is also rather interesting as a way to gauge people’s feelings and experiences on the matter. The general consensus would appear to be that for FOSS projects that do not already have the backing of wealthy sponsors or similar, keeping the developer(s) behind them engaged and motivated is crucial.
Speaking as someone who has had their own middling success with some mildly successful FOSS projects, there is a certain rush that comes from people actually paying attention to, and even using your software in real commercial projects. Yet at the end of the day it is essential to differentiate whether a project is a hobby or a job, with the differentiator here being whether you are being paid to do work.
If you are a project owner, and you put out a crowdfunding request that ends up covering your projected feature implementation costs, even if it’s just to cover the rent and human/pet food, you take on the responsibility to get that feature implemented so that those who financially contributed are satisfied with the results.
If, however, someone creates a ticket in your GitHub project saying that they would ‘really like to see feature XZ implemented’, but no funding has been allocated, it’s still just your hobby project and you are free to ignore such tickets, or only take it on because it seems interesting as a challenge within the context of said hobby project.
A major risk with FOSS projects is FOSS exploitation, which most recently has become a rather hotly debated topic. Some companies are now moving away from very open FOSS licenses to more restrictive ones (like the GPL) as a result, as a way to combat other companies making money off something that was given away for free. This could be regarded as a natural response to such exploitation, as companies and individuals alike seek to protect themselves.
We are taught as children that ‘sharing is caring’, yet the concept of fairness is even more crucial. Although FOSS is sometimes portrayed as some kind of utopian dream of infinite free software, the harsh reality is that each line of code is still written and tested by human beings, each of whom need to eat, and deserve their fair due.
Interesting read, thanks. Got a few notes:
> which interestingly enough is essentially the inverse of a bounty system as it essentially involves donating to a project.
two times “essentially” in essentially rapid succession sound a bit “off”, essentially. ;-)
Maybe “… practically the inverse …. it essentially involves …”
> Although the difference between donating and sponsoring can seem academic to some, the latter has definite expectations of returns, no matter in what form.
Would it be fair to say donations to a FOSS project are for what you’ve got already – kinda pay after use? – and sponsoring is for what’s to come – as in “investment in future development”.
I mean a donation has the later purpose as well but only additionally, not at its core.
> A viable way to get the financial cost of developing software features [covered in detailed] by Brad Collette of the Ondsel (FreeCad) core team.
??? maybe: “… features IS covered in detail by …” Modern-day infrastructure, as visualized by XKCD. (Credit: Randall Munroe)
I thought Randall Munroe visualized that first and then published it under his XKCD comic/brand. Didn’t know XKCD could do stuff on its own. ;-)
For some reason the last part got mangled?! I still have the text in ctrl+c so I know it looked like this (the XKCD part got it’s own lines, not mangled with the “covered in detailed”):
> Modern-day infrastructure, as visualized by XKCD. (Credit: Randall Munroe)
I thought Randall Munroe visualized that first and then published it under his XKCD comic/brand. Didn’t know XKCD could do stuff on its own. ;-)
Bounties are another way of saying “contract development”. Contracting out work is fine when it’s a bounded task and your terms clearly define what you expect (style, quality, functional acceptance criteria). It becomes dangerous if you expect the contractor to take a personal stake in the project as if they’re a regular OSS contributor that finds the work intrinsically rewarding.
https://xkcd.com/2347/
In case you want to read the alt text.
Just read the alt-text… ain’t that the truth!
“Someday ImageMagick will finally break for good and we’ll have a long period of scrambling as we try to reassemble civilization from the rubble.”
-For the terminally lazy
I really can’t see the problem – if somebody with money wants to pay to develop a feature that is good for them it is probably good for others too. And if it isn’t a good idea for everyone, or the initial implementation doesn’t meet the existing projects goals you get a fork or future refinement that does play nice.
At what point do you draw the line of acceptable? Is it before something like the Pi folks or Valve (etc) paying external devs for something they want as its good for their customers, but after a big corporate IT company pays for something that is obviously good for themselves but has no bearing on the service they provide? Or are both equally evil?
And if you won’t accept FOSS developers getting paid by these groups that have some interest in the software how do you expect them to get it paid for? As the general consumer that might pay for crowdfunding type concepts almost certainly doesn’t know enough about the building blocks that are more fundamental to how programs run to also contribute there – they only want the program that does x to do x well. Which means either you then end up with that crowdfunded pool of money being spent only to pile new stuff inside a monolithic program, duplicating effort with heaps of other programs and wasting computing resources, which is stupid, or sensibly spent to further develop the more core underlying everything stuff and you are right back to a larger group paying somebody to develop something because they have a vested interest in it working right themselves…
I suggest you read the blog post over at Zig since they explain why feature-bounties is a bad idea.
To summarise: it’s competitive, often done completely without consulting the maintainers (i.e. the contribution may not even be accepted) and doesn’t take future maintenance into consideration.
Maybe there should be a program where only hunters approved by the core team can work on the bounties. Then it would be closer to the way commercial software is done, with a small paid team, which produces great results.
Commerical is often way ahead of FOSS in most areas except stuff like format/protocol compatibility and local-first support.
Not saying its the best way, but it doesn’t have to be accepted to be useful in the end. Won’t be the most efficient use of time if it doesn’t get accepted, but that just leads to a fork or a rework if the features were actually good ideas. And the work done will be at least a useful concept demo and accelerator to implement that feature in the future.
The bounty setter is the only one that really losses if things don’t go well with their bounty – as they got their own fork that nobody likes and isn’t accepted by the project, so they probably mostly wasted their money. But the project still probably gains even if its only from the skeletal rough draft of the feature that will get reworked to be maintainable first.
There’s another important part of this, community.
These kinds of bounties can foster a competitive environment where actors are incentivized to be the one who gets the payout rather than cooperating and coordinating with each other. There are winners and losers in this system, which is in contrast to a system where everyone works together and everyone wins.
Fostering a positive community is critical for any large project, especially those made of volunteers. It requires good leaders who are thoughtful/intentional and are actively doing things to keep that environment safe and productive for everyone.
Hmm, that is an excellent point that it can break the community, one I’d not really considered much. Though it seems the community is more likely to break itself for clash of personalities near the top and incompatible goals than this from what I’ve seen of FOSS projects.
Either way the developers do need to eat. So they need to get paid. If this is the method somebody wants to put money in with it seems better to me to accept it than try and probably fail to get them to donate to the project in general without getting any certainty of progress towards their feature needs.
All this seems to muddy the distinction between “free” as in unencumbered by licenses and open source versus “free” as in the sense of no money involved. I don’t see money in itself as evil (though of course the love of money is the root of all evil) — as long as we don’t sacrifice the open source aspect of what is produced. If there is a bias towards meeting someones particular needs, that is likely to be a win/win.
I can’t help thinking about Red Hat. For the most part they aren’t writing software, but they have let commercial influences cause them to make some unfortunate decisions. But that quickly becomes an entirely different story.
Somebody ought to pay whoever wrote this funky Hackaday web software to add an edit button.
In relation to this subject, I found this an interesting read:
Producing Open Source Software. How to Run a Successful Free Software Project, e.g.:
– Chapter 4. Social and Political Infrastructure
– Chapter 5. Organizations and Money: Businesses, Non-Profits, and Governments
https://producingoss.com/
it’s possible for different people to independently discover the same bug, but that’s an unlucky coincidence, not a structural aspect of the resulting system.
The notion of “bug bounties” for FOSS bothers me. It feels ripe for abuse. But there is a spin that makes it sound less bad: paying people to test. Often development is rewarding, but testing is less so. But maybe there is something I don’t understand about FOSS that has solved the inadequate testing problem. Is feedback (bug reports) from the user community enough?
I’m a lawyer, and as assist, have worked as a professional bioethicist, have a degree in philosophy with concentration and ethics, have written a research ethics guidelines and remediation procedure for research on human subjects had a national University which was adopted by The faculty Senate unanimously in 2013, I’m currently focusing on the ethics of science and technology and the effects on culture policy and law. This would include all of the privacy regulations, finds, the corporate veil, open source software, the different types of Open source licenses, bug bounty programs, conflict of interest potential that exists within those programs, and I would suggest that a committee be formed an international body which comes up with not only a set of various types of applicable responsible disclosure procedures but that would eliminate someone who’s connected with the development in any way or there relatives and or associates from collecting a bug bounty based on a potential conflict of interest in parent within the development of software at a rapid pace and then the finding of a exploit in the collection of money based on that exploit. I also am an advocate of better treatment and respect on it law enforcement and cyber security apparatus as well as the companies and developers in regards to Independent security researchers or ethical hackers which is the and historical terms and which some people believe is a vaginal but it’s social media and media today has kind of a negative rotation despite my understanding the argument for using that title might not sure the best interest of an individual. I think we need to spell out some standards and make them very clear beginning from when the security research begins like riding out your plan your disclosure plan as well as an agreement between your researchers to stringent security procedures to prevent premature disclosure and that that plan be written and witnessed by a neutral third party so that it can be produced to anyone from question me and center and the motives of be it independent security researchers, ethical hackers, or academic teams. The motivation behind finding these exploits and reporting but ethical hackers come independent security researchers are academics is wide and varied and can come down to your curiosity and the desire to try and solve a puzzle or in other words break something but not in the terms of in a malicious way but in terms of figuring out how it works and see if it’s really sure. Some people do it for education or reasons and to publish to help the career advancement or advancement within academia. Some people do it for a job and for the bug bounty and the monetary rewards to come along with it because they have a certain set of skills that is rare and it takes a lot of work dedication and time in many cases to find these very complicated exploits. I would be willing to serve as a member of any such committee because I believe I have the requisite understanding and their requisite experience to be of assistance to a team should be a team effort and it should be a I can census based and joint team effort with the input of civil society and those who are affected. It should ss the universal but take into account the fact that those differ in various jurisdictions. It would be quite a bit at work and but I think it’s important it’s very important the precedes an ethical and correct manner. Most professions have code of ethics and professional responsibilities. The same should apply to this profession and it is a professional whether your reasons be for monetary gain, not variety, or academic success as well as career advancement. The point being is that there is conflict of interest potential and there is a need for having strong ethical standards as well as the cooperation with long cyber security apparatus which could even help with the correct and just awarding of bug bounties in the timely manner and do away with these dodgy intermediaries which do nothing but take a piece of the pie.
That is contrary to the whole idea of FOSS. And maybe at you know because commercial sector utilizes the library everywhere in a case of an open source library which isn’t simply it’s all companies which use it within their commercial co code base should pitch in to a fund from which to pay for bounties on open source maintained projects. Some of these libraries are maintained free but people who believe and and open source software and there could be a single person or a two people maintaining and extremely essential and vital library that’s being used commercially and many many soccer packages.
Fair is fair and where these people work hard for nothing and they do their best toto do the best job they can sometimes they just don’t have enough time to catch absolutely every fall or every potential increasingly sophisticated and increasingly complex type of exploit and I give an example focusing a lens on an LED light of a hard drive and extracting an encryption key seriously.