This was one of the lessons from Google Answers, an early version of Stack, Quora, etc, which paid people.
There's a good basis in psychology for this. If you look at studies about intrinsic and extrinsic motivation, you find payments (and external rewards generally) can be counter-productive and make people less motivated than if they're doing the same task for free.
The problem is when you have commercial and volunteers together at the same event, and some volunteers may think:
"Hey, screw this, why am I volunteering my time, when the guy next to me is getting paid a decent hourly wage to do exactly the same thing?"
But I am willing to pay for someone fix my problem, not answer it. I mean, get access to my code and solve the issue himself. Like a micro-freelance job.
Thar way there is still incentive to answer doubts for free, in order to get more points/karma and attract more clients/charge more money.
If you provide payments integrated, typically the financial incentives become market dictated, and once money is involved the intrinsic rewards become greatly decreased.
That way developers could pick the bugs where people are willing to put their money where their mouth is.
It seems that this might encourage developers to leave bugs outstanding or introduce new ones as a way to generate revenue though, unless a similar scheme is used to fund 'new features' and not just bugs.
Emphasizing this. This is why the police sometimes oppose safe streets and raised speed limits: it decreases their revenue from speeding tickets. It's a fairly well-known problem, though I've never heard of a fix.
For example, here's an issue with 11 backers: https://www.bountysource.com/#issues/27-split-pane-feature
...and here's a bounty over $1100 with 5 backers:
I think this is probably why gittip works so well. Set it and forget it.
Being a developer myself, when I create a piece of code to do a specific thing and release it to the public it's not for monetary gain, but to help others than need it by using my source. However, if they wanted additional features added to it, you could have a pot, and once the feature is achieved the pot would be deposited to the developer.
> I think maybe each bug could have a pot where people could to put an amount, and if a developer fixed that bug and enough people agreed he would get that pot.
Except leave out this part:
> That way developers could pick the bugs where people are willing to put their money where their mouth is.
Instead, completely hide showing how much money was donated to a bug. From everyone. When a developer fixes a bug, they may get a nice surprise for their contributions, that may further encourage them to work on issues.
A little like GitTip, but you're tipping whoever solves an issue, ahead of time. And because it's invisible, it doesn't make your hobby feel like a job because you don't know which issues are worth the most. (although it may be possible to guess by issue popularity)
Which I really don't think is okay. However, I fully support helping developers spend their time doing what they love to do; but wouldn't spend more than $5 on any one thing. If you think about it, you could have a really successful middleware or something and get $5 from 1,000 people at once, or $5,000 for doing something that you were intending on doing anyways... Seems kinda underhanded to me as an open source developer.
What do you think about it? Are you using it?
I had wanted to build a funding platform for open source as well but I don't think a bounty board is the right way to do it anymore.
The other people I have seen taking a stab at the idea are:
Repo seems stale now so they might have given up.
What I think what would work better is if you had the option in github to vote up a bug (or expose the number of people following/watching it) so that the owner of a repository could use that number in deciding how important a bug is to his/her userbase.
Another website managing this would be nice. It could tie into Github's API and offer this service.
We also have a plugin that committers can install that automatically updates issues with bounty details when they exist (that we don't think clutters the Github UI). Example here: https://github.com/jshint/jshint/issues/28.
A "Would you be willing to pay ..." question with yes/no/maybe options would seem more accurate to me.