So, now the stomach pain is replaced with a cold and having been off the antidepressants for a week, the latter solely because the doctor's office can't get it together. At least I know it's not an ulcer or appendicitis, which is good news.

The XFree86 Render and Printing Summit mailing lists have both kicked into high gear. It's all I can do to read both of them and keep up with the rest of my life, and of course, I can't resist the temptation to throw in my two cents. Among other things, I updated my color management page pretty substantially.

I somehow expected more controversy from my advogato piece. In hindsight, the tone is a little whiny. Next time, I'll try to replace that with pure righteous anger :)

In any case, after writing the post I did some more thinking about theoretical economics, particularly the tragedy of the commons. I'll post my thinking here instead of in a front page article because relatively few people seem to care about this theorizing.

The ToC is an interesting parable of economics, often used to describe "externalities" such as the poisoning of the environment. Thus the first difference - free software is a benefit for all. The "tragedy" is that people (or, more poignantly, businesses) aren't motivated to contribute to it on purely economic terms, in analogy to the fact that people (or businesses) are motivated to plunder common resources. But, flip the signs around and the basic model works. The actions of one person get multiplied manyfold when you look at the total damage or benefits to everybody, but from the point of view of a selfish transaction, it doesn't count as much as the value the individual gets from plundering, or (flipping the signs) the cost of contributing.

Obviously, free software isn't a pure ToC scenario, or else nobody would be motivated to contribute, ever. This is empirically not the case. What's interesting, then, is the deviation from pure ToC and how free software thrives in spite of everything.

Classical economics deals with the ToC by adding governmental regulation, ie make it against the law to plunder the environment too much. Before you scoff, consider that leakage in government-funded academic computer science research is one of the big sources of funding for free software. But it's not the one I'm primarily interested in here.

The usual ToC model uses a scalar to model the total amount of environmental degradation. But software utility is much better modelled as a granular vector quantity. If the features match and the bugs and incompatibilities don't, it's useful software. However, the desired features, the types of bugs you're likely to run across, and (perhaps most importantly) the systems you care about the software being incompatible with vary quite a bit from person to person. So, you might find a local situation in which a relatively small expenditure leads to a significant increase in value for the person using the software, perhaps enough to make it worthwhile. The fact that the contribution causes the value to jump for lots of other people is almost irrelevant.

There are a few more important details to make this work, including differing actual costs (ie, code is much cheaper for a grad student than for a corporate IT department). But that's a detail fairly well understood by classical economics - ie, freshwater is much cheaper in Canada than Saudi Arabia, and so on.

A much more interesting detail is that you can play the "you scratch my back and I'll scratch yours" game. I'll use modified perl variable conventions just to make any economists who may be reading comfortable. Let's say that there are two changes, both of which are required to add $a value to users of the software (by requiring both, I'm modelling a "network effect" here). However, the cost of adding each change is $b, with 2 * $b > $a, but $b < $a. For one individual to add both features, the cost does not justify. However, if you find another person in the same position, you can agree to each contribute one of the changes. The total value to each of you then increases by $a, at a cost of only $b each. Win-win.

This game, I think, captures the essence of the force that makes "community" so powerful. What's even more interesting is that the agreement need not involve any element of coercion, even to follow the terms of the agreement. If your partner has a probability $p of following through, then the expected value for your cost is $b, while the expected value for the benefit is $p * $a. As long as $p >= $b / $a, there's incentive to follow through. Note that this is the easy two-player game, in contrast to the knotty Prisoner's Dilemma that gives economists so much trouble.

More restrictive free software licenses such as the GPL help codify this positive network effect. Otherwise, players in this game benefit equally as much (or more, if there's a competitive business relationship with the other player) by having the other player contribute the change publicly, but not themselves doing so. Of course, the other player has less incentive now, but there may be power imbalances that make the game asymmetrical, so that doesn't matter so much.

Finally, while I said contributions to code have positive sign, in contrast to plundering the environment having a negative sign, the value of software can be influenced either up or down. One of the most awesomely powerful of these downward forces is bit rot, which naturally takes its course if the software is left unmaintained. Thus, any player who has the power to stand in the way of necessary maintenance is effectively negatively contributing. This is why the fork right of free software is so critically important - it almost functions as a ratchet to make sure the value goes up and not down. I say "almost" because the cost of maintaining the software is still there, and if nobody picks that up, bit rot still sets in. However, bit rot is a classic example of granular, non-smooth gradients in value, and as such is an especially good candidate for maintenance work cost-justifying itself locally as described above.

None of this theorizing should sound that strange to people who do free software, but I nonetheless believe it's a real contribution to the economic understanding of free software. For one, treating cost-benefit as granular and having local variations, as well as inherent network effects pushing games of cooperation to be win-win, seem to be interesting additions to the ToC theory. It may be that they have no counterparts for traditional ToC models (if for no other reason than the signs being upside down, as described above), but otoh wouldn't it just be fascinating if you could find useful analogies in more classical ToC settings?

Second, it seems to me that this theorizing makes actual (potentially falsifiable) predictions, that might even be useful. For one, at a macro level it shows that, in contrast to the proprietary software lock-in model, the economics really are driven by the ToC, so you can't make money from free software that way. However, it suggests that the "granules" that appear at a more local level really do create economic incentive, and may in fact be the basis for a real business model. Lastly, it focusses attention on the inherent network effects of software as the most important factor for creating incentives to contribute. To me, it's obvious that network effects are the basis of almost all software economics, but my guess is that there are a lot of people who don't have that clue, particularly economists :)

Finally, while economics may be boring to many readers, I'm not sure it's worth ignoring. In the future, designing a free software project to have good incentives for contribution may be considered just as important, if not more so, than the traditional engineering considerations of good algorithms and data structures, modular architecture, and so on.

Hmm, maybe this should have gone on the front page. In any case, it needs expanding and more careful argumentation before it becomes a real essay. If none of you have read this far, then it's probably not a good use of my time :)