4 ms·

Public open source code bounties run into a market-for-lemons issue: The people who have the strongest incentive to pursue those bounties are the people who don

Public open source code bounties run into a market-for-lemons issue: The people who have the strongest incentive to pursue those bounties are the people who don't have a reputation for making high quality contributions. This can be mitigated slightly via code review, but at a certain point you spend more time and money fixing code than it would have cost to write it in the first place. The only way I've seen this work is with a pool of users contributing money and then an "internal" developer -- someone well-established in the project who is trusted to write good code -- stepping up and saying "ok, for that much money I can turn away other gigs to work on this". The catch is that you need to decide which developers are trusted to do the work, and you can run into political difficulties.

SteveNuts 6y ago
There seems to be a lot of conflict of interests here. For one thing you could reject the code during code review then use it anyways, basically plagiarism. The other issue I could see would be people creating bugs on purpose to squash them, lowering the overall code quality and creating churn.
- jimmy2020 6y ago
  The whole idea is based on goodwill. Why anyone rejects the code then use it anyway. The second issue is valid for open and closed source. Free or paid. There are always people who want to contribute regardless of the value they bring, and that doesn't affect the quality of the code because you aren't merging without reviewing the changes.
  - watwut 6y ago
    > Why anyone rejects the code then use it anyway. So that he does not have to pay bounty.
    - jimmy2020 6y ago
      > The whole idea is based on goodwill
- btilly 6y ago
  The biggest problem is people submitting code, it being rejected, a working solution using similar principles being accepted, and then accusations of plagiarism. With the same people always submitting the accepted code. The fact is that their work gets accepted because they followed coding standards and understand how to not undermine the project design. But people who have not internalized coding standards or the overall project design will not see that and get upset that they don't get paid for at least showing how to solve the problem. (Nevermind that the part of their solutions that they point to would have been obvious to anyone.)
- jobigoud 6y ago
  > The other issue I could see would be people creating bugs on purpose As a side note this particular perverse incentive also exists in the world of proprietary code security bug bounties. That's why bounties cannot grow to truly enormous amounts.
fblp 6y ago
There are assumptions about how the bounty could work here. What if the bounty is $1000/mo for 12 months? What if it is split amongst contributors in a pre - determined way?
- deleted 6y ago
  [deleted]
vimax 6y ago
I agree. The pool of people that could submit code to a project is much larger than the pool of maintainers who could effectively integrate those contributions. At some point an issues bounty will start wasting everyone's time. It encourages people investing time in contributions without a full understanding of the codebase. This is turns puts pressure on maintainers to keep up in spite of areas they want to work on. And when contributions are are ignored it creates a rift and misplaced ill will.

SteveNuts 6y ago

There seems to be a lot of conflict of interests here. For one thing you could reject the code during code review then use it anyways, basically plagiarism. The other issue I could see would be people creating bugs on purpose to squash them, lowering the overall code quality and creating churn.

jimmy2020 6y ago
The whole idea is based on goodwill. Why anyone rejects the code then use it anyway. The second issue is valid for open and closed source. Free or paid. There are always people who want to contribute regardless of the value they bring, and that doesn't affect the quality of the code because you aren't merging without reviewing the changes.
- watwut 6y ago
  > Why anyone rejects the code then use it anyway. So that he does not have to pay bounty.
  - jimmy2020 6y ago
    > The whole idea is based on goodwill
btilly 6y ago
The biggest problem is people submitting code, it being rejected, a working solution using similar principles being accepted, and then accusations of plagiarism. With the same people always submitting the accepted code. The fact is that their work gets accepted because they followed coding standards and understand how to not undermine the project design. But people who have not internalized coding standards or the overall project design will not see that and get upset that they don't get paid for at least showing how to solve the problem. (Nevermind that the part of their solutions that they point to would have been obvious to anyone.)
jobigoud 6y ago
> The other issue I could see would be people creating bugs on purpose As a side note this particular perverse incentive also exists in the world of proprietary code security bug bounties. That's why bounties cannot grow to truly enormous amounts.

fblp 6y ago

There are assumptions about how the bounty could work here. What if the bounty is $1000/mo for 12 months? What if it is split amongst contributors in a pre - determined way?

deleted 6y ago
[deleted]

vimax 6y ago

I agree. The pool of people that could submit code to a project is much larger than the pool of maintainers who could effectively integrate those contributions. At some point an issues bounty will start wasting everyone's time. It encourages people investing time in contributions without a full understanding of the codebase. This is turns puts pressure on maintainers to keep up in spite of areas they want to work on. And when contributions are are ignored it creates a rift and misplaced ill will.