Software Economics – Public Goods

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”: – 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).

CodingHorror and Open Source Economics

Jeff Atwood writes about the economics of open source software:

Well, he actually doesn’t say as much, but that’s what it’s about. Someone really ought to do a book about this subject. I have some ideas – any takers? It’s always tough to write about because there’s so much material. It’s a topic that is near and dear to my heart – almost 10 years ago, I joined the Free Software Business mailing list, as I got curious about the intersection of free software and business, and how the whole thing worked. I’ve learned a lot in the meantime, including a stint at Linuxcare, which was one of the Linux companies during the dot com boom, and am still fascinated by the subject.

Before we get started, let’s reiterate something:

  • It’s clear that open source software works. There’s just no doubt about it – it’s been through ups and downs, the dot com boom and bust, and it will trundle happily (well, as happy as anyone is with this economy) through the recession too.

That point bears repeating. Everything else needs to take it into consideration. Could it work better? Differently? Perhaps, but it does work, so you need to understand it very well before you fiddle with it.

Jeff writes:

for the average user? Heck, how realistic is this for the average programmer? Even if you’re the type of macho, gung-ho programmer who can master an alien code base just to get some small pet feature or bugfix in — do you honestly have the kind of time it would take to do that?

Sometimes, when people say this:

The source code is freely available. If you feel so strongly about this bugfix/tweak/feature/plugin, why don’t you code it yourself?

They’re really saying this:

F**k you.

Which is of course a terrible analysis of open source, and its pros and cons. I wrote the following comment on Hacker News:

Heck, how realistic is this for the average programmer? …

“Actually, I have submitted lots of (mostly small and inconsequential) bugs and minor features over the years, to projects such as the Linux Kernel, Tcl, Erlang, Ruby, Rails, Apache, and probably lots of others I’m forgetting right now. I actually enjoy it quite a bit, come to think of it – there’s something cool about diving in and studying something new and different, and a thrill that comes with nailing the bug. Sometimes, the knowledge required to actually fix it is too much, and you have to settle for sending in a good bug report, but in other cases it’s very much possible to hack up quick, useful things despite not knowing much about the system in question. And, no, I’m not really that great a programmer… I’d consider myself fairly average.”

And I know I’m not alone, as I see similar sorts of people in Debian and the Apache Software Foundation. Debian, infact, is all about those kinds of tweaks to improve the operating system as a whole. And this sort of exchange goes on all the time, as evidenced by the huge success of a large number of open source projects.

Now, granted, most projects are really driven by one or a few really committed hackers, who do the lion’s share of the work. However, that large network of people who contribute, test, document, and suggest is certainly important to any open source project.

As long as we’re looking at my anecdote, let’s look at it in a bit more depth – most of those projects are developer tools or closely related. A cynic might note that Jeff comes from the world of Microsoft, where the core developer tools are provided by a company and ‘giving back’ is limited to payments and bug reports. But leaving that be, I think the enormous success of stuff like Ruby, Perl, PHP, Python, Tcl, Apache, Linux, GCC, and on and on and on indicates that, at least in terms of stuff that developers share between one another, open source works.

However, there are problems, one of which is that he (or, in unfortunately rather rarer cases, she) who writes the code does not necessarily get the money. And without money, he or she who writes the code must dedicate themselves to some means to actually accumulate a bit of money in order to pay for living expenses. Most likely, this is time taken away from the open source project, which is a loss for all the people who benefit from it. Proprietary software solves this feedback loop in a neater way (generally) – companies that create good products get money for their efforts, which can then be reinvested in development.

Jeff suggests that “sponsorship seems like a constructive way for people who are unable or unwilling to write code to affect the direction of a project.”, which is ok as far as it goes, and more or less works here and there, but hopefully he’s not thinking about trying it on a larger scale. This sort of thing has been tried before, and never really seems to take off. Part of the problem is that it can work on a person-to-person basis, but is almost impossible to standardize in a way that it makes sense to have some kind of clearinghouse that operates as a business. There are simply too many factors – what kind of open source project it is, what motivates the people behind it, how the transaction costs of defining a specification, monitoring the results, sending money and so on compare to the actual value of a fix… the list goes on.

Ultimately, it’s a nice idea, but it doesn’t seem to work out too well in practice.

Anyway, while it’s a good thought on Jeff’s part, at the end of the day, it is fairly evident that he doesn’t have a lot of first hand knowledge of open source business and economics. That said, to some degree, open source took everyone by surprise, and, lacking the nice, simple feedback loop that proprietary software has, can be a lot more difficult to get a handle on. I find it quite pleasant that way – it attracts both hard-headed business types and social-experiment idealist visionaries; both huge corporations (IBM!) and a huge number of individuals; both people who have gotten quite wealthy from open source as well as most of the rest of us who manage to make ends meet but still love it. It’s not something that’s easy to pigeonhole, and as such it’s hard enough to figure out the many ways in which it does work, let alone figure out how to improve on it.

Stay tuned for further installments:

Software Economics – Public Goods