I am a developer working on an open source project and I would accept less money if I knew the bug was something I wanted to fix or a feature I wanted to implement. But to tackle something I truly don't want to do for personal joy or itch, I would have to have something on the order of $60-100 dollars per hour of my time to do it. And, there would be bugs and features all along this continuum. Also, I want higher adoption rights so the more "money" there is the more I want to do it for that reason. Also, if there are only a few bounties, I'd probably be willing to go for those more.
However, when money becomes a part of the motivation, if its not guaranteed, then I will start to look at expected probable outcomes (value of bug * chance I'll get the money = EPO). There has to be a reasonable assumption that you will get the money as a developer. Ways to increase the chance I'll get the money would be to take user's credit cards, but then you run into the problem of authing the card months after the bug has been fixed. You could implement a reputation system such that money that has been paid out in the past makes the current offer look stronger. You could also hold the money in escrow. Every solution on this front requires overhead, so how much would be taken off the top? Transparency in the accounting and structure would be highly important to maintain a perception of integrity in the bribing system.
Developers also can cheat the system by not really fixing the bug or adding the feature. They could implement the feature in ways that make more sense to them but cause the user to feel that they aren't getting value for money. A bug could be fixed in one way then pop up again causing the developer to look like he cheated a user, when in reality its the same buggy behavior for a different reason.
People are often terrible about getting information to the developer so that the bug fix is "easier". In that way, lines of communication would have to be kept open so the developer could ask for more information. Also, the developer could indicate that they find it low priority and suggest that they would consider it higher priority for a little more? Features are often poorly described by users so the developer could also communicate on that account as well.
What about bounty pooling? Like, two people put in a feature that is the similar but not quite the same. The developer and the users together may want to arrive at a compromise that benefits everyone.
People aren't paid in just money, social capital via social networks is also significant. Allowing the user to broadcast on plus and fb that he financed an open source project (and which one) also gets advertising for the project which benefits the developer, and kudos and respect for the user. Integration with social networks could be powerful. I, probably like many developers, don't like to use social networks personally, but users using them is great and I see the benefit.
I think the theory of the idea is sound, but it would require a lot of careful consideration, a lot of implementation, and some sound business consideration.
Also, in some way, this might undercut the amount of donating people already do. Now, to get the money I have to do more work, instead of generally getting rewarded for work I've already done. I can see that maybe it would lead to more money overall, but I wonder if it would?