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."
it's not a bribe, it's a contract. how is this news?
Anons need not reply. Questions end with a question mark.
"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 not a bribe, it's a contract. how is this news?
Its not news its marketing. Open source hobbyist devs are too rebellious to go for contracts, bribes are more appealing to their inner pirate. ;-) Its a way to make minimum wage pay for software development sound cool.
Getting paid for work? What arcane principle is this?
Doesnt everyone just work for free towards the greater good of software
that's called issuing a paycheck.
Reeses
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.
It is obviously a "bribe"; because bribes aren't taxed!
Revenue from a contract is taxed. A paycheck is taxed. A reward is taxed. Hell, even a bounty is taxed.
A bribe? Not so much ... ;-)
- Jesper
My security clearance is so high I have to kill myself if I remember I have it...
Or better still, go medieval, and just call it patronage. Support worthy causes (art, architecture, music, science, computing) and receive honour from your peers, who all do the same, at least whenever they need a break from exploiting the peasants.
Already been done. BountySource
I do not fail; I succeed at finding out what does not work.
How does this differ from Bounty Source? Bounty Source has been around for awhile now, is well maintained and already offers everything here. In some things, to much diversity is a bad thing and I see that here. You need to be able to meet up as many users with developers as possible for a system like this to work well.
I am a developer working on an open source project and I would accept less money if I knew the bug was something I wanted to fix or a feature I wanted to implement. But to tackle something I truly don't want to do for personal joy or itch, I would have to have something on the order of $60-100 dollars per hour of my time to do it. And, there would be bugs and features all along this continuum. Also, I want higher adoption rights so the more "money" there is the more I want to do it for that reason. Also, if there are only a few bounties, I'd probably be willing to go for those more.
However, when money becomes a part of the motivation, if its not guaranteed, then I will start to look at expected probable outcomes (value of bug * chance I'll get the money = EPO). There has to be a reasonable assumption that you will get the money as a developer. Ways to increase the chance I'll get the money would be to take user's credit cards, but then you run into the problem of authing the card months after the bug has been fixed. You could implement a reputation system such that money that has been paid out in the past makes the current offer look stronger. You could also hold the money in escrow. Every solution on this front requires overhead, so how much would be taken off the top? Transparency in the accounting and structure would be highly important to maintain a perception of integrity in the bribing system.
Developers also can cheat the system by not really fixing the bug or adding the feature. They could implement the feature in ways that make more sense to them but cause the user to feel that they aren't getting value for money. A bug could be fixed in one way then pop up again causing the developer to look like he cheated a user, when in reality its the same buggy behavior for a different reason.
People are often terrible about getting information to the developer so that the bug fix is "easier". In that way, lines of communication would have to be kept open so the developer could ask for more information. Also, the developer could indicate that they find it low priority and suggest that they would consider it higher priority for a little more? Features are often poorly described by users so the developer could also communicate on that account as well.
What about bounty pooling? Like, two people put in a feature that is the similar but not quite the same. The developer and the users together may want to arrive at a compromise that benefits everyone.
People aren't paid in just money, social capital via social networks is also significant. Allowing the user to broadcast on plus and fb that he financed an open source project (and which one) also gets advertising for the project which benefits the developer, and kudos and respect for the user. Integration with social networks could be powerful. I, probably like many developers, don't like to use social networks personally, but users using them is great and I see the benefit.
I think the theory of the idea is sound, but it would require a lot of careful consideration, a lot of implementation, and some sound business consideration.
Also, in some way, this might undercut the amount of donating people already do. Now, to get the money I have to do more work, instead of generally getting rewarded for work I've already done. I can see that maybe it would lead to more money overall, but I wonder if it would?