inamerrata

Some more thoughts on this topic.

Ecash is actually something of a distraction in the description; there’s no particular need for people to be able to do anonymous transactions, or to transact without talking to a central market — so you can do this just as effectively with market accounts. In that case, it makes more sense to call the “bids” contracts: initially you buy, for a dollar, two contracts: one that offers you a dollar at a certain time if something doesn’t happen; the other offers you a dollar when something does happen, as long as it happens before that certain time. We’ll call these “lose” and “win” contracts, where “winning” is when the feature gets implemented.

So far, we’ve really only dealt with half the problems of financing free software: ensuring users get a fair deal for their money. That’s important, because the money has to come from somewhere, but that’s only useful if it goes somewhere too. If people put up their money, and don’t get anything back but they’re money, they’re sensibly going to stop wasting their time and go do something useful. And so far we’re requiring software developers to have a fair chunk of capital up front that they can invest in themselves. That’s nice and all, but most free software hackers aren’t all that cashed up (which is the problem we’re trying to solve here after all!) so it’s not terribly realistic.

One of the questions that most annoyed me about the Wall Street Performer Protocol and that still annoys me here is the issue of giving the winning contracts to people. If you charge for them, then you necessarily preclude all the poor starving hackers from being able to participate; but if you don’t charge for them, the poor starving hackers will have an incentive to just sell them immediately for the going rate (5c each), so they can eat. Both of which kind-of defeat the purpose of this. One way of dealing with this is probably to give out options. Say the current market value of a win contract is 5c. Say you have a friend who thinks he can implement 50% of the feature in a couple of weeks, and that that should raise the market value to 40c. Say you’re willing to invest $500 in this feature. Then what you can do is buy 500 win+lose contracts, and offer your friend an option to buy as many as he likes in two weeks’ time for 7c each. If all goes to plan, the feature gets half implemented, he exercises his options, by giving you $35, then sells them at the market rate (for $200). If things don’t go to plan, you still either get your $500 back, or your feature implemented; and your friend doesn’t have to invest any of his savings or run any financial risk.

The key point here is that if the current value is 5c, an option to buy at 7c is (almost) worthless; so you’re not actually giving anything of value away. But if you give that option to someone who can increase the value of the contracts significantly, and they do, then you win (because you got 7c for something that was only worth 5c) and they win (because they get to buy something for 7c and sell it for 40c). And you both win again, because you get your feature half implemented, and they get to spend some time doing some fun coding. This further means that you don’t have to worry as much about giving options to people you trust — since the option is worthless, they’re not going to be able to make any huge profits just by immediately reselling it. This at least gives you the possibility of dealing with people that you don’t know, without them having to put up some capital in the first place.

There’s no conclusion here, just some thoughts.