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.
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.
If you keep throwing chairs, one day you'll break windows....
Is this an advert for bribe.io, or for the linked blog, i-programmer.info?
Both are shit by the way.
"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.
bribing is a stupid name because it has so much negative energy.
bribing is a stupid name because it has so much negative energy.
Sounds more like paying devs.
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
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 Amiga community there is the similar notion of bounties, 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.
that's called issuing a paycheck.
Reeses
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 like tables you can resize with your mouse like you can in MS Word, isn't as much fun as writing a Personas feature in LibreOffice to let you use Firefox personas in the UI.
People who code for a livelihood aren't guaranteed to make better code than open source developers. But they are motivated to do the messy shit to solve end-users issues, because there's money on the table.
So, basically, it's exactly the same thing as Bountysource, 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
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.
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 suspect because some of them do it in real life?
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...
So how is this different to sites that already exist...?
https://www.bountysource.com/
http://www.codebounty.co/
others, i mean, wikipedia even has an article for this idea.
http://en.wikipedia.org/wiki/Open-source_bounty
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
My security clearance is so high I have to kill myself if I remember I have it...
Why the hell would someone want a bunch of politicians involved?
CAPTCHA: adultery (How ironic is this?)
So, pay someone to pay someone, I'd rather get something going via mailing list or forum not a middleman.
Naming it "Sponsor" would be a lot better. I really like the way LuaJit handles this and I think it's a rather good win-win. Someone gets a feature they want and the open source developer gets some funds to continue doing what they like. Hopefully the developer will say no to features that would take the software in the wrong direction.
Please do not call this a bribe - bribes are implying dishonesty and/or illegal behavior. This is something what keeps many african, asian and south american countries in the poverty.
Let's call it something like a bounty, reward, whatever.
Calling it a bribe will give impression, that bribe is something acceptable - which it isn't.
It rewards having more nuisance bugs. Bad idea. And money always finds a crooked use. Or several ones.
I'd prefer to see that done for actually useful documentation. Specially for promising, fun, but less used distros. Whole countries could benefit from that. Seriously. And the well documented distros would definitively have a better chance.
Yes. Decent documentation would be a much better idea, there.
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 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.
...
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 source package themselves step up and fix it and get paid, or some independent developer will. It may depend on their contributions being accepted by the maintainers, but I don't see anything hidden or dishonest about the process.
It may fail because people aren't willing to pay enough, or the initiative will remain too small to maintain, but I don't really see any other reasons why it would fail otherwise.
I was promised a flying car. Where is my flying car?
This already existed, http://freedomsponsors.org/ has been doing the same thing for some time now, what I like about these sites is they don't charge you anything until the developer claims the bounty and and it is accepted, then you procceed to send the money, I like how this operates in a trust among all parts.
This can be hacked by creating a stupid (or less intelligent) system, generating publicity to the bugs/issues and waiting for your incentive to fix them. This is a well known tactic, used in the corporate world to get the incentives. When I started out in the corporate world, an old-hack once told me, "When you write code, make sure you insert some sleep statements. That way when management comes back requesting that you optimize it, you can (after waiting for the problem to escalate to a suitable level), fix it and get to be known as the fix-it guy".
Already been done. BountySource
I do not fail; I succeed at finding out what does not work.
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?
did you forget to take your meds?
Isn't that what so many FLOSS supporting slashdotter complain about when companies charge for patches and upgrades?
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
Yep.. of course there's an IRS form for it.
Make sure the bribe giver files the required 1099, though.
If they were to do that then why would they do any work whatsoever currently, where they get paid fuck all?
Is this merely you asserting what YOU would do if you were a FOSS coder (but are not because it doesn't pay)? Because, remember: the coders working for FOSS are either already being paid or are unpaid. In the case of the latter, they already do not consider the only purpose of coding on the project "to get paid" and in the case of the former, they get paid already and won't get paid if they refuse to do work.
In either case, your conspiracy would only work with people who already COULD work on a FOSS project BUT DO NOT because they won't get paid.
Therefore a bounty would make these people do the work that isn't currently being done.
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, 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.
True, a lot of things can be accomplished without paying a surcharge for priority processing. It'd just take several years longer for the paperwork to be approved, while your competitors pay the surcharge for priority processing and take the market for themselves.
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.
Money can be exchanged for goods and services (Thanks for that nugget of knowledge, Homer Simpson!)
I've long held the opinion that developers aren't allowed to complain about the quality of open source software. Now rich people aren't allowed to as well? Fine by me.
It's brilliant: Let's create an economic incentive to introduce annoying bugs into our software so people will pay us to fix it. What could go wrong?
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?
Is to be active in the mailing list and simply give them money (PayPal, whatever they accept). It lets them know that you value their work, and human nature tends to take over after that (hopefully for the better!).
Buy your next Linux PC at eightvirtues.com
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 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 the "funding free things" problem rather than a rehash of something that has been done several times before, which "bribe.io" appears to be.
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.
Sure it is a "bribe". Bribes aren't taxed! ;-)
Actually, they are. Illegal income is specifically mentioned in the IRS tax code. That's how they got Al Capone.
"Once we've identified and embraced our sickness, we'll have strength...and that's when we get dangerous." - John Waters
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 with an open-source project I've been interested in a long time. Since the source-code had practically no comments whatsoever, I took it upon myself to learn the subject matter (in this case, NOT an easy task), then learn large parts of the source code. Then, being the sort that's willing to contribute, I offered to document the code. The maintainer was willing, even eager, for it. Then I submitted my first patch...and he immediately changed his tune. He found my documentation to be "excessive", and quoted chapter 8 of the Linux kernel coding guidelines to bolster his case. Frankly, I couldn't disagree more with his viewpoint.
I'll never understand, for the life of me, why programmers don't document their source code, especially open-source programmers. How is anyone supposed to contribute to their project if the hurdle is set so high? Hell, how do they remember how a piece of code works if they haven't seen it in a long time? It boggles the mind.
I don't have any good theories for why this is...just a disparaging one. Every time I encounter this problem, I get a vivid image of Gollum grasping some source-code printouts and hissing "Nooooo! My preciousssssss...."
I certainly document my open-source code. My biggest project to date is a temporal analog-video denoiser called y4mdenoise. Feel free to look at the code, if you'd like to see an example of what I'd consider a proper level of documentation. Start with the high-level overview and find out for yourself.
"Once we've identified and embraced our sickness, we'll have strength...and that's when we get dangerous." - John Waters
Among other things this scheme sounds like it falls into the "penny gap". There is a big psychological difference between free, like volunteer donations to open source projects, and cheap, such as these small bribes. See here for a fascinating overview.