Slashdot Mirror
Bribe Devs To Improve Open Source Software
mikejuk writes "Bribe.io announces itself as: 'A super easy way to bribe developers to fix bugs and add features in the software you're using.' Recognizing the fact that a lot of open source projects are maintained by developers working alone and in their spare time, the idea is to encourage other developers to by specifying a monetary value to a bug report or feature enhancement. Once an initial 'Bribe' has been posted others can 'chip in' and add to the financial incentive."
"bribe |brb| verb
persuade (someone) to act in one's favor, typically illegally or dishonestly, by a gift of money or other inducement"
I bet they really thought that one out. As a professional developer myself, the last thing I would want is someone googling my name and seeing that I "accept bribes" or something stupid. Given how HR departments work these days, they probably wouldn't even bother going to the website to see what it's actually about, and your resume would go into the trash can without a second look.
Of all the words they could have picked, they went with the one that is associated with illegitimacy or dishonesty. Talk about a Web 2.0 fail.
It's also a way to potentially slow down bug solving. You write the patch and just before you hit submit, you realize "Oh wait, I could get paid for this" so you create a $1 bribe for said bug, wait until it have some dollars more, then submit and cash out.
It might even lead to more bugs appearing in the software. If there's some 1000 bugs you know because you added some willfully sloppy code, there's obviously money to be made.
Want more features? Well think of it like DLC. Oh they're ready all right but I'm waiting for the bribe request.
This certainly could be the way that things go, but there are a few delicate balancing acts to be performed if a dev wants to game the process in this way.
Purposefully writes bugs into the software will probably have a negative impact on the quality of the finished product, making it less attractive to potential users. Less attractive will usually translate to fewer users, which translates to a smaller pool of potential "bribers".
If the bugs are in a core element of the product that everybody uses, it will be discovered quickly, and either fixed quickly by another contributor who is not looking to get paid for it or start driving users toward other potential options (assuming there are other potential options which offer a similar feature set).
If the bugs are in an area that not many people will use, so it is less likely to garner widespread attention from devs looking to fix it, there will also be fewer users interested in the problem. Those users may be the most likely to post a bribe/bounty on the bug, and may post a correspondingly higher bribe, but that single user's contribution may be the only contribution.
Delaying a bug fix in order to try and get paid (or paid more) on the bribe/bounty runs the risk of another dev stepping in who fixes the bug for nothing or the currently posted amount, so the work you have done to date is for nothing.
If the code on a project is so badly written (on purpose, to game the system) and you are the only dev supporting the project, that no-one else is willing to get involved in it, then the project will probably not see many users.
The gaming options are also present on the user's side - being the first to post a bribe/bounty on a particular bug in the hope that others will climb on board is a good way to get your bug addressed, but there is a degree of "why should I foot the entire bill for this change?" which is perfectly reasonable as the change will probably benefit either the community as a whole or at least a section of it. The gaming side from the user's perspective is similar to a Dutch Auction, where the question "How low can I go?" comes in.
Also, and this one depends very much on the implementation of the idea, not the idea itself, if a user posts a bribe for a particular bug, which then attracts other contributors, what happens if the original briber then tries to withdraw their bribe? For example, I want to get a bug fixed but I do not want to pay for it, so I post a $100 bribe for the bug to be fixed. 10 other users see that, and contribute $10 to the bribe fund, and I then withdraw my bribe (because now, there is a much higher chance that other users will contribute and that devs will take notice, so the problem might be fixed without me having to spend anything).
The sweet spot for this system to be gained is thus pretty small, and probably most applicable to older projects which have been very popular in the past and have a fairly large community of users with significant investment of time and effort spent using the system, so they are pretty much locked in. On those projects where there has been some drama or the existing dev team have not been maintaining the project properly, then this approach could work and could be reasonably profitable, as long as both the devs and the users are not going to try and game the system too much.
The problem this has always had in the past is that what people want to pay for is generally not actually a bug, it's editorial control over some aspect of the product which they dislike. This may or may not have an impact on "fitness for purpose" of the person who is willing to supply the "bribe".
A good example of this is the lack of Cairo back end rendering support in xpdf, which will only get included over the primary maintainers dead body, according to at least 3 GNATS database bug reports by third parties who would desperately like to see Cairo support, and have even provided code to implement it.
Only they are not SO desperate for this support that they are willing to fork the project and shoulder the same burdens shouldered by the current maintainer. So it seems they are willing to pay a "bribe", it's just not a sufficient one for them to get their way. And so it remain unsupported.
I really don't see this site going any farther than the half dozen sites that have tried the same thing in the past, and also failed to provide the editorial control over the product that the people supposedly footing the bill want.
The last pay-for-feature/pay-for-bugfix business model that worked is centralized control of the product by a nominal support organization, which acts as a barrier to entry for other people trying to get into the "we want to be maintainers too!" business. This was the Cygnus model for gcc, and it's the current Codeweavers model for Crossover Office as a commercial WINE variant. It only works because the barrier to entry for third parties is so high that there isn't competition occurring in the market.
So once again: nothing to see here.