When I see this kind of bounty for open source projects, I immediately think of this psychology anecdote: when you tip people to give their blood or sperm, the number of donor goes down, not up. Why? Because you don't really pay them, it's too low to matter and never covers the time spent anyway (even at the minimum wage). Yet, now people are not giving it, it became part of a transaction and it completely changes how the reward mechanism in the brain is stimulated: when giving, you're proud of yourself for giving, when in a transaction, the amount matters.
In order to have a net positive effect, such a program would need to be able to generate an income, not necessarily a engineer market-level one (because you could have students working on this) but at least something above the minimum wage[1], not just tips.
[1]: and at this level, you'd still not attract more affluent kids who don't need a job.
The book Predictably Irrational has a great section about this. Basically we have a "market" way of thinking and a "social/gift" way of thinking about goods. When something is free we think of it in the latter way, when it's not, we use the market mindset. And the transition can be jarring - say you're selling cookies. If you lower the price, people buy more cookies. Lower it a lot to, say $.01 per cookie and people will buy all of them. Then lower it all the way to free and people will suddenly take fewer again. Why? Because when you buy all the cookies at $.01 you're a shrewd merchant, but when you take all the free cookies, you're the asshole who took all the free cookies, so there's none left for everyone else. It's two different mindsets, leading to a discontinuity in the supply and demand graph.
Yes, there are also related examples of this in some of Ariely's books. If you introduce a fine for showing up late at daycare the number of late people and the average lateness goes up, not down, because then people are "buying" the right to be late for example.
There were some issues with the paper you're citing ("A fine is a price"). I believe a grad student wanted to replicate their analyses and they told him the data had been lost, which is pretty weird. I wonder if anyone has replicated the experiment.
> they told him the data had been lost, which is pretty weird
I don't think that is weird at all. After the lead student on a project leaves, the faculty, especially non-technical or not so organized ones, may not even know how to access the data anymore. Who knows what arcane scripts or processes are needed to get it in a shareable form.
There can also be hoops with the IRB to jump through and a lot of effort in general to give someone access to data. I had an IRB insist that all raw data be deleted after 2 years of collection anyway, so by the time the paper got published the raw data had to be deleted forever.
I wish it were easier to release data and replication kits, but sadly the incentives aren't there.
For big names in a field not to know to keep their data - certainly today, that would be shocking. I think it was quite shocking even back then. I still have my data for my work from my PhD in the 2000s. It isn't a job you'd leave to a student. IRB hoops are a different matter - but this wasn't that, as I recall.
Or maybe if you do not have a specified fine, then in the heads of people there is still a “virtual fine” associated with being late, but it is not an exact number, but a wide range, and people tend to predict all kinds of bad things that would happen (but 99% of times it wont happen), so the fear of an unknown punishment is higher than a known one.
Intuitively the present value of punishment is amount of punishment x probability of getting it, and if the second term is nil then so is the punishment; but according to many studies I believe the amount of punishment is much less important and being caught is what matters.
Interesting because if the supermarket/grocery store has a 0.01 steaks and someone placed the whole lot in their trolley I am very sure people will posting about the asshole on social media
I'd say so - it's a very accessible introduction to behavioral economics. Similarly, "Stumbling on Happiness" is an easy introduction to the psychology of happiness, but also tells you a lot about perception, memory and decision-making, and the illusions and biases we have. And finally "Thinking, Fast and Slow" is a slightly deeper and longer but still accessible book that digs into the details about how many of the biases we have (that the other books talk about) arise due to the interplay between the conscious and unconscious parts of our brains - it felt like a deeper explanation, but I'm glad I read after reading about most of the biases before in the "lighter" books.
> In order to have a net positive effect, such a program would need to be able to generate an income, not necessarily a engineer market-level one (because you could have students working on this) but at least something above the minimum wage[1], not just tips.
The pay scale is going to be tough. Looking quickly through the top bounties, none of them are really student level. Issues that are truly good for beginners or someone unfamiliar with the codebase in any moderately popular open source project usually get scooped up immediately for resume building.
I can see this as being useful for abandoned projects, or as a way to promote something new. It's a much better signal that the ticket is actually meaningful and impactful than a GitHub tag.
Whether that is enough to get past psychological barriers behind transactions, I don't know. I do like the "buy the author a coffee or two" mentality of support, which I think does remove some of the transaction aspect of it. Not sure if this is what Rysolv was going for -- it feels a bit more formal.
I have funded a couple issues at like $25 that were marked "Good First Issue". And I had a couple people reach out saying they were excited to have done their first pull request.
So I think that even with small bounties, rysolv can have the positive affect of introducing more people into OS contributing.
And if the site ends up making money, I think there should always be a list of "First Time Only" issues.
> Spend a week working on this issue for free? No problem! I love to contribute to software I use.
> Spend a week working on this issue for $50? No way! I'd never work for so little.
I can certainly see it having this affect. And hopefully there will be ways to mitigate it. But I don't see any harm in trying to bring some additional funding into OSS development.
Also I feel like it would be nice supplemental income for sole maintainers, who would likely be tackling these issues anyway.
Paying bounties for people to fix issues removes the altruistic aspect of being a generous open source contributor. Instead it makes you seem like a money grubbing bastard that’s hard up for cash.
This is great. Other comments here are underestimating the power of a group. An average bounty on an issue might just be between $10-$100 but there can easily be 50 people putting up a bounty for a popular issue (have you seen issues with hundreads of upvotes and are still open for years). If we start seeing (collective) bounty on an issue in the range of a few thousand $$ then it's decent money for maintainers or anyone else who's motivated enough.
My guess is this is eventually going to be built into GitHub (via acquisition or otherwise).
Open source is a public good, which means open source bugfixing is likely to be undersupplied by private demand. I think this needs a kickstarter-like way for groups of people to "contribute only if others also do so".
Was just thinking the same thing on the “built into GitHub” thing. Being able to easily see the current bounty directly in GitHub and donate $10 to the bounty with one click I imagine would make adoption blow up.
Yeah and now extend this idea to start a bounty of 100$ for the maintainer of a library/framework to merge your pull request, completely new ways for open sources projects to be paid for their hard work.
I think this is inherently limited to small, low-effort issues, for a number of reasons.
If I was to set a bounty for an issue that would be laborious and therefore expensive to fix, I'd want to be able to withdraw my funding in case the issue does not get fixed in a reasonable amount of time. Leaving money tied up on the service indefinitely is not really an option when you start talking about the kind of money that would actually motivate someone to do a lot of work.
This creates a problem where it's really risky for a developer to take on any hard problems. If funds can be pulled at any time, you might not get paid. Also, of course, there's duplication of effort- someone might beat you to closing the issue, meaning you get nothing and have wasted your time.
This, in turn, means that pricing on the service must be very high to account for the risks of non-payment, or be so low as to be insignificant.
There are some mitigation strategies available. Funding could have an end date, after which the funds are returned to the funder. This still leaves the issue of parallel effort, which seems harder to solve. Preregistering to close an issue by some deadline might work, but likely would result in a lot of issues going unsolved, and now you need some kind of ranking system for developers on the service...
> Leaving money tied up on the service indefinitely is not really an option when you start talking about the kind of money that would actually motivate someone to do a lot of work.
This is something that I've been going back and forth on for a while. I've considered having the money be a 'pledge' like Kickstarter. Where people pledge the funds and pay out when the issue gets resolved.
But that can add some technical concerns (keeping track of peoples bank details to charge them) as well as less assurance that the developer will get paid.
And I especially don't want to have a platform where a developer puts in the work and doesn't earn the bounty.
Parallel effort is another tricky one to solve. And I see it all the time even without funding involved. Someone comments that they're working on an issue, and then everyone else drops it for 6 months only to realize that person dropped it too.
I think that splitting bounties could be a good solution. Have multiple people contribute towards a branch, and the funding gets distributed evenly.
Ideally parallel effort could be rewarded and combined. Have frequent communication between requestors and aspiring resolvers. The requestor could release a portion of the funds in exchange for the two developers publishing their wip and exchanging ideas. Both would get paid.
There are a couple of things missing from your “how it works”:
- Please clarify what happens to funds when a bounty isn’t claimed.
- Is it possible to retract funding?
- As another commenter pointed out, what about situations where the involved parties would rather not use Rysolv? If a funded issue is closed, what happens next?
Also it would be nice if I could fund in €.
Concretely, I wanted to list
https://github.com/grncdr/otssh/ on there. I’m offering 500 € for the creation of a fairly simple program, but I want to know what happens to my money before in the above situations before handing it over to Rysolv.
I just added a section to the README about this, but my main use case is admin access to shells inside of containers run in managed environments where `docker exec` (or `kubectl exec`) is not available.
Thanks for building this! Love this version I think this would work great for making and fixing bugs. I think automated tests and chores as a category would actually be great to add to this.
For our open source project (https://github.com/papercups-io/papercups). We participated in hacktoberfest recently and one problem we ran into is people submitting low quality PRs. Which ends up taking up way more time to review than to merge.
I would love to be able to filter by users who have merged multiple issues or some sort of quality bar for our bounties. Obviously since you are just starting out your users won't have too many issues merged. You might be able to work around this by finding the number of Github issues an author have merged previously to any projects that is greater than x number of stars. This way you might be able to bootstrap some credibility of the authors. Then a open source maintainer can gate on only allowing some reputable contributors.
One inspiration I would recommend is taking a look at how 99designs has different tiers of designers you can have a bounty for your design. If you could build 99design for open project that would be amazing. Best of Luck!
This is reminiscing of the reputation on some of the bug bounty platforms. Like all good things it’s not straight forward though, just because a PR is rejected or even if the project thinks it’s low quality is not 100% directly related to it actually being low quality.
Never the less something like this is likely needed. With reference to the digital ocean free shirt pull request saga :)
Thanks for the feedback! Right now we have a PR breakdown on the user overview (Completed/Rejected). So that could be a good judge of quality. And I could see pulling in stats from Github (i.e. 'this user has contributed to 25 projects').
But I wouldn't necessarily want to block new developers from being able to contribute to a project. I think it would be best to have anyone able to contribute, but perhaps a flag on the project owner side to see that user's rating.
What happens if someone "imports an issue" for a project you've never dealt with before, and contributes funds to the "cause", and then someone commits a fix for it, but you have no prior engagement with that person?
i.e. How does this not become the Brave issue all over again: taking funds from people without a confirmed way to pass those funds on to the person they think it's going to.
The person who submitted the story, and ostensibly setup the site, said this in the comment I replied to:
> Anyone can import an issue to the site and contribute towards the bounty. Whoever submits a pull request closing out the issue earns the bounty.
Imagine this scenario:
John files an issue on Project Foo, submits that issue to Rysolv, and pays some money to "contribute" to getting it fixed.
Joan sees the issue filed on Project Foo's issue tracker, and submits a patch.
According to the statement from the parent comment I replied to, that money would be paid to Joan. But Joan has no existing relationship with Rysolv, and thus they have no way to pay her for the fix.
So far it hasn't been an issue. Even when people aren't on the platform, they usually respond to the "Hey I want to send you $50 email".
But this could definitely be a problem if the site grows and I don't have enough time to track down people.
Another suggestion I've had for abandoned funds is to redistribute across the repo. i.e. A $100 issue for OBS was closed/abandoned/etc, so the $100 is split and the remaining OBS issues get $100/n added to the bounty.
That's an important detail, but in practice probably not too bad. Might need some sort of third party separate from Rysolv to hold funds until they either contact Joan or hit some sort of expiry date.
The bigger question is how do you handle disputes. Who decides that the issue is actually resolved? What if the fix involves multiple people?
But "you took my money where did it go" is without doubt a bigger problem - Brave had essentially the same issue, and (rightfully) received a lot of shit for it.
If you don't have a confirmed contact/way to transfer funds, claiming to collect on their behalf is bordering on fraud IMO.
it should remain in john's account at rysolv so he can contribute it towards a different issue.
rysolv is holding money to solve a particular issue, until that money is claimed. if the issue is never solved, the money won't be claimed either. the problem what happens with the money is the same as if the issue is solved without anyone claiming it.
so presumably there needs to be a process for unclaimed money regardless.
brave was collecting money to give to the project as a whole for work already done. they didn't expect that it would be rejected or remain unclaimed.
It's a great idea, the site looks nice and works as expected! However, I see that some people have "credit", and I fail to understand how they work. They're not mentioned in the "Start Here" [0] page.
Adding to this [1] bug report, when I change pages using the numbered buttons at the bottom of the issues listing and then press the Back button of my browser it takes me back to HN. Navigating back should instead take me back to the previous-numbered page of the issues list.
For usability, please also consider not requiring people to scroll to the bottom of the listing to change pages.
I had nearly the same idea a while ago, made some notes and collected links to others, never built anything. I'm glad to see another, this looks awesome and congratulations.
Limited to Github right now. But planning Gitlab support soon. Just wanted to really finish out the integration logic with the Github API before porting it over to Gitlab.
I do some consulting where I'm paid to fix specific bugs / add specific features to various open source projects, often in Python data science world. Usually it goes something like:
1. Figure out what the project's contribution guidelines are.
2. Check out code, figure out how to build it and run tests.
3. If it's a complex task, might want to build some credibility with maintainers first, so might contribute tiny fix first.
4. If it's a complex task, try to engage maintainers to see if they'll accept it, and to get hints on how to approach it. They may be hard to reach, so this might take a few days or a couple of weeks, though I'm not working during that time, it's just delay.
5. Do the actual work.
6. Go through whatever code review process. Sometimes I might need to gently ask for reviews if it sits for too long.
$80 total for all the above is laughable. And to be fair I ask for a good amount of money because I am good at what I do, and there are people who live in much cheaper places than Boston area and could charge less.
For $80, you'd have to both have an extremely low cost of living and already be an expert on the project for this to be in any way worthwhile.
Consider that steps 1-3 may often be skipped, since it will usually be the existing maintainers who are resolving issues.
And given that they will likely be fixing the issues at some point anyway, it could just be another bit of supplemental income. As well as give them an idea of what issues people are struggling with the most.
I think it's unlikely that rysolv bounties will ever pay an engineers salary. But I see so many projects with thousands of download get like $4 / month on Open Collective. And I figure I could at least beat that.
"Dude, you should checkout Rysolv, its a cool service!".
"What's it called again, doesn't show up on Google."
"It's spelled Rysolv".
"WHAT!??"
"R Y S O L V".
--
Sorry, but I have always found names of this sorts bad for all kinds of ways. IMO the way you say it and the way you spell it should be relatively obvious. Ofcourse there are exceptions like Lift..ggrr..Lyft. To be fair, its quite difficult to satisfy all aspects of a company name. You can't Kodak like the old days!
Even if you think it's important, it's not equally important for all names. In this case I dare say that this project is going to be typed about more, rather than talked about.
Ran into the same issue when naming our startup ClaimR, searching for the name on Google would indeed give a suggestion "Did you mean 'claim'" and completely tank our SEO.
Although ~9 months after launching the site it stopped giving this hint. Not completely sure what changed it, although in the meantime we added the domain to the Google Search Console and incorporated.
> bountysource
Very similar proposition to bountysource. But ideally with better execution. They've got a great stats page. But you can see a pretty sharp decline in their contributions since ~2016. They've changed management a few times, and I wonder if that's contributed to the the decline.
> addressing a need gap
Immediately, no. But rysolv is ~2 months old right now. And I'm still building every day.
A few things I'd like to add:
- First time only: accepted bounties only if it's the users first PR
- Projects: Kickstarter approach for new projects. Pitch an idea and have people crowdfund it.
- Gitlab support
> mention Rysolv
Sure! Go ahead. And feel free to give me a ping if you want any additional info on the site.
(tyler@rysolv.com)
I'm afraid that those bounty programs may create an expectation that all contributions need to be paid. If someone makes unpaid high-quality contributions for a long time and then sees someone else being paid for a minor fix, it will leave a sour taste.
On one of my own projects someone randomly added a bounty to an issue that was mostly an upstream issue. Of course the original poster had good intentions, but didn't fully understand this.
I can't imagine it working too well anyway. Valuable work isn't done by drive by contributions very often. It usually takes someone a very long time to become familiar with the project. The first few contributions are likely wasting the maintainers time but over time they become valuable contributors.
That's the hope is to bring some more people into OS contributions who haven't tried it out before.
I have funded a couple issues at like $25 that were marked "Good First Issue". And I've had people reach out saying they were excited to have done their first pull request.
I'm curious how/if this can handle sponsor theft. The mechanism: someone posts an issue and puts a bounty on it. A working fix is imported by a developer. The sponsor then grabs the diff and applies it to their own private fork of the code.
Most open source bugs never get fixed (or get fixed slowly), and this project would select further for issues that are not already being addressed for whatever reason. So it's not unreasonable to think that many PRs would not be merged inside 6 months, even if they are valid fixes. (Raise your hand if you've ever contributed a PR to an OSS project and had it linger for > 6 months.)
That risk, plus the low bounties identified by other posters here, seem very tough to overcome.
Well luckily git has timestamps. And we have a manual approval step before bounties are paid out.
So the original developer would have to raise a dispute somewhere (issue, email, etc.) and I could go through the commit history to see who wrote the code originally.
Although I think that would be an extreme edge case. Especially with a low bounty. I don't think it's worth the effort of ripping off another contributor.
And if the bounty was like $10,000. I would pay a lot more attention to the solution before sending out the money.
First of all, kudos for trying to find new ways to fund open source. Those are needed.
This approach might work well for issues which require a lot of thought, but produce a simple fix and can be easily merged
This might go horribly wrong if outside contributors try to implement a major feature to a project which they don't have a good mental model for, produce a large patch that may get rejected by maintainers, or end up being rewritten-by-code-review, which would cost such maintainers more time than if they implemented the feature in the first place.
This is totally an unintended consequence of the Github Oauth 2.0 setup. And I'm working on changing the authentication setup to avoid this. Since we really only need to read the username and email address.
There's an open issue for it, and I'll try to get to it in the next week.
I'm not a fan of OSS development as it's unfair to creators (which are rarely remunerated for their time, minus a few exceptional individuals who can survive of donations) but I really appreciate the idea behind it: this is providing a way for a developer to earn money without subscribing to the usual employee bullcrap dance or the usual contractor sales bullcrap.
The closest thing I can think of are security bug bounty but companies are not really reliable with the way they reward issues, not to mention getting closed as duplicate or just waiting forever because they have half engineer dealing with security.
That said, I think we need a mechanism to assign an issue to a developer on rysolv, so that if someone outside of the maintainers fixes the issue in a way that is considered acceptable by the provider of funds, it can be closed and the developer rewarded.
I have had PRs open on OSS projects for 5 years, just one merge away from delivering value, just because tons of OSS projects are not maintained.
Other times maintainers are just not willing to share responsibility with others (and I doubt it will be much better with money), forcing you to fork their project or wait forever.
This would also solve the issue of waiting forever for a fix without being able to unpledge the money: there's someone assigned to the issue you can ping about status or terminate.
Yup. Rysolv holds the funds and then distributes when the issue is resolved.
Right now, if an issue isn't fixed after 6 months, the bounty can be refunded to the user. But I'm still exploring better ways for this to work out.
Since other sites have run into issues where they refund money to a user's account, and then it sits in limbo forever because the user forgot about it.
I've contemplated instead of refunding the bounty, having the funds move into a repo account that get's distributed among other issues for that repo.
i.e. and issue for OBS with $100 was closed and not solved. So all the other OBS bounties will have an extra $100 / n added to them
> If an issue remains open for more than 6 months, a user may request their contributions be refunded to their account.
I think there should be a lot more to this. Like having a choice how long my bounty can stay up (in months maybe, minimum 6). Receive an email after that time to remind me. Show in each issue how much of the bounty is up for how much longer for sure.
Add an RSS feed and weekly newsletter where I can subscribe to see new additions for a specific language.
It is not clear who is holding the bounties while waiting for issues to be resolved? It is not clear what fees are involved? How is this platform financed?
I also suggest you add the faq link to the header ;)
I've been struggling with this concept for a while and I'm not sure would be best. I want to allow people to raise and issue, and then crowdfund a bounty for it. And I think that adding a minimum dollar amount would limit people posting new issues.
But I also don't want the site filled up with $0.00 issues.
If anything, I may do a small minimum. Like $5, so that way every issue has some value to it.
And for #2: I'd like to add in some collaboration features so people could split the bounty if they both worked on the solution.
For anyone game multiplayer savvy there's a mod for Skyrim called Skyrim Together, the old version is closed source but a new one on github is open and has some well funded issues from their patreon.
The creator essentially stepped down from a development position but their patreon still makes money, so may be some opportunities there.
Eventually a system like this will succeed at getting some kind of scale. When that does happen, the smart devs will write tools that search for common issues in open source repositories, that also have bounties. You apply 1 code fix to 100 repositories, and that $80 bounty (x100) becomes an $8000 bounty.
The result of that is that the easy stuff with a known fix will always be prioritized, and the hard stuff that require real engineering time will never be fixed.
Feedback: Please reduce the range of your price filter. All the bounties are under the $500 range. This makes the range slider pointless beyond the first 1%. On a mobile device it's near impossible to select a meaningful range that returns results.
Solution: Make the upper bound max value a dynamic variable of the current highest bounty with some padding and rounding up to a nice number.
> I'm curious to see if this works
Same here! And I can see an inverse effect as well. People willing to work for free on a project, who aren't as willing to work for $50.
But I think often times the bounties will go to the people who are already maintaining the project. Who likely would have resolved the issue anyways.
And rather than a ton of people commenting "same" on an open issue. They could chip in a couple dollars and support the developers.
Totally agreed. And this is a really weird default behavior in the Github Oauth 2.0. There's an issue raised for it and I'll try to get a fix in this week.
https://github.com/rysolv/rysolv/issues/15
Gitcoin has been doing this for a while now, crypto has had success in this model.
There hasn't been a lot of success with fiat platforms like bountysource.
And I'm interested to see why. Perhaps crypto people are just more willing to part with money, since bits are less tangible than tangible as cash?
I didn't discover bountysource until after starting on rysolv. But from their stats page you can really see the rise and fall of contributions on their platform.
They've been acquired a couple times. And I wonder if issues came from changing ownership / poor marketing. Or if OS funding is just inherently unprofitable.
In order to have a net positive effect, such a program would need to be able to generate an income, not necessarily a engineer market-level one (because you could have students working on this) but at least something above the minimum wage[1], not just tips.
[1]: and at this level, you'd still not attract more affluent kids who don't need a job.