Open Source versus Capitalism

Martin notes that:

One fairly silly argument sometimes advanced against Linux is that by reducing towards zero the cost of getting a good operating system, it is somehow communist or anti-capitalist.

He’s right: people do make that argument, and it’s silly. It’s especially silly because people already do it for a profit, and even sillier when you realise that there isn’t even anything anti-capitalist about charity. And it’s even sillier when you note that Linux and open source have demonstrated that they have a viable business model: there’s plenty of open source being produced given existing incentives; even if those incentives aren’t insanely great.

What’s even sillier though, is that there is a real problem here. The business model for developing free software isn’t a very good one. It’s either financed by charity (whether it be the author’s own, or users, or some other group), or it’s parasitic symbiotic with some other business model, like hardware sales or support or just as in-house development. To be fair, that really is great.

But. The problem with this is that it’s just not reliable. It’s not reliable for the employees, who are at serious risk of being restructured as not being part of the “core business”, and it’s not reliable for users of the software that are willing to part with their cash to keep the development going, but aren’t interested in the primary product these companies are selling.

The real issue here is providing a stand-alone business model for free software development. To backfill a little, Joel’s essay (if you didn’t already click the link above) talks about complementary products; where if one product is available, or cheaper, the other product is likely to sell more. He gives the example of dinners and babysitters:

And babysitters are a complement of dinner at fine restaurants. In a small town, when the local five star restaurant has a two-for-one Valentine’s day special, the local babysitters double their rates. (Actually, the nine-year-olds get roped into early service.)

The thought here is that if babysitters aren’t available, married couples aren’t going to have as many nice romantic dinners. Whereas if they’re cheap, easy and reliable, they’re going to go out for dinner more often. It’s easy to imagine a restaurant putting two and two together and deciding to setup a creche to encourage more couples to come along. Now imagine that that’s the only way to get a babysitter. That’s pretty much the situation we have with open source development. It’s bearable, but it’s not ideal.

By contrast if we could setup a viable stand-alone business model for free software development then we could do things like setup a Microsoft-like campus filled with a hundred well paid free software developers, working full time on doing old stuff better, and making new stuff possible. Given we can compete with Microsoft without those resources, having them should be a significant improvement, and considering the sorts of energy you can get at developers conferences that’s not even completely theoretical.

A question is why consumers would want to give money to developers. Obviously not for the product itself, or for support or other add-ons; since the former’s ruled out by open source licenses and competition, and the latter’s ruled out by assumption. The only thing that seems reasonable to “buy” is what developers spend their time working on. And that’s hard to buy because it’s unpredictable — both because developers don’t tend to have consistent output, and it’s hard to work out how much time and effort is needed to get a useful product out. That is it’s hard to know what you’re actually getting, and it’s hard to know what you should expect to get for your money. But hard’s not the same as impossible.

I’ve been interested in gambling lately, or more descriptively using markets to predict things, such as the next Pope or Governor of California. I’ve been thinking that one way of handling such things is with ecash. Say you setup two currencies, A and B, and allow people to buy 1A and 1B for $1, and allow them to freely trade them. You keep the dollars you collect until the end, at which point if Arnold wins, you buy back the A currencies for $1 each, and let the B currency become worthless. If Bustamante wins, you buy back the B currencies for $1 each, and let the A currency become worthless. If you buy an A and a B, you know it’s worth paying a full dollar, because you’ll get a full dollar back at the end. In a well informed market with the opportunity to average out risks over a long period, the cost of each currency should end up matching the probability that the appropriate candidate will win. It seems nice and simple, and doesn’t requiring any gambling on the house’s behalf — the market works the odds out naturally, and the house just has to charge for its overhead in managing the moneys, which can either come via transaction fees, or by charging slightly more for the initial A+B bets than it pays for the eventual A/B payouts. Simple, honest and effective, as far as I can see.

Putting this together with the above thoughts on software development seems interesting too. One way of doing it would be to let people bet on a particular feature being implemented by a particular date. Fun and exciting, for sure. Let’s suppose you’re a user, who’d really like that feature by that date — enough that you’d part with $1000 for it. Okay, so you buy 1000 W + 1000 L tickets for $1000. You keep the 1000 L tickets — that way if your feature doesn’t get implemented, you’re no worse off. You can either give the 1000 W tickets to someone you know who can work on it, or can sell it on the market — both have their drawbacks, but oh well. At least you win either way: you get your feature or your money back. Interestingly, there’s even some incentive to invest: if your feature doesn’t get implemented, you’ll make a profit on your initial $1 of whatever you can sell your W ticket for. Not sure if that could compete with other investment opportunities, but hey, anything that improves the accuracy of release schedules has got to be a win, right?

For developers, there are two incentives. Obviously if you can afford to implement the feature for $49,000 and can afford say $1,000 upfront to buy 50k W tickets at 2% odds, you’re fine. Spend the money, implement the feature, win. There’s even an incentive to half-implement a feature: if the odds are initially at 5%, and implementing a feature will get those odds up to 40%, you can make a 7x profit on your initial investment, by buying low and selling high after you announce. It doesn’t even really discourage cooperation: if someone else beats you to the punch, you still get the winnings. Unfortunately you have to have some money up front to play, but that’s kind-of true of any business.

There are more significant problems though. One is working out whether a feature has actually been implemented or not — you probably don’t want to let whoever decides that have too much money locked up in either W or L shares; imagine if everyone thought the feature was implemented, so were selling L shares for 1c, and imagine buying 1000 such shares for $10, declaring the feature wasn’t implemented, and getting $1000 back. Yick. At least we quite specifically don’t have to worry about insider trader (we encourage it after all!), so it’s not all bad news.

The ideas here are very similar to those developed in Chris Rasch’s Wall Street Performer Protocol. The main functional difference is in the setting of a time-limit, and the possibility of getting your money back.

UPDATE 2003/11/04:

Martin followed up drawing the analogy to Jim Bell’s Assassination Politics. Why should this sort of scheme work for open source and fail for assassinations? First, there’s nothing questionable about writing open source software: it’s legal and it’s moral. Assassinations presumably aren’t. As such, you presumably need fewer incentives to promote open source than you do for assassinations, and further, if assassination politics becomes successful due to this betting mechanism, you’re likely to see the betting mechanism become either banned outright, or tightly regulated (removing anonymity, eg).

Also worth a quick link is the Rational Street Performer Protocol, which rather than offering software outcomes, guarantees that other people will donate a certain amount for every cent you donate. The theory is that it should create a virtuous cycle of everyone donating more money.

Finally, a big hello to the Carnival of the Capitalists!

Oh! There’s more here.

Leave a Reply