I was just about to respond to
this thread about bounties for ultimate blockchain compression, but this was actually something I had been meaning to post in this thread for a while. So I'm posting it here, because it's a more general thought about bounties and donations, etc, and it just so happens that the UBP/UBC idea is a perfect example of why I propose this:
tl;dr -- I'd like to see us move away from "traditional bounties." Fund the developer to do the work, don't pay for a completed product. "Completion" is too fuzzy and controversial. Build and leverage trust, and give developers some leeway to make decision on their own without worrying about the financial security of their endeavor.
My general thought on bounties: "completion criteria" is frequently too complicated and too controversial. The bounty-driven idea might be reshaped, reprioritized and improved over the course of development, at which point the original criteria are no longer valid. The question of whether the idea was actually implemented becomes controversial. People will complain the money shouldn't be released until it's 100% done even when 95% of it is completed, and even when it's not clear exactly what should qualify as 100%. If certain aspects of the design happen to be infeasible, but the spirit of it was still completed, does the developer get 80% of the money? 0%? 100%?
Some bounties are fairly clear-cut, because the task is relatively simple and well-defined. A task as epic and complicated as
Ultimate Blockchain Compression is going to fall into this gray area. Parts of the idea may be found to be infeasible, major aspects of its implementation may be swapped out with something better/similar/possible in order to try to achieve results. Additionally, for some bounties, it may be found to be completely infeasible, period. Should the developer who spent 3 months demonstrating that it was infeasible be left with 0% of the bounty? Strictly speaking, he still made a valuable contribution to the community (probably because he kept a thread going and collaborated with lots of smart people to try to figure out how to work around problems, and there was no reasonable path forward). If the bounty is supposed to be released only upon completion, even users who otherwise would be satisfied with his work may have to give into others who argue that he didn't do the job, he shouldn't get the money.
So what's the solution to all this?
Not bounties (in the traditional sense). Just like justusranvier posted on that thread, the solution is trust -- you are donating money to someone you trust to put in a reasonable amount of effort to solve your problem in reasonable time. Someone whose judgment you trust to do the right thing, and make good decisions, which may involve changing directions of the original task for various reasons. It would be best if a task was not held hostage to the complaints of users who don't understand the technical complexities of what is being implemented.
This works in the long-run: developers solicit "funding" to accomplish some task that would otherwise be covered by a bounty. There may be a threshold, or it may be part of a series of funding whereby the developer agrees to work primarily on the task that receives the most funding. Then the developer receives the money and does his best to complete that task. This has the added benefit of providing financial security to the developer.
If that developer does nothing -- well then people will be pissed at him and he won't be
trusted anymore. He won't receive any further bounties/funding. If he's untrusted at the beginning, he wouldn't have received the money at the beginning. Someone who has very little reputation may develop reputation by presenting evidence that he has already developed some significant portion of a task that would otherwise receive funding. Therefore, he develops reputation by "donating" his own time to a project with no guarantee of receiving money, and people are willing to give some money to see it completed. After that, donors can judge how much bang they got for their buck (bang for their bit?), and offer their money to someone else if they were unhappy.
Discussion on the forums will aid in smoothing out the opinion -- those with more technical background can help inform others how challenging certain things and whether the developer is BS'ing about why things don't work. Not everyone will be happy, but I think satisfactory equilibria can be reached.
This is not too much different than "the real world", I just got there by explaining why "traditional bounties" are not ideal for some of the things we want the most. In the business world, companies get contracts from other companies (sponsors) to do some kind of work. Usually something small, at first, until there is some trust built up. The sponsor periodically receives status updates and decides whether to continue funding after the contract period is over, and/or whether to hire that company for other tasking as well. If the company doesn't meet their needs, they go contract with someone else.
So in practice, how does this work? Most importantly, the donors/contributors must be willing to give money up front. It doesn't have to be one year's salary all at once: perhaps the developer claims he needs $2k/month to do it and it will take 9 months. So $6k will be raised to support him for three months. After that, people will have the opportunity to give him more money if they like what he's doing. If they don't give it to him, he's likely to stop developing it and work on something else. This creates a feedback loop where people who originally wanted to see it done, will want to contribute more to see development continue (it would be a waste for all that work already done to be dropped). Or maybe after three months it will be deemed infeasible (either by the developer himself, or by the donors), and the money will stop.
At the moment there must be trusted third parties to collect and hold the money, but only to the point that funding goals are reached. The criteria for releasing the money is simple, and creating new bounties/campaigns is also simple. In the future, assurance contracts can be used, at least for Kickstarter-type (all-or-nothing) funding.
