HN Explorer

Ask HN: Would issue “bounties” make contributing to open source more appealing?

108 points by Rperry2174 ↗ HN
I'm building an open source company (https://github.com/pyroscope-io/pyroscope) where we're very upfront about intent to eventually monetize via cloud-hosted version as many open source companies do.

We, in a way, have financial upside to people completing (some) of the issues we've posted, so sometimes it feels like it would be mutually beneficial to pass some of that through to the contributors as people contribute.

I'm wondering... if we added a "bounty/reward" in the issue text that said we'd pay $X amount for someone to resolve the issue, would that make people more or less likely to contribute?

On one hand it seems to go against the historic "vibe" of open-source, but on the other commercial open-source seems much more acceptable these days and would maybe be a nice bonus for the. contributor.

Any thoughts, experience, or ideas here? Anyone have experience really incentivizing people to contribute to open source?

96 comments

[ 5.0 ms ] story [ 173 ms ] thread
neolog
Why not just hire a contractor?
Rperry2174
Yeah thats exactly what we were thinking of doing...And then as we were sending them the "contract" it turned out we were effectively just linking to github issues...

So then I thought "How have I never seen a github issue where someone just puts in the issue 'I'll pay you X to do this'"?

yjftsjthsd-h
Well https://www.bountysource.com/ exists, so someone seems to be doing it. Unfortunately I couldn't say how successful it is.
ChrisGranger
There's also https://issuehunt.io/ which seems to be the same idea.
Rperry2174
Interesting... Yeah I didn't realize so many of these sites exist. Something seems to be preventing them (or especially one) to really gain prominence and name recognition.

My suspicion is that people contributing to open source don't really just contribute randomly. It is most likely that they use a library or repo and then they end up on the "issues" page because they had a problem themselves.

It's at this point where I would imagine one is most likely to convert into actually picking up an issue and when notice of a "bounty" might push someone over the fence (?)

Vivtek
I keep telling myself this is something I'd enjoy doing - but then I do something to scratch my own itches instead and live without the bounty.
freeone3000
Honestly, solving the problem is more of a push than any additional income. If there was a way to search for the bounty, maybe, but unless it's integrated into the project somehow, it's not worth searching out.
Nowado
Is this service ESCROW? It feels like 'number on the bounty' to 'actual payout' ratio may be not great otherwise.
maddyboo
Yes, at least for BountySource. To contribute money towards a bounty, you need to pay upfront and BountySource will hold the money in escrow.
Vivtek
There's https://gitcoin.co/explorer, too, and it's always got new jobs posted and people doing them.
mooreds
Came here to post this. I know some of the folks behind gitcoin and they've been pushing this effort forward for years.
satoshinm
I cannot recommend Bountysource - my first time using it, excited to contribute to some open source projects, I made a deposit and it was never credited. Reached out to Bountysource and they claimed they had no record of the fund transfer. Never received my money back despite proof of the transaction.

In 2018, Bountysource was acquired by "CanYa", a company known for their CanYaCoin ICO. As far as I can tell since the acquisition they have only gotten shadier (fair or not, I now associate them with sketchy cryptocurrency operations). Would not recommend.

I wanted to find a platform to fund open source development through bounties, but Bountysource isn't it - fortunately there are new alternatives popping up, hopefully more trustworthy.

edoceo
I've seen this a few ways, tried similar with some of our FOSS bits. Was easier to just get a few via 1099s to close many bugs than to manage dozens of one-offs.
Rperry2174
How did you convey that you would pay for them? For example I was thinking of adding a tag here (https://github.com/pyroscope-io/pyroscope/issues) similar to "good first issue" that says something like "bounty"
edoceo
We had a page on our site. it linked to bugs and bugs linked to it. bugs indicated their bounty. lots of overhead.
ksm1717
I think a bulletproof implementation of this would be a key enabler for a decentralized autonomous (anonymous) organization
Rperry2174
Not sure if it would work for 100% decentralized / 100% anonymous because someone has to be the authority on whether or not to accept the PR right?
ksm1717
You can trade bounty chips for POWER in the repo. And contributors could be anonymous, maybe not maintainers.
dboreham
No, this model doesn't work for me.
erezsh
It would make me more likely to contribute, if it was an appropriate amount of compensation for that issue.

In that case, I would also want to have a clear understanding of under what conditions my pull request will be accepted, and when.

kjrose
This idea has been around for a long time. I've always found that it never gets much traction. A combination of the amount of money offered and the amount of work required never really lines up.
Razengan
Or the quality of work received.
qbasic_forever
Well, one sure-fire way to make sure you can turn money into resolved issues is to hire people...

edit: Also the assumption that the 'vibe' of open source is free work-for-hire is a gross misinterpretation.

trinovantes
I doubt it'll work out.

Other than highly mechanical tasks, the time investment to resolve an issue is unpredictable. It's highly unlikely someone only interested in monetary compensation would just randomly pick up an issue in a random repo and work on it. There's a reason why most contractors bill by the hour rather than by number of JIRA tickets closed.

Even if there are people interested in the bounty, it'll eventually turn into the 99designs of coding: dozens of people competing to be the first to resolve an issue and that usually results in a drop in quality for speed (see Goodharts law)

Rperry2174
Yeah I guess I'm picturing it being more for "mechanical" tasks. For example, in our case we have a tag called "new profilers" (https://github.com/pyroscope-io/pyroscope/issues?q=is%3Aissu...)

Which TLDR is they are reporting agents for each respective language that send profiling data to our server.

I'd picture the bounty as us just giving an input and an output in the form of a set of unit tests and just saying: "if you create a java agent that passes these tests we will pay you $X"

Seems "mechanical" enough right?

zabzonk
> I'm building an open source company

Well, if you want to waste your time, and money...

Monetizing open source is very, very difficult. It can of course be done (I've made a few, a very few, quid out of it) , but it is statistically unlikely that you will do it.

Rperry2174
Lots of people have done statistically unlikely things :) thats where the funs at! High risk high reward
zabzonk
> High risk high reward

Also, high losses.

Grimm1
This has been my thought, I think ideally you start closed source, build your business and then open source things that are commodities to your business but never the core bussiness.

Just because we're writing an extension for it right now, MSFT VSCode is a great example of this. All of their actual magic "intellisense" is locked down but the editor itself is open because that's not where the money is for them it's in the code intelligence.

cperciva
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
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
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
> Why anyone rejects the code then use it anyway.

So that he does not have to pay bounty.

jimmy2020
> The whole idea is based on goodwill
btilly
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
> 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
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]
(comment deleted)
vimax
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.

rossdavidh
I think there's nothing wrong with offering a bounty for certain kinds of issues. Caveats:

1) it would need to be the kind of issue where it's pretty clear whether they did an acceptable job or not; some kinds of rearchitecting would just not be objective enough

2) you cannot assume that it will work; it should be a "nice to have" kind of issue, not a "we need this for the roadmap why hasn't someone done it yet" kind of issue

3) there is a lot of discussion among psychologists about the consequences of putting money on something, you might want to read this and ponder it: https://priceonomics.com/effectiveness-of-fines-for-late-pic...

Having said all that, I don't think anything horrible would happen if you just tried it out to see if it worked.

the_rectifier
Spot on. Most bounties are tiny and, as a FOSS developer myself, look discouraging or even a little bit insulting.
argc
Hire people to work on the project, so their incentives can align with yours. Like, its worth more to you for someone to spend a lot of time on the important issues and less or no time on the unimportant issues, but pay-by-issue would lead to people avoiding the difficult issues (important or not). You can increase the bounty for some issues but I doubt it will work.
argc
I was just thinking, maybe you could accept (detailed) proposals, and then the proposal writers would make a small commission when their proposal is selected, and then the implementer would also get paid for actually doing the work. This would help filter out drive-by contributions and payment would be determined by the helpfulness and difficulty of the proposal and effort to implement. You could have a maximum number of payouts per cycle, as well, and be upfront that payout is only guaranteed after the proposal is accepted by whatever process you put in place for review. Be upfront with high standards for the proposal review process as well. Still, I think it probably won't work.
cgb223
I personally think the idea of becoming an Open Source mercenary to be pretty cool, but it really depends on how acceptance criteria are set, how many people are allowed to work on it at the same time, and other means of making sure pull requests that are submitted are quality code vs quick garbage to make a buck
ngokevin
I have run large open source projects before with hundreds of contributors. From the maintainer side and imagining what it'd be like from the contributor side, I'm not sure bounties are worth it.

There's a lot of back and forth on the code reviews and no guarantee your code will be merged (and thus paid). You could address all code review comments and even then your PR may get ignored once it's all ready to merge.

From the maintainer side, PRs still take a lot of work to review and merge in. So you need to factor in the overhead of doing the code review and communications back and forth, and trying to parse someone else's code.

I think OSS is best built the way it's always been built, by passion or necessity from contributors. I think for more substantial projects, money for output works, but then it's better off going into a contract/agreement rather than having a bunch of contributors independently throwing in their shot.

On the flip side, I think the bigger problem is getting open source maintainers paid too, rather than fly-by contributors.

I also remember another company in my batch that did the same thing as well. I think they pivoted? You could talk to them (W18).

gitgud
> I think OSS is best built the way it's always been built, by passion or necessity from contributors

Completely agree. People who contribute need to care about the project, only a lot of money can make people care...

Also, as far as labour is concerned, writing the actual fix/feature is a tiny amount of work, compared to understanding the context around the project and it's use cases.

teruakohatu
Haven't some companies have tried giving away merch to people who send in pull requests? I can't remember who the last one was, but I looked at the repo and it was mostly nonsense changes to docs or comments like adding unnecessary punctuation. And that was just for t-shirts.

People even posted YouTube tutorial videos on how to submit a pull requests using github just to get a t-shirt.

If you inventive solving issues expect to get a lot of nonsense issues posted, and 30 seconds later "someone else" solving it.

jimmy2020
I am not sure if bounties can bring any value. Fixes and debugging require someone who knows the base code. It may increase the traffic of your repository but without a paid core team I find it hard to bring any meaningful value.
blihp
Bounties tend to not be enough money to be worth the time of the people with the skills to solve the problem.[1] The vibe of open source is largely a fiction when it comes to solving someone else's problem. Open source works because you solve your own problem and share your work/results, someone sees value in what you did and finds a bug / add a feature in an area of it that they care about and contribute it back and so on. Others don't have an interest in solving your problem(s) for the sake of solving them. That's called work... people have a bad habit of demanding real money for that.

[1] There are exceptions especially if one is a student / just getting started. But once you have some experience, bug bounties tend to look like underpaid homework problems.

infogulch
I think about this kind of thing a lot, but I haven't put much of it down in writing yet.

One thing I think is often overlooked is the value of writing a good description. I genuinely believe an issue in the form of a user story can require as much work defining the task as it does implementing it. Some contributions question, clarify, articulate, or integrate an issue so that the implementation becomes straightforward. If you can find a way to pay for that, then I think everything else becomes easy.

Another thing is that sometimes the best solution takes some exploration to find, but if you only pay for the final solution then the cost of finding it is not aligned with the price and the system cannot stabilize. I think this is similar to the problem that Science is facing where funding sources prioritize positive, novel results over the bare truth. I think if you find a way to reward experimentation even if it fails you will have solved a big problem. I think the key might be to realize (in both senses) the value in a failed experiment.

[deleted]
(comment deleted)
foobiter
If bounties can’t outpace salary then no, not really.
lyoshenka
My company (lbry.com) tips contributors for opening good issues, PRs, reporting security vulns, even for good blog posts or tweets (contributions are not limited to code). There’s nothing formal. We just try to be fair and generous, and let it be known that this is something we do. Over the years we’ve built up a bit of a reputation for this.

Certainly this system could be gamed or become more hassle than it’s worth. We’ve only seen that in narrow cases (e.g. during hacktoberfest). On the whole it’s been great and it feels good to do it.

I encourage you to try it and see how it goes.

More here: https://lbry.com/faq/appreciation