Bribe Devs To Improve Open Source Software 109
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."
not a bribe (Score:5, Insightful)
it's not a bribe, it's a contract. how is this news?
Appealing to the inner pirate ... (Score:5, Insightful)
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.
Re:Appealing to the inner pirate ... (Score:5, Insightful)
In that case, wouldn't "ransom" or "bounty" have been better? There have been projects like this before. As I recall, there was even one before Kickstarter came and made everyone talk about "crowdfunding" - but it didn't catch on.
Re:Appealing to the inner pirate ... (Score:4, Insightful)
Ransom implies hostages... But bounty sounds exactly right, indeed! I personally probably would get off my lazy backside and start coding a bit more if there was a little reward involved
Re:Appealing to the inner pirate ... (Score:5, Informative)
Obviously, many services already exists which provide bounties for open source development:
https://www.google.com/search?q=open+source+bounty [google.com]
So really, from first glance this doesn't sound new in any way.
The writer of the article thinks the 'voting system' (multiple people pledge to pay for a feature/bugfix) is a novel idea though. I've not looked at the others, it might be.
Sounds a bit like kickstarter as well.
Re: (Score:3)
Re: (Score:3, Funny)
"Yeah, babe, I'm a bounty hunter"
Just don't follow it up with "... just like Boba Fett"
Re: (Score:2)
In that case, wouldn't "ransom" or "bounty" have been better? There have been projects like this before. As I recall, there was even one before Kickstarter came and made everyone talk about "crowdfunding" - but it didn't catch on.
"Booty" would be the best. Lots of hobbyists would work for booty...:)
Re: (Score:1)
From the developer's standpoint it's extortion.io.
- Eddy
Re: (Score:1)
Professor, what's another name for pirate treasure?
Re:Appealing to the inner pirate ... (Score:4, Interesting)
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.
Re:Appealing to the inner pirate ... (Score:5, Funny)
Re:Appealing to the inner pirate ... (Score:4, Interesting)
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.
Re: (Score:2)
If this were to be done, you wouldn't be allowed to withdraw any offers. It would be the same as an eBay auction, or a Kickstarter project. You've essentially agreed to a contract. If you win, you have to pay.
Re: (Score:2)
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.
My God! I think you just re-invented a commercial software development and marketing strategy.
You should be paid for that!
Oh yeah, never mind...
Re: (Score:1)
OK, so you created 1000 bugs and put a $1 bribe on each of them to encourage others to chip in to get them fixed.
If half of the bugs are fixed by random people who thought that it was easier to fix the bug and cash in on the $1 than paying someone else to do it you are down $500.
You have essentially created a game where one can choose between adding to the bank or taking it all and you start by adding to the bank. There is no reason for anyone else to not take the money and your only advantage is that you h
Re: (Score:2)
OK, so you created 1000 bugs and put a $1 bribe on each of them to encourage others to chip in to get them fixed. If half of the bugs are fixed by random people who thought that it was easier to fix the bug and cash in on the $1 than paying someone else to do it you are down $500.
You have essentially created a game where one can choose between adding to the bank or taking it all and you start by adding to the bank. There is no reason for anyone else to not take the money and your only advantage is that you have your hand a little bit closer to the bank since you created the problem. You do however not benefit from this since you don't see when someone else is fixing the bug until it is too late.
The only problem with this premise is that intentionally writing bugs but leaving a mostly functional piece of software would take quite a bit of planning.
Surely a serious coder would want to write more, useful, code and bug-fix as necessary rather than engineer a situation which may or may not produce free monies?
I choose to believe that coders would have pride in their OSS and introduce new features rather than produce bug-laden code which might be replaced by the next big thing.
Having said that I'm
Re: (Score:2)
but I'm waiting for the bribe request.
...money is the root of all shareware. In this case, open source bugs are the root of all booty. That's still not doing evil, right?
Re: (Score:2)
I'm not sure it's a real world issue. Firstly is someone who has already decided to code a fix without any prospect of getting paid suddenly going to change their mind after designing a fix to potentially earn a few pounds; even if they did then someone else might see the bounty and claim it before they does
Platforms that ban copyleft (Score:1)
The fact that someone could go and work for a firm making paid for software already doesn't stop 1,000s of people working on open source software for free.
Yes it does, especially in the field of video games. First, video games tend to require skills other than programming, and the communities around these skills tend not to have quite as much of a sharing culture. Second, all major video game consoles require a proprietary commercial software business model and ban copyleft [slashdot.org], and game genres involving two to four gamepads and one screen don't work well on PCs, which tend to be connected to screens too small for two to four people to fit around.
Re: (Score:2)
It's also a way to potentially slow down bug solving.
Maybe. But it could also speed it up. If developers can profit by fixing bugs or adding features, they would likely spend more time doing that, and it could attract more developers into open source.
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.
Most OSS projects have competitors, so if the code is too buggy, users will go elsewhere.
Re: (Score:2)
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.
You forget this is OSS so you're not the only one who can bug hunt. I'm not saying some enterprising scumbag won't have such an idea and try to perpetuate such a con but for it to be successful the code must be relevant to begin with. Then there's the time spent fabricating the actual bug in the code. If it's too easy to spot somebody is going to swoop in and claim that $1 you just put up. Of course crafting such a bug on purpose is much more difficult than doing it accidentally so you actually spend more t
Re: (Score:2)
They should have called it Booty.io
Re:Appealing to the inner pirate ... (Score:4, Insightful)
In other news, people who think bribery is cool are small-minded morons. Case in point:
"One of the things I have always found troubling about Westerners doing business in emerging market countries is that they sometimes take an almost perverse pride in discussing payoffs to government officials. It is as though their having paid a bribe is a symbol of their international sophistication and insider knowledge. Yet, countless times when I am told of the bribe, I know the very same thing could almost certainly have been accomplished without a bribe."
--Dan Harris, chinalawblog.com
First movers pay surcharge for priority processing (Score:2)
Re: (Score:2)
Open source hobbyist devs are too rebellious to go for contracts
Is this actually true for any of the open source projects that have users? In most cases, the developers are entirely happy to work on the code for money, and in the case of larger projects many of them do full time. The problem is that a contract to fix a single bug is hard. This is why bug bounties administered via a simple mechanism are nice.
The hobbyist Linux dev is history (Score:2)
Open source hobbyist devs are too rebellious to go for contracts
Is this actually true for any of the open source projects that have users?
Doubtful. That is why I ended the sentence with a ";-)". In reality it seems that many successful open source projects are corporate or government funded. Linus Torvalds is not even in the top 100 kernel contributors anymore.
Re: (Score:2)
Not so minimum wage. About 7 years ago, my business partners and I needed a certain software feature that was present in a $10,000 piece of software. We paid an open source developer $500 to add it to his software. We had the changes in 2 days from the day we sent the money. We didn't call it a bribe, but there was no contract involved. Just a quick email saying "hey, would you add XYZ ASAP if we sent you $500"
Sure it's a bribe ... to avoid taxes (Score:2)
Sure it is a "bribe". 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 never sees the light of day = not taxed ... ;-)
- Jesper
Re: (Score:2)
You can declare bribes, and I'm sure some people do. No point exposing yourself to the penalties for tax evasion.
Re: (Score:2)
You can declare bribes, and I'm sure some people do. No point exposing yourself to the penalties for tax evasion.
I'm pretty sure that there's actually an IRS form for that, in fact.
Illegal income is taxed...just ask Al Capone. (Score:2)
Sure it is a "bribe". Bribes aren't taxed! ;-)
Actually, they are. Illegal income is specifically mentioned in the IRS tax code [wikipedia.org]. That's how they got Al Capone.
Re: (Score:2)
A contract can impose that any new code or modifications must be submitted under a license different from the original open-source code. A bribe does not give any rights to anyone.
If anything, bribes revoke rights, in spirit of the open-source ethos.
Re: (Score:2)
it's not a bribe, it's a contract. how is this news?
They can't call it a contract. If they did, it would be too obvious that isn't not a new business method so you couldn't patent it.
Re: (Score:2)
It's not a contract either, as the developer doesn't sign anything in advance agreeing to do work.
Its more like a bounty. "$100 for the head of the GUI bug that is ruining my day". Why they didn't go with that for a theme is beyond me. Boba Fett is far cooler as a model than some corrupt school board official.
Re: (Score:2)
Nope, still a contract.
You are right in that most contracts are bilateral; that is, everybody agrees with them up front.
Reward contracts ("lost my object, return for reward") are called unilateral contracts, the person making the statement agrees with it. Other people are not bound to the terms, but if they complete the terms they can collect on the contract.
Courts around the globe routinely find that these unilateral contracts are binding, usually when someone posts that they will pay a large reward
This will fail big time (Score:2)
Established proprietary s/w vendors have big pockets; and much more self-interest and motivation to keep Open Source Software inferior. Honesty is the not only the best policy for open source projects; it is the only policy that works in the long term.
Re: (Score:2)
There are plenty of other cognitive problems with money compensation.
For example, if you are paid to fix a bug, and there are a lot of bugs, you'll probably fix them as fast as possible to get the money.
When you concentrate on the result, the quality always lowers.
The quality is not a problem for a few jobs, but definitely not on computers !
Here is a nice article about other motivational problems:
http://whatspinksthinks.com/2013/11/04/get-shit-done-the-worst-startup-culture-ever/ [whatspinksthinks.com]
Re: (Score:2)
Well it didn't fail, no matter how badly your proprietary brain wants it to. this [indiegogo.com] shows you how it can and does work.
Re: (Score:2)
The problem is that many open-source projects simply will not listen to their minority users, presumably because they have no obligation to do so. Handy examples are the "Use margins to track changes" in Libreoffice. The developers admit that the feature is trivial, but will not implement it even as optional.
Or the recent ridiculous address bar font in Chrome - again obviously trivial but a 'wontfix'.
Now here is the thing, people have specialization and contribute in different ways to open-source. OSS devel
Just document your code, you lazy bums. (Score:2)
The prevalent attitude seems to be 'The code is there for you to modify. Do it yourself.' For the average user, that could mean developing proficiency in some programming language, familiarity with that software's architecture before they even begin to understand how to get what they want.
Making matters worse...most open-source projects are severely under-documented. Even though the source is available, getting past the hurdle of severe under-documentation is too much of a hassle. It takes dedication to get to the point where one can contribute meaningfully to an open-source project, and not for any good reason — it shouldn't take that much effort.
Making matters even worse...in my experience, most open-source-project maintainers will resist documentation. I just went through this w
Why? (Score:2)
I'm sorry, but both your arguments don't make sense to me. Why would big pockets of closed software vendors make this initiative fail? Will they spend money on this platform to have developers focus on irrelevant features or "harmless" bugs? I can't think of any other way closed source vendors would be spending money on open source to make it worse.?
Honesty? What's dishonest about this? It's out in the open that people are willing to pay others to fix bugs in software. Either the maintainers of the open sou
What a great name! (Score:5, Interesting)
"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.
Bounties, not bribes (Score:1)
In the Amiga community there is the similar notion of bounties [amigabounty.net], where people collect money, to be given to whoever implements some required functionality, usually a port of something useful.
I'm not sure one would want someone to think that one is bounty hunter, but at least it's better than giving the impression that they accept bribes.
Re: (Score:1)
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.
Maybe. But maybe instead your new employer would have expectations that you find uncomfortable to fulfill.
Re: (Score:2)
Reward for work? (Score:2, Insightful)
Getting paid for work? What arcane principle is this?
Doesnt everyone just work for free towards the greater good of software
not new (Score:1)
This is what SuSE and Redhat already do in a sense. Instead of calling it bribery they call it employing developers to work on opensource.
In the rest of the world... (Score:5, Insightful)
that's called issuing a paycheck.
Bullshit name (Score:1)
They call this a "bribe" because there seems to be this assumption that open source developers write code purely out of the greatness of their heats, that this is the status quo, and that adding a financial incentive towards fixing bugs is morally wrong.
The biggest problem I have with a ton of open source software is that the really big issues (particularly usability, but even features to make some software on par with their proprietary counterparts) are either hard, boring, or both. Coding functionality li
Re: (Score:1)
My first reaction to your remark was to respond that you're wrong, that for the most part work on open source is separate from work for pay, and that people do it in their own time out of intrinsic interest and not out extrinsic reward overcoming intrinsic indifference.
Paying them would then be pernicious and wrong because it changes there story from "I do this because I'm good at it and value it" to "I do this for spare cash", and I've seen that have a bad affect on people. Their intrinsic sense of reward
Bountysource (Score:1)
So, basically, it's exactly the same thing as Bountysource [wikipedia.org], which we discussed less than 2 months ago...
http://slashdot.org/story/13/09/18/0114237/a-new-way-to-fund-open-source-software-projects-bug-fixes-and-feature-requests [slashdot.org]
The problem this has always had in the past... (Score:5, Interesting)
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.
Re:The problem this has always had in the past... (Score:4, Informative)
Batch conversion with no screen output is not supported, which many people want so that they can provide screen readers for things like forms documents that are required on state and federal forms documents which are flagged as "no edit", which makes them non-compliant with the Americans with Disability Act (ADA).
Open source is scratch your own itch (Score:2)
As a contributor to open source myself (okay, minor, but in quite a few projects) I can say that it is very much a scatch your own itch thing that, in a mature environment with lots of devs/project managers/translators/package maintainers/etc., will gel together to form a nice overall 'product'. Many people do it just for the fun of it and already have another (I assume quite good) source of income. As nice as they are, it is the artists and content people that usually like the micro-payment system -- I sus
Obviously a bribe ... to avoid taxes (Score:3)
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
Re: (Score:1)
Um, no. IRS Publication 17 [irs.gov] doesn't agree:
Bribes. If you receive a bribe, include it in your income.
Sponsoring would be better (Score:1)
Re: (Score:3)
New Revenue Stream! (Score:2)
Wouldn't it be terrible if anyone deliberately put bugs into things so they could later be bribed to fix it.
I'm sure no-one would dream of doing that.
How is outcome decided? (Score:2)
How will they decide if the goal was met? I could easily envision a case where I ask for something, developer implements it with a slight change.
Now, I'm still unhappy about the result, but developer thinks he finished the job.
It's not a new idea (Score:3)
Already been done. BountySource [bountysource.com]
Just pay like everyone else (Score:2)
When my toilet gets blocked, I pay a plumber. if you need shit fixed pay a software developer. what's the point of this bribe stuff?
Pay for bug fixes? (Score:2)
Re: (Score:2)
There is a difference between paying for a bugfix on software you already purchased once, and paying someone to fix something you get for free.
Re: (Score:2)
Re: (Score:2)
Yes, the developer may use the software, but does not consider the bug worth fixing because it does not get in their way.
Paying to get the bug fixed may work in this case.
Re: (Score:2)
The contributors that are scratching their own itch are one group - the users who dont code are another. The first is only serving the second in the sense of letting them have whatever is useful to them at no cost - which is significant - but they still go in the direction that suits them, fix what bothers them, leave unfixed what does not. Which is only fair - they are donating their time.
But many people use free software without actually being coders at the appropriate level to alter every piece of softwa
Bounty Source (Score:4, Informative)
You can't complain (Score:2)
Re: (Score:2)
Even in well designed projects with excellent coders, there are plenty of bugs. And, its quite possible people will pay more for new features. There are still tremendous forces suggesting that you don't add bugs willy nilly to a project, like much loser user adoption rates.
Concerns on bribing (Score:3)
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?
a simpler alternative (Score:2)
This has definitely been done before (Score:1)
There are various sites that have done this in the past, I'm sure someone has mentioned them above.
What I've not seen anyone mention yet is https://www.gittip.com/ [gittip.com]
Gittip basically lets you set up weekly payments of like $1 or more to a person who does something, like, say, maintains some free software. If you are prepared to do that, it's a great way to support developers because, at its best, it would a regular income.
I don't really know whether Gittip will amount to much, but at least it's a new take on t