To look at the economics of open source software, you have to start with the economics of software as a category, both proprietary and open source.

Note: it should be perfectly obvious to everyone that open source software works, and works quite well for some things. This article is more about understanding the how and they why. Just to avoid any confusion…

If you look at software as a product, it has a couple of defining characteristics:

• It’s difficult to keep people from sharing it. Not impossible, but not easy, either. It was already doable in the days of floppy disks, but with the rise of the internet, it has become nearly effortless. This means, in terms of economics, that it’s “non excludable” – it’s difficult to keep everyone from enjoying it once you’ve created it and started to distribute it.

• If you give a copy of a program to a friend, it in no way detracts from your own use of the program. Quite the contrary, it may even make your use of it better, if, say, your friend discovers how to use a cool feature, or writes a handy extension. This is different from traditional goods like bicycles. If you loan me your bicycle, you can’t use it to get around. In economics, things like software (or radio or over the air TV) are called ‘non rivalrous’ goods – many people can take advantage of them without ruining them.

What do you get when you combine something that’s “non excludable” and “non rivalrous”? In economics, these are known as “public goods”:

http://en.wikipedia.org/wiki/Public_good – read the whole thing if you have a few minutes, it’s what I’ll be talking about.

As per the article, “The Problem” as it were, is the free rider problem. Let’s stop and look at a contrived example:

Bob is an ex-dentist and really knows what it would take to write a great program for managing a dentist’s office (or pick your own example… it’s contrived, don’t quibble about the details). He’s also a good programmer, with the skills necessary to implement the program. He talks to a few of his dentist friends, and they’re enthusiastic about the whole thing.

Let’s look at a few scenarios of how things might play out:

Bob values his time at 10 dollars an hour, and it will take him 100 hours to complete the project, meaning the whole project would cost about 1000 dollars.

One way things could work is that he could find a dentist friend who needs this program, and bill him 1000$ for his time and services, bang out the code, and release it as open source software. Bob gets his money, the dentist gets his code… and all the other dentists in town get it for free, which is bound to make the dentist who shelled out the money a bit irritated, given that he’s a human, not a homo-economus, and doesn’t like paying and see others get the same thing for free.

Let’s introduce another variable: the software is only really worth 200$ to the dentist – any more than that and yeah, it’s helpful, but not worth that much money (And please stay with me, I know it’s contrived, but keep in mind that the situation is possible, even if the numbers might be different). That means that if Bob wants 1000$ for his time, but the dentist will only pay 200$, then no transaction will occur! The software won’t get written, Bob won’t get any money, and the dentist will be worse off because he won’t have the nice program, and neither will his dentist colleagues.

One way things might still work is if the dentist rounds up some friends and they all contribute a bit, however, that’s kind of a pain in the neck for everyone concerned – the dentist doesn’t want to get into the software business and spend a bunch of time trying to chase his friends for money, and even if 10 dentists contribute, the ideal position to be in his the 11th guy, who pays nothing, and still gets the software for free. So it’s in everyone’s interests to not return the dentist’s calls in the hope of being the 11th guy. Also, none of them gets the software until they’re all on board.

So, how to resolve this problem? The wikipedia page talks about introducing an exclusion mechanism, which in this case would be a copyright system so that Bob can sell a copy of his software for 100$ and be sure that it won’t be open to everyone to use. This way, the dentists get the software for 100$ less than they value it at (200$), and as soon as Bob signs up an 11th dentist, he’s making more than his time/materials costs, and is therefore coming out ahead! The dentists all know that they’re paying the same price, so have no reason to grumble about free riders. In short, everyone is pretty happy.

Of course, in the real world, things don’t play out like that all the time. There are problems with the simplified example above, some of which are very evident: the cost of enforcing copyright laws, in an age when copying is extremely easy, is very high and potentially very intrusive. However, “intellectual property” is, by and large, a compromise solution that has had positive aspects, especially when you ignore the outliers like Microsoft, and look at all kinds of niche software vendors, who make a nice living, create good products, and have happy, satisfied customers.

If you look at the other solutions to the free rider problem listed on the wikipedia page, we can see how they might be applied to the world of software.

• Dominant assurance contracts

  Assurance contracts are contracts in which participants make a binding pledge to contribute to a contract for building a public good, contingent on a quorum of a predetermined size being reached. Otherwise their money is refunded. A dominant assurance contract is a variation in which an entrepreneur creates the contract and refunds the initial pledge plus an additional sum of money if the quorum is not reached. In game theory terms this makes pledging to build the public good a dominant strategy: the best move is to pledge to the contract regardless of the actions of others.

  This means that Bob goes out and gets a number of dentists to pledge 100$ to his dentist program, and if he doesn’t raise at least 1000$, he’ll give them each back 110$. So it’s a clever solution that works out for everyone, but is still a lot fiddlier than the copyright system – Bob has to go sell the contracts and explain how things work to a bunch of people before he can get started. This might be doable with 10 dentists, but for a more mass-market sort of program, it would not be feasible.

• Coasian solution

  a mechanism by which potential beneficiaries of a public good band together and pool their resources based on their willingness to pay to create the public good. Coase (1960) argued that if the transaction costs between potential beneficiaries of a public good are sufficiently low, and it is therefore easy for beneficiaries to find each other and pool their money based on the public good’s value to them, then an adequate level of public goods production can occur even under competitive free market conditions.

  That sounds an awful lot like open source software, especially the kind espoused by groups like the Apache Software Foundation, where making free software is not a moral imperative, but a good way of producing something that is not necessarily a key business component. This has proven to work very well for infrastructure type code, as well as lots of developer tools. It is less proven as a way to develop end-user software – in the example above, it’s not like Bob needs help to develop his system, or that the dentists really want to contribute – they just want a working program and don’t want to get involved in its production.

• Government provision
  This would mean that the government would be responsible for funding the production of open source software. I’m no free-market zealot, but I think the idea of the government being responsible for software products is not one I am entirely comfortable with. Of course, I do think the government has a role with places like universities, where people can do “research” in the sense of hacking on cool systems just to see what can be done, without necessarily having to be thinking of how to make a profit in the short to medium term. Software like BSD, Tcl, and plenty of other great stuff has come out of universities, meaning that in part it is ultimately funded by the government and taxes. The problem, though, is the process of refining those things down into something people are willing to buy. Would Bob go to a local government official to get a grant to produce his software? Why should Bob get the contract and not some other guy? Does the government official know enough about code or dentists to determine who should write the program?

• Subsidies
  Subsidies might work to encourage software production, but would probably simply be abused. It’s probably not as relevant as other potential solutions. What form would it take? 1$ off your taxes per line of code written? It would be difficult to place a value on anything, and might be quite difficult to implement.

• Privileged group
  This, as the wikipedia page says, is an incomplete solution, and is less generally applicable. In terms of Bob, it might mean that instead of valuing his code at 200$, his wealthy dentist friend with a large practice really needs the code – it’s worth 2000$ to him, and can pay Bob the full 1000$ to develop it out of pocket and still come out ahead, and he doesn’t really care that much about the free riders because he’s getting what he needs and the rest doesn’t matter too much.

• Social norms
  If Bob and the dentists live in a small town, and are all good friends, perhaps Bob could still release the software, and even though the other dentists could copy and use it for free, they don’t, because they feel an obligation to Bob to help him out for the work he’s done. Even though they could take advantage of it for free, they would feel bad about doing so, and so each chip in 100$, which after enough people contribute, is enough to cover Bob’s costs. It’s likely that anything distributed on a larger scale, however, will see more free-riding, and “please pay!” might not work out. And it’s probably fairly distressful for a developer to make that jump, knowing he’s at the mercy of other people’s good will.

None of these solutions is perfect, and all, including exclusion in the form of intellectual property laws, or simply doing nothing at all, have problems of their own. Due to the very nature of software, this is somewhat inevitable, and the best we can do is come up with good compromises, and continue to reevaluate them as technology and society change (this is something that needs to happen with IP laws, for instance).