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

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

108 pointsRperry217493 comments

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?

View on HN

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.

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.

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.

> Why anyone rejects the code then use it anyway.

So that he does not have to pay bounty.

> The whole idea is based on goodwill

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

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

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?

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.

I think the following suggestion is most likely extremely naive, so please bare with me.

Reading the valid criticism here of such a scheme, why not just approach some contributors, ask them if they would like to contribute more, and offer them short term contracts / rewards for their work?

"We've seen your activity on our issue tracker and we would like to hire you (short term for now) to help us out (home office work). Are you interested, and if so, considering other obligations you might have, how many hours a week would you be able to contribute to the project so we can ballpark a first payment?"

Alternatively you could simply pay for contributions already made to the project. Cherry-picking the contributors you want to see more of seems to be a good system? Even considering the effort this would cause, I do think your idea would be even more cumbersome, as you would have to set up a system to evaluate every single contribution.

I know of a nice open source project, where the lead programmer used part of the project's funding (plus even some of his own assets as far as I know) and more or less out-sourced a lot of work partly to one of the project's most loyal contributors, who he's been working with. Said individual is somewhere from Eastern Europe, where even a "relatively small" amount of money comes a long way. Everyone involved (project lead, the person hired, the community) benefited greatly.

> "We've seen your activity on our issue tracker and we would like to hire you (short term for now) to help us out (home office work). Are you interested, and if so, considering other obligations you might have, how many hours a week would you be able to contribute to the project so we can ballpark a first payment?"

I think this only really works when you reach a certain size and/or get lucky with really good early contributors. I did a quick analysis of the repo and this is one year of activity:

https://public-001.gitsense.com/insights/github/repos?q=wind...

Right now it looks like petethepig is doing the lion share of work (switch to the impacts view to see this) and I'm not sure if they have enough previous contributors to really pick from.

Side Note: Don't download my tool as the current docker image has an expired license which I need to sort out when I get the time.

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

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.

Well https://www.bountysource.com/ exists, so someone seems to be doing it. Unfortunately I couldn't say how successful it is.

There's also https://issuehunt.io/ which seems to be the same idea.

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 (?)

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.

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.

Is this service ESCROW? It feels like 'number on the bounty' to 'actual payout' ratio may be not great otherwise.

Yes, at least for BountySource. To contribute money towards a bounty, you need to pay upfront and BountySource will hold the money in escrow.

There's https://gitcoin.co/explorer, too, and it's always got new jobs posted and people doing them.

Came here to post this. I know some of the folks behind gitcoin and they've been pushing this effort forward for years.

There are a number of open source bounty sites documented on the FOSSjobs wiki:

https://github.com/fossjobs/fossjobs/wiki/resources#bounties

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.

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.

No for various reasons:

1) We don't live in a gift-based economy. Companies approve budgets for software purchase every day but cannot easily justify donations for many reasons.

2) Individuals have to choose between donating to a software project, or to famous charities fighting poverty and diseases, or save money in case of any future rainy day. Difficult to justify donating to FOSS: you cannot even ask your money back in case of a health emergency.

3) Developers want long term employment/contracting based on trust. Being offered occasional work on bounties can feel dehumanizing and unprofessional.

4) Most bounties are very small and tend to attract only very unskilled developers.

I recently started reading Nadia Eghbal's book, "Working in Public: The Making and Maintenance of Open Source Software" [0]. One point she makes early on is that attracting lots of people to open source projects isn't all that hard; but managing lots of potentially low quality contributions is really hard. See "Hacktoberfest" for an example. [1]

If you pay $X for someone to "resolve" the issue, when they submit a patch that doesn't work, or doesn't follow the style guide, or doesn't fit the software architecture, or is otherwise unsatisfactory, how much time are you going to spend fixing/massaging/arguing? Will it be worth it to answer the jilted contributor who keeps sending "I want my $50!!!!" emails?

Nadia also has a quick 10-minute presentation on some ways you can use money to help open source, but without actually paying for bug fixes. [2]

[0] https://smile.amazon.com/dp/0578675862 [1] https://blog.domenic.me/hacktoberfest/ [2] https://www.youtube.com/watch?v=bjAinwgvQqc

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.

Or the quality of work received.

As someone who doesn't have enough technical expertise to build the features in open source projects an active donor to projects I support this kind of idea. I wouldn't call it a bounty though, more like gofundme for certain features. In some cases i'd pay $1000+ for some features to be built, and ideally others would join me.

Here's an example of a feature I'd want to financially contribute to that has a lot of support: https://github.com/RocketChat/Rocket.Chat/issues/2049

From my perspective it is the killer feature that enables me to switch from slack, saving my business hundreds of dollars a month. I can't just "hire a developer to do it" - the best deal would be if one of the existing contributors did it.

Also, some open sources struggle with funding and priorities - I'm sure there's features out there where the community would commit tens of thousands of dollars (Kickstarter style)

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)

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?

Mostly speculation: In order to avoid getting submissions that check all of the boxes for the feature but are a jumbled sloppy unmaintainable mess of code I would think you would need to have some kind of way to track developer reputations (e.g. a stackoverflow-ish solution). This would also allow you to turn it into a bit of a game of prestige where money is not the only incentive. The other problem I could see is multiple reputable developers doing the same task in parallel, but one submits it before the others and gets the bounty. I think that would annoy the developers that were not the first submission for a given task. In order to avoid that, you would need some kind of locking algorithm to ensure only one reputable developer is working on a given issue. You would also need to penalize developer reputation for not following through on a task.

You could also try out some kind of bidding process for issues with issue auctions having different minimum reputation levels that developers need to be above in order to submit a bid. Newer developers could bid on the easier/simple tasks that pay less, but for more advanced features or features that have a tight time frame could require higher reputations and pay accordingly. At this point though, it starts to look a lot like a separate start up that uses contracting work, but maybe the social aspect of reputations could get more better work done for a cheaper cost.

May turn out to be a little tangential, but do read Cory Doctorow's article on IP - https://locusmag.com/2020/09/cory-doctorow-ip/ - if you haven't already.

A few things stand out in your request for me (imho) -

1. Open sourcing software in order to get free contributions is .. not a fair exchange. In most circumstances, your software is likely only useful to your company, or one that builds something off your tool for a competing product ... or attract uncouth elements like what happened with DigitalOcean's OSS contrib promotion earlier.

2. Open sourcing components that facilitate _interop_ with other systems seems worth it and would help your ecosystem grow while also serving your users. Do you have pieces you can cordon off like that?

3. You're already making a contribution to society by building your product. So don't beat yourself up about not "contributing to open source".

4. If you're prepared to pay your contributors, might as well spend that budget hiring staff to work on your product? It would save a lot of effort in figuring out who to compensate, besides you'll need a few folks in your company paying attention to what's happening with your repos instead of working on your product .. thus potentially reducing velocity.

How do you make sure only one person is working on a bug at a time, or if more than one does, how do you split the bounty? I'd be pretty upset if I worked on an issue and then someone else got the bounty or I had to split it, unless I knew that ahead of time.

And if you're going to pre-qualify people for a particular issue, you've basically just gone down the "hire a contractor" path, so you might as well just hire a contractor.

I can't see any reasonable way to make this work.

I think you actually might hurt the project by doing this.

The main motivation for contributing to open source is altruism and/or the desire to contribute to something meaningful and/or have something for your resume.

By paying people, you make it about the money, and likely the money is far below what someone with the skills to really contribute could make. That gets them thinking not about the money and not about how fun it would be to contribute.

I feel like this is a bit of a false dichotomy.

For example, my reasons for my (relatively insignificant, but still) FOSS contributions include everything from altruism to scratching an itch to satisfying my intellectual curiosity. If I didn't have bills to pay, I'd probably be making a lot more FOSS contributions, and a lot more regularly.

However, at the end of the day I do have bills to pay, so for better or worse the code I write ends up being the code that gets me paid. Right now this is from a day job. Bounties could instead position FOSS as the code that gets me paid. Maybe one of these days I'll have Patreon/Liberapay/etc. contributions sufficient to keep me afloat (or, for that matter, greater than $0), or my country would extract its cranium from its rectum and entertain the idea of a universal basic income, and then I can dedicate my time to whatever I wish, but today is unfortunately not that day.

That is: the "conflicting" motivations of "money" v. "fun" ain't mutually exclusive. These are both "compensation", in a sense. If I'm already making contributions because they provide "fun", then said contributions only need to provide as much money as I'd need to save up money and not starve; anything beyond that is just gonna go toward fun anyway, which contributing to FOSS already (hopefully) provides.

There have been countless FOSS-centric bounty sites since the late 1990s. They never took off in a significant way and now people are using subscription-based platforms like Patreon and Liberapay: https://github.com/uraimo/awesome-software-patreons/

I guess in hindsight one could say that bounties are too messy while a subscription-based approach is much clearer (less managing overhead etc.).

Quoting from https://wiki.snowdrift.coop/market-research/history/software

"Many bounty sites have been tried over many years. Some sites that have come and gone: The Free Software Bazaar, CoSource, Fundry, Public Software Fund, BountyOSS, BitKick, COFundOS (which alled users to place bounties for new applications as well as for changes to existing programs), Opensourcexperts.com, Donorge, Bountycounty, Bounty Hacker, microPledge, FundHub (some unrelated site uses that name now, not surprisingly), GitBo, Catincan, DemandRush, and Open Funding (broken though the main domain openinitiative.com still exists) — and probably others we never discovered. GNOME and Launchpad each made attempts at supporting bounties but that never came to anything substantial. FOSS Factory (which is still live but has had no activity for years) bothered writing their own essay on the history of other failed bounty sites."

You might also want to check out https://wiki.snowdrift.coop/market-research/other-crowdfundi...

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.

Honestly, I'd guess that it would hurt more than it would help. People tend to put things into mental buckets of monetary-based or favor-based relationships. For example, I wouldn't agree to do 4-5 hours of manual labor in exchange for $20. On the other hand, I would help a friend move to a new house/apartment for snacks and pizza. Those two have the same level of monetary reward, but one is being judged as a social tradeoff.

There was a study about a neighborhood daycare center that was trying to avoid parents being late to pick up their kids. The daycare instituted a penalty fee if a parent is late to the pick-up. From an economic perspective, this is a larger cost, and should result in one-time pick-ups. Instead, people were consistently later in picking up their kids. Before money was added to the equation, it was "Person X, who I know and enjoy talking with, is troubled when I am late. To avoid hurting their feelings, I should be on time." After, the situation changed to "Being 30 minutes late is a $10 fee. I still need to get groceries today, and that is worth $10." By thinking of it in monetary terms, people stopped considering each other as much as people. Even when the fee was removed, the damage had already been done, and the late pick-ups continued.

My guess is that you might get a few more contributors here and there, but it would turn off more than would start.

For me personally, I've spent time fixing bugs in open-source javascript libraries that I happened to notice while browsing. It would have felt a bit off had there been a monetary reward, because that wasn't why I made the bugfix. Or one time I made a character builder for an out-of-print RPG system, and was beaming for weeks at being mentioned in that company's weekly newsletter. Had they tossed me $50 for it, objectively I would have been better off, but rather put out. $50 would have shifted it from a social exchange into a working exchange, and not one that valued the months of evenings/weekends that were spent in development.

That said, a lot of it depends on the amount. Other posters have recommended reaching out to offer part-time jobs to contributors. This sounds like a reasonable route, so long as it is at a reasonable hourly rate for the full time contributors put in, not just the difference from before. Remember, by making the offer you are taking away the entire social exchange, and need to make a good enough offer to counteract that effect.

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.

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.

As far as incentives go, bounties are like contract programming, only coupled to the roulette of being rejected or gazumped, which dramatically reduces the effectiveness of the inducement.

The main barrier I experience when contributing to open source projects is being ignored by the clique. If you're short on the time, energy, or disposition for joining the in-group, then set expectations low: feature PRs, and sometimes even simple bug-fixes, may go ignored for long periods, and receive only cursory attention.

(There are exceptions to this. I'll call out three projects I remember for very positive interactions despite being a drive-through contributor: Dovecot IMAP, and Ruby on Rails, and, showing my age now, wu-ftpd).

From my own experience, solutions to the social dynamics move the needle more than financial incentives. By which token I reckon the most effective agent of the last three decades was Github, but there is plenty more to do.

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.

Spot on. Most bounties are tiny and, as a FOSS developer myself, look discouraging or even a little bit insulting.

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

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

I started contributing to a certain open source project that gets lambasted on here a lot last summer. After some contributions, a bounty using my skills became available. I jumped at the chance and completed the bounty. That led to more contributions in the same area as the bounty. I would certainly say it's worked out for me and the project in question.

Many other people have been similarly incentivized and compensated on the same project to the point where probably 2/3 of the development comes from the company that started it and the other 1/3 is bounties.

Like this? https://rysolv.com/

// incentivizing people to contribute to open source//

That is the problem right there. As Alan Watts used to say "It is double bind". Kind of saying "you MUST love me spontaneously"

open-source or closed-source 1)volunteers will do volunteers using their own "free will"- You don't have to do anything 2) If you want "influence" 1 then it is not 1 so hire professional and pay money to do work.

It would have to be done carefully with respect to compensation for your actual employees. What if one of them fixes an issue with a bounty, is the bounty price in line with the approximate hourly wage of the employee? Would you be paying anonymous contributors more for the issue than what an employee would received?

What about employees in their off-time? Can they collect a bounty on issue completed outside of normal work hours?

I believe it can work, probably best to start it with a small group (<10) of known high quality contributors who are actively working with you and giving feedback on the process.

You are going to be trading your time, creating bounties that are objective, testable and fair.

This model is just too interesting for it to never get figured out. I am sure at least one successful case will happen (if it hasn't already) in the next ten years.

I've worked with groups with small bounties and toxic environments. I'd rather have less drama in my life. Remember, good engineers can make money.

Programming is one of the few things I love in this world, and these groups made me start hating it.

I hope you can keep your feedback and leadership positive, I think it's too late for some areas I've worked in.

Also, consult a lawyer on legal issues with compensation and volunteers.

If you want to raise some (small amount of) funds for specific issues, try https://github.com/uav4geo/quadratik. We had some good successes with OpenDroneMap using this model. https://fund.webodm.org

I don’t have an answer for you. But I remember finding a lot of research on the subject published on First Monday many years ago:

Just the first hit searching now: https://firstmonday.org/ojs/index.php/fm/article/view/1488

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.

Why not just hire a contractor?

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'"?

> How have I never seen a github issue where someone just puts in the issue 'I'll pay you X to do this'

Here’s an example of that, kind of: https://github.com/debauchee/barrier/issues/109

There was https://www.bountysource.com/ but IIRC they lost some goodwill a couple years ago due to some shenanigans that I don't remember the details of.

The math almost always just doesn't work. I don't think I've ever seen a issue bounty of over $1000, yet all but the most trivial issues are probably going to take at least a few hours to resolve. For issues that attract significant attention, it is probably more like 20-50 hours (or more!). There's just no way to justify that much time to earn what amounts to at most a handful of hours pay on a typical software developer's contracting rate.

The real problem is that a bunch of people pledging $5 or $10 or even $100 just isn't going to add up to enough.

Surprisingly, I've noticed a different trend. You're right, the math never works out to a comparable tech salary.

But similar to the rest of open source development. People are not purely motivated by money. Developers work on issues all the time with zero financial incentives.

And in the case of bounties, I think that the dollar value becomes a proxy for how much people care about the issue. Especially when several people give in $5, $10 increments. It's a lot better than just clicking the :thumbsup: on an issue.

Sure it doesn't add up to a full time salary. But it's a nice way to triage issues that people value.

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.

There was a significant number of companies doing this for Hacktoberfest 2020: https://hacktoberfestswaglist.com/

This is not a solved issue and bounties simply result in a lot of free work with no assurance of being paid, and there is nothing the company can do to fix that which doesn’t result in the company being taken advantage of.

There is no way to compensate based on code amount or code commits or anything.

Feel free to change my view! But basically you just need to sign on everyone and pay them based on time with bonuses based on milestones. Or just hire people the normal and time consuming way.

I think hiring people traditionally is better for the bulk of the work. If people want to contribute for free they can, what they’d get out of it is if they get to choose what to work on eg fix the bug that is most annoying to their company so a win win. I’ve seen this done before and think it works well.

Plug-in architectures can also help so people can contribute to an ecosystem with their own open source free/pro edition work like is done with Wordpress.

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.

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"

We had a page on our site. it linked to bugs and bugs linked to it. bugs indicated their bounty. lots of overhead.

So what happens if I spend 2 hours on a ticket, but submit it 10 minutes after someone else? Do you have people "reserve" tickets? What happens when someone just keeps high-value tickets "reserved" and prevents others from working on them? What if I submit a better solution? What if you find a bug in my solution but I'm not available to work on it for another week? Do I get 1/2, 3/4?

Gitcoin recently raised 13M for this purpose. They are crypto-first, so for fiat it can be interesting to think about it, I have been thinking around building such a platform. https://decrypt.co/66541/ethereum-gitcoin-raises-11-million-...

I wouldn't say that it would make it more appealing exactly, but it definitely seems like it might make it more possible for many people. There are lots of folks who could contribute code and, for whatever reason, need to spend their time on side gigs or working overtime. Paying for open source contributions means they could replace other income supplementing activities.

People have tried this about a million times. It never works.

Writing the code is not the hard part. Verifying its good quality is. Bounties encourage people to do the absolute minimum which works poorly.

Compare that to security bug bounties. Its much more binary - you either hacked us or you didn't. Even then, 90% of submissions are crap and sorting through bad submissions is a significant effort

I think a bulletproof implementation of this would be a key enabler for a decentralized autonomous (anonymous) organization

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?

You can trade bounty chips for POWER in the repo. And contributors could be anonymous, maybe not maintainers.

This would be good for me since I don't have bandwidth for a full time job now but I want to work on something. I would need a way to acquire a lock on an issue so nobody can swoop in and finish it right before I open my PR. Let me know if you want to go through with the idea.

Somewhat similar is https://huntr.dev

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

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

> High risk high reward

Also, high losses.

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.

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.

Just wanted to say thank you and I wish you luck. Even if you only correct a few major bugs it will make a big difference.

No, this model doesn't work for me.

All your ideas are of value for our FLOSS MOOC! I'll make sure we integrate some of these ideas in it. If you're interested and want to contribute: https://gitlab.com/mooc-floss/mooc-floss/

LBRY does this with success.

You're saying they incentivize people to contribute to their github repo (https://github.com/lbryio/lbry-desktop/issues)?

Or are you saying that they specifically pay people to do so?

This model worked really well for me and several others some time ago - but the conditions for that may not translate to your project and other not-so-popular ones.

I loved finding feature requests for rocket chat on bounty source years ago - this gave use lowly users the ability to crowdsource how ideas should be implemented and crowdfund them. I found many other people who really wanted to add the option for 'login without email addy or registration' and to hook that login into permissions options already established.

Together we put in over $600 I think, which I believed would be a pretty simply code chunk to add. That amount got the attention of a coder who knew the rocket chat system and decided he could get it done in a short enough time to make it good money per hour for him and he put it together and it went to code review and they added it!

I started to imagine how powerful this could be for wordpress and similar - but some story broke about bounty-source that made it fade - like said elsewhere in thread https://news.ycombinator.com/user?id=neolog , don't recall what it was at this moment either.

With wordpress you can kind of do this - but it's less crowdsourcing and more try your luck with codeable or freelancer or whatever - and you won't get a code review from the core WP team, and it likely won't become part of 'core' so you'll have to maintain updates, breaking code and security and crap all on your own - but it's kind of an option nonetheless.

I have really wanted to do this with matrix/synapse / fluffy/element - as there are important mods I think should be implemented immediately - and they already have a roadmap with priorities and those are gonna take a while.

So I think for popular projects with lots of users it can be a boon for features being developed and it could work out good for everyone. Your project may not have enough people with eyes on for the same kind of thing. Maybe hiring a contractor that gets subcontractors to take care of the small things for you would be better at this time?

I'd love to see a bountysource reborn with variable options, and glad to see others mention similar portals that I am eager to take a look at.

If I had a big project going, I'd like to be able to make an 'official page' on a portal like so that could setup revenue splits as well - as I can imagine it would be easy to get overwhelmed with new code chunks being sent and it would take time and money to review security and how things in this new chunk could affect other things and all that.

I'd also put up a page where people could vote a thumbs up, as well as the vote with held in escrow dollars that I enjoyed with b-source time ago..

I'd consider giving users who bought a premium copy or pay for premium cloud or whatever to get 20 'super likes' per renewal so they could collectively vote up feature requests.. often I/we/I notice others, are quite surprised at what they users want most while we work on features we think are most important.

last note - with you coming out with a premium version in the future - as a 'bounty coder' or funder - I might feel slighted paying or coding for open source with the premium version coming at a later time - I think it's important to note that boldly so no one is surprised by it - and offer a guarantee that code will still be available - like wordpress does. I'd hate to spend time or money on something that was set to take advantage of that and then wall off and drop everyone ala fbook and google with xmpp kind of situation.

Hey, I'd love to hear what you think about http://rysolv.com/

Still pretty early stage development. But we're building out some project management / crowdsourcing side to the application as well.

Quick scan, seems like the kind of thing I would like to use - as putting bounties on issues and putting up money for them is great. The ability to crowd source this is even better.

However as rysolv is right now, the first two lines keep me glued, the third line: "Import an issue from Github that you think needs more attention. This can be one of your issues, or from a project you support."

I'm lost.

I start to scroll a bit.. the next section with pics - I have to squint to try to see what they are about.. I see the text to the left is talking about github this and language specific to git.. so it's not for me.

I've been publishing web sites since around 2003, I do ftp, cpanel, directadmin, plesk, some linuxes stuff, php.. been modding wordpress sites since it first cam out, css.. But I don't git (yet)..

I have hit github hundreds of times since so many people link to stuff there - and I eventually figured out how to download a package from there a couple times - but the layout makes me want to pull my hair out, and how it really works I don't know yet - and me wanting to give money to developers shouldn't be impeded by me now understanding git terminology and navigation.

I was able to quickly see a list of stuff on bountysource some years ago - and click to support issues presented there - and add some text and all that - and I think anyone without developer experience could chip in the same way.

I'll eventually learn git,and hopefully find a way to skin it and remove the big box at the top begging me to sign up and probably enjoy how great it is one day - since everyone seems to like it - but I'm in no hurry, and I'm super busy already.

So maybe it's a great presentation for those who know git on site and don't struggle to understand push, pull, issues, branches.. I still don't understand why some let me download a zip in a click and others have me looking for tabs -

anyway - I'd maybe make the front page you have now as a how-to for developers looking to get paid to see how it works - and make a different how-to for people that want to get shit done and have some cash to throw at issues.

There are plenty of people who have some dough to spend, and want features for apps, and have less tech experience than I have. I'd suggest a list of popular feature request, an easy way to search for feature requests other have posted.. and at the end of the search page a "new issue creator" (dang that git language sneaking in, perhaps "post a new..bug fix. feature request.." and have the search term they just used already filled out for the title..

then they could just add a few more details, hit a check box, and put in their email for confirmation..

or something like that.

If bounties can’t outpace salary then no, not really.

Reply on news.ycombinator.com