Looks like around the same time I was writing my “Third Way” column, the NY Times was editorializing to similar effect — though, of course, without quoting Hayek (heaven forfend). Jim DeLong, however, argues that open source boosters are being naive if they think Linux is suitable for government (or, indeed, business) use.
One preliminary observation. Jim closes with the suggestion that government keep its “hands off.” As a reply to the Times’s vague statement that government should “support” the development of Linux — which could mean sending Linus Torvalds a monthly check, for all I know; they’re not too specific — that’s sensible enough. But if the question is just “Which OS should government use?” then the state quite literally cannot “keep its hands off” without abstaining from computer use altogether. If it goes with any proprietary software, after all, the state necessarily acts as a market participant, and becomes a huge buyer of software licenses. This cannot help but affect software markets: the question is not “should the government have an influence here?” but “how can that influence be minimally pernicious?” The most plausible answer would seem to be: by spending less taxpayer bucks (viz., using software that doesn’t need to be licensed) and, most importantly, by not excessively subsidizing any one firm (viz., Microsoft). It’s also a little odd that DeLong cites IBM and several other large companies’ recent calculations that, even given the money they’ll have to spend on in-house coding and development, it’s more cost effective to go with Linux than to pony up the money for licenses from Microsoft. It’s not enough, after all, to point out that those who adopt the OS may have to pay for some programming or support work; one has to further ask “compared to what?” DeLong, as far as I can tell, doesn’t.
We also see the incentives point trotted out: when software is non-proprietary, programmers won’t be willing to develop applications. Given the large number of Linux applications, especially when one considers the relative youth and small percentage of computers running the OS, this claim seems premature, if not in outright defiance of reality. The proper response to an observed empirical fact inconsistent with your expectations is not: “but I’ve got this theory!'” Barring good reason to be suspicious of the facts, one ought instead to wonder what might be wrong with the theory. The piece by Yochai Benkler I’ve cited before provides a reason to doubt the conventional wisdom on this: when the production function is sufficiently granular (viz., capable of being split up into small tasks) and potentially distributed over a large programming community, the incentives problem becomes trivial. Pure coding pleasure, reputation effects, or any number of other incentives can do the trick. The “viral” nature of the GPL license, which DeLong sees as a bug, is actually a feature in this regard. It means that even when a firm must pay a coder to develop something they need, the rest of the user community gets to “free ride” on that innovation. That may sound a bit commie, but it’s also the way cultural production has worked for millenia. Whenever we enjoy works in the public domain, we free ride on the efforts of previous generations. It may be true that, even once Benkler’s analysis is taken into account, the inability to fully internalize all benefits will result in somewhat less code produced at the margin. But as economists are forever telling us, one has to look at both sides of the ledger: weigh the difference in code produced under proprietary and open models (if Benkler’s right, maybe not nearly as large as DeLong seems to think) against the benefit to the thousands or millions who can benefit from that code without cost and, perhaps even more importantly, use it as a stepping stone to further innovation by incorporating the source in new programs. DeLong’s distaste for utopian hippie coders is clouding his economic reasoning.
