snow@smoke.suba.com said:

Well, I was thinking, what if a "Crypto Software Bounty Server" were set up, so that someone could propose a tool that they would like to see, along with an initial bounty. Others could contribute toward that bounty (anonymously if they wish) until either the tool was delivered.

The original issuer sets standards for the software (i.e. "easy to use interface to mixmaster remailers for Macintosh", then must define easy to use; Software considered delivered when in [alpha beta late-beta &etc.]). The first to present software meeting these qualifications gets the bounty, with the caviate that the software must be either gnu-copylefted, or some similar "free use" copyright, after all, "The Net" paid for it...

Hmmm. This is a one shot game (is that the term?) whereas software generally has implications that escape a single sale scenario. For example, the more difficult the software, the more risk there is that someone else will beat you, thus lowering the real risk-adjusted payoff dramatically. For this reason, more complex stuff would need some sort of contract+reputation scenario that allows a repeating game to work. A contractual alternative could work like this. I (the initial desirer) write a contract specifying my requirements. I publish this as a market tender, where other desirers can contribute funds, and this becomes a cumulative sum that grows. Programmers can offer to supply by naming a price. The market clears when the pot of desire equals or exceeds the lowest offer to supply. In a simplistic scenario, the contract is now sealed and the work is done and paid for. In order to overcome project failure, I could write my contract as a multi-supplier seed project (often done by governments). That is, the pot gets shared around, say, the three best alternatives. Once supplied, all are free to pick from the alternatives. In order to overcome the low silly bid, somehow reputation would have to be built into the market. That is, your efforts in the past as programmer will cause your solution to be better valued than mine. So perhaps we should turn this around. Programmers would write contracts to supply the given requirements at clearance+T, also specifying the clearance price. Your price is 2000 for the widget, mine is 1000. (That makes three contracts, a widget spec, my work plan and your work plan.) The market (the desirers) would then push funds back and forth between the two until it became clear that one or the other cleared. As more pressure increases, more funds pour in. Then, deliverables could be phased, with monies similarly phased, so that the market has a chance to monitor. Now, if it is not delivered, reputation suffers, and you have to lower your price for the next job (or hide in shame). There's a lot of aspects of newbies and switching funds that I havn't really thought through here. However, I like this viewpoint because it eliminates the need for judges. History shows that a good market microstructure will beat an authority approach in the long run. Also note that if you drop the free software assumption, and make it, say, moneyware, then the market becomes much more workable - the asset being traded is a share of future revenues. This has more ramifications than might be obvious: Propose a market to write a GAK killer for e$10,000. If it clears and is built, is the Dept. of Justice forced to buy the rights out?

Has anything like this been proposed before?

I don't know if this has been proposed before, but it is a logical conclusion of the CP world. If the Internet transaction costs make single-person economic entities the most efficient unit in the machine, and e$ in all its forms provides the oil, then we need some way to connect up the parts for grand projects where there are hard cash incentives. There has to be some mechanism to distribute that cash in the most efficient manner to produce the result. BTW, this is a here and now issue, not a hypothetical future. We have already found that there is too much work on our plate, and limited efficiency in farming it out. Others may have found the same. -- iang iang@systemics.com