Forgot your password?
typodupeerror
Programming Open Source The Almighty Buck

Bribe Devs To Improve Open Source Software 109

Posted by Unknown Lamer
from the five-cents-for-two-years-of-work dept.
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."
This discussion has been archived. No new comments can be posted.

Bribe Devs To Improve Open Source Software

Comments Filter:
  • not a bribe (Score:5, Insightful)

    by Gravis Zero (934156) on Tuesday November 05, 2013 @04:07AM (#45334077)

    it's not a bribe, it's a contract. how is this news?

    • by perpenso (1613749) on Tuesday November 05, 2013 @04:27AM (#45334139)

      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.

      • by Vintermann (400722) on Tuesday November 05, 2013 @04:51AM (#45334211) Homepage

        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.

      • by durrr (1316311) on Tuesday November 05, 2013 @04:53AM (#45334213)

        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.

        • by perpenso (1613749) on Tuesday November 05, 2013 @05:09AM (#45334277)
          Have you picked out a color for that minivan yet? :-)
        • by Stolpskott (2422670) on Tuesday November 05, 2013 @05:36AM (#45334327)

          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.

          • 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.

          • by Bob_Who (926234)

            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...

        • by Anonymous Coward

          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

          • 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

        • by Bob_Who (926234)

          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?

        • by N1AK (864906)

          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.

          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

          • 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.

        • 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.

        • by ArhcAngel (247594)

          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

      • by Thanshin (1188877)

        They should have called it Booty.io

      • by DNS-and-BIND (461968) on Tuesday November 05, 2013 @07:57AM (#45334751) Homepage

        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

      • 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.

        • 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.

      • 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 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

    • by nashv (1479253)

      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.

    • by Shavano (2541114)

      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.

    • by T.E.D. (34228)

      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.

      • 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

  • 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.

    • by eulernet (1132389)

      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]

    • 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.

    • by nashv (1479253)

      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

      • 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

    • 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)

    by Anonymous Coward on Tuesday November 05, 2013 @04:09AM (#45334087)

    "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.

    • 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.

    • 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.

  • Reward for work? (Score:2, Insightful)

    by genocyde (184014)

    Getting paid for work? What arcane principle is this?

    Doesnt everyone just work for free towards the greater good of software

  • by Anonymous Coward

    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.

  • by Reeses (5069) on Tuesday November 05, 2013 @04:53AM (#45334215)

    that's called issuing a paycheck.

  • 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

    • by kemosabi (659932)

      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

  • by Anonymous Coward

    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]

  • by tlambert (566799) on Tuesday November 05, 2013 @06:03AM (#45334381)

    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 sus

  • by SplatMan_DK (1035528) on Tuesday November 05, 2013 @06:14AM (#45334417) Homepage Journal

    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

  • Naming it "Sponsor" would be a lot better. I really like the way LuaJit [luajit.org] 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.
    • by kale77in (703316)
      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.
  • 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.

  • by msobkow (48369) on Tuesday November 05, 2013 @08:59AM (#45334929) Homepage Journal

    Already been done. BountySource [bountysource.com]

  • 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?

  • Isn't that what so many FLOSS supporting slashdotter complain about when companies charge for patches and upgrades?
    • by Arker (91948)

      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.

      • by DaveV1.0 (203135)
        If they are going to give it away for free, why shouldn't they give away the bugfix for free? After all, as so many FLOSS supporters tell me, the developers of FLOSS projects are working on the project because they use the project's product. If one fixes it for one's self, shouldn't one release the fix for all, for free?
        • by spitzak (4019)

          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.

        • by Arker (91948)

          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)

    by mulvane (692631) on Tuesday November 05, 2013 @11:03AM (#45335635)
    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'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.
  • by znanue (2782675) on Tuesday November 05, 2013 @11:47AM (#45336113)

    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!).
  • 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

"Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." -- Howard Aiken

Working...