> Don’t “claim” issues or ask whether someone is already working on an issue. Instead, focus on creating a pull request which solves the issue. Once you create a pull request we can assign your account to the issue to ensure others don’t start working on it in parallel.
Having maintained popular OSS software in the past, this sounds problematic. I know “claiming” doesn’t work, people will regularly “claim” and issue then not be heard from ever again. But PR-to-claim sounds iffy, especially when money is involved. Failure modes I envision include people putting up low effort PR’s to lock the issue, then either wasting a bunch of maintainer time on reviews or getting into IP debates with people who later on create a proper PR that maybe includes a bit of the same routines.
Perhaps if the PR author would stake cash that the maintainer/reviewer would receive upon review?
The third party pr authors are asking for the other party to do work just as much as the maintainers are.
Thanks for raising this issue, you're right! There's no mechanism for making concurrent work impossible. We haven't had this problem of concurrent issues being worked on from start to finish in the past, maybe that will change with the bounty program?
We haven't seen adversarial behavior yet but if it starts to be a problem we can address it, I agree that the language of "opening a PR" isn't super great. Maybe that section needs to be more general i.e. "we'll assign you the issue once you've made substantial progress towards the tasks" leaving that to be defined by maintainers.
The possibility of "staking" money by the contributor is a non-starter. We aren't in the business of taking money from people who have good intentions and operationally I don't see a way forward there.
This whole program is an experiment so we're open to being wrong about things at first. We'll be iterating based on feedback and providing a retrospective in a future newsletter.
Offtopic: is there a list of bounty
programs which, like this one, award feature implementations instead of bug/vulns? Google just gives me bug bounty company lists.
That seems to be fairly standard. When some government institution started a term-limited security-related program for a project to which I contribute, the consulting company that ran the program took out a fixed fee out of the pool each month, too. I suspect this is done so that the project is encouraged to promote the program while it lasts.
Actually, I found the terminology much more problematic than the way the program administrator was compensated: while “bounty” can mean (among other things) “subsidy”, that is not the meaning that is predominant in popular culture today. Maybe some use it as a convenient industry shorthand, but others are definitely aware of the fraught history (particularly when it comes to persecution of Native Americans), and allude to it in conversations. And that a 21st century government sees this as a model to be emulated for maintaining public safety is quite disturbing.
Thanks for posting this! If anyone has questions you can ask here and I'll answer or our community Discord listed in the article is a good place to start.
As a maintainer of a few open-source projects, some funded & some unfunded — this is a v interesting development. I'm excited to see how this goes and I really hope it's successful.
Some concerns that I've considered before around this model (no need to address them all):
- How has adding this incentive changed the community?
- Do you get worse quality contributions because people are doing it for the money?
- Are non-funded items neglected?
- Do people argue over whether an issue is fully closed?
- Is it more of a challenge to craft issues with a tight spec?
These are all great questions! Our team is collecting feedback and our own experience and hoping to publish a retrospective some time down the line about how things are going. Stay tuned!
I find the language "Paid: $___" confusing because it is past tense and reads like the task has been completed. I suggest changing it to "Will Pay" or "Bounty"
This space is in rough shape for python. Python ships with urllib, which is fairly neglected. People tend to use requests, which is better, but still doesn't support normal keep-alives, so it's a new connection per request.
Also, urllib3 has a dependency on the shipped urllib, and requests depends on urllib3.
Edit: I was correct about urllib not doing keep-alive, but incorrect about urllib3 and requests...those support it.
Where are you seeing this information? urllib, urllib3, and requests all support connection pooling, keep-alives, and re-use and have for a very long time.
I had remembered incorrectly. Urllib (the only one of the three that ships with python) is hobbled this way, it sends Connection: Close with every request. Urllib3 and requests don't have that issue.
It would be great if GitHub integrated the concept of bounties into its system, so other projects could have them too without much administrative trouble.
You also can just see the difference between your potential salary and what you get as your personal contribution to open source. And lots of people are happy to receive something, even if the value of the gift is not significant.
Some experienced, well trained, 1st world developer is not satisfied with $300 for 5 minutes of his oh-so-superior work on FOSS software? Please excuse me, while I try to parse your statement in some nice way...
I think their point is that there are a lot of people for whom $300 is a great payment - essentially, defending the maintainers for offering what the parent seems to be implying is too little.
Personally, I'm a senior dev making more than triple what I did when I started my career, and if it were five minutes of work (or even ten, or an hour) I'd be extremely happy with $300.
I included people that are doing FOSS work in there. I also have found very few software engineering tasks that are 5 minutes of work. I am not looking down on 3rd world developers, it is just a simple fact that in most of the western world, doing a few days of work for $300 is not going to equate with getting a job as a software developer. Assuming it takes a week to tackle one of these bounties, 40 hours of work, That is a bit above minimum wage in the US. Even 20 hours is only $15 an hour. I don't think this will inspire professional developers in expensive nations to try and make a serious effort, for just the money for just a simple fact that it doesn't pay enough. But there are many classes of developers that this is good money. I am defending this bounty.
We wish we could pay FAANG salaries for working on open source! That would be a great world to live in. Currently our funding comes from corporate sponsors and individual donators so is limited in what we're able to offer for now.
Our current calculations for issues is roughly ~$50 per hour of anticipated work from an individual with some relevant skills which we're hoping is enough money to entice people to contribute.
I don’t believe this is meant to replace a full time job, just to incentivize open source maintainers who might otherwise place their effort elsewhere.
Having maintained popular OSS software in the past, this sounds problematic. I know “claiming” doesn’t work, people will regularly “claim” and issue then not be heard from ever again. But PR-to-claim sounds iffy, especially when money is involved. Failure modes I envision include people putting up low effort PR’s to lock the issue, then either wasting a bunch of maintainer time on reviews or getting into IP debates with people who later on create a proper PR that maybe includes a bit of the same routines.
Perhaps if the PR author would stake cash that the maintainer/reviewer would receive upon review?
The third party pr authors are asking for the other party to do work just as much as the maintainers are.