Ok, so everyone knows that, but I was particularly surprised. LangPop.com got on the front page of Hacker News the other day and I got a ton of hits. But virtually no one clicked on the advertisements - just a few clicks for many thousands of page views. Some of my other sites, which are of a more general-interest nature, do way better with far fewer visitors.

Not that I'm really complaining, I did langpop.com for fun, but it's a good reminder that it's a lot better to produce and sell things to a more general audience. Programmers expect, and largely get, most everything for free - me included.

I released some new statistics on LangPop.com. There are some new things:

• The normalized results are now user configurable - you can put in your own weights for the various data sources (such as Amazon, Craigslist, and so on), and see how the results change.
• Freshmeat.net fiddled with their web site, and statistics are not going to be available this month. Hopefully they will be able to correct the problem soon.
• On the other hand, I wrote some code to grab the data from Ohloh, so there's something new to look at while we wait for Freshmeat to come back on line.

So there is a fair amount going on. Hopefully Freshmeat will come back soon, and I can also add a few fixes to the IRC statistics which I've been thinking about.

In the process of doing the above, I also managed to do some open source work, albeit of a minor nature:

• I updated LangPop.com to use the Flotr Javascript chart library instead of Plotr. So I also updated my Ruby code to integrate it. It's a fairly thin layer at this point, but it does what I need. It's available here: http://github.com/davidw/chartr/tree/master
• I did some hacking on the Simile Timeline code, (used here on LangPop.com), correcting a bug, and also creating a system to install the whole thing with a simple command. Normally, it's kind of difficult to just use the Simile code on your own site, so I created an (admittedly hacky) way of making it easier to install. That code is here: http://github.com/davidw/standalone-timeplot/tree/master

Oh, yeah, and we moved from Innsbruck, Austria back to Padova, Italy!

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.

<small>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...</small>

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).

Jeff Atwood writes about the economics of open source software:

http://www.codinghorror.com/blog/archives/001247.html

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

A thought occurred to me a while ago, and I thought I'd write it up:

Some languages are better at others for Really Big Systems, those with hundreds, or perhaps even thousands of people who work on them. They allow people to divy up work without stepping on one anothers' toes. Other languages are great for writing quick little hacks or small, one-off programs to just get something done. Generally, people talk about the former as 'scaling well', but there's an important point missing there: for most people, what really counts is not the absolute upper limit, but the range of problems a language can handle. To haul out the poor, bedraggled transportation example once again, some things, like Boeing 747's, are pretty good if you have to fly halfway around the world. They're not so good if you need to pop out to the grocery store for milk. Bicycles are a great way of getting around the congested streets of the Italian town I live in, but a little less useful once you start talking about distances upwards of 10 km. Cars, on the other hand, are popular because they're pretty good at a lot of things. It might be a lot slower than flying, but you could drive from Oregon to Maine if you needed to. A car might not be quite as convenient as a bike or scooter in downtown Padova, but you can still use it. So the car, while ultimately being inferior to the 747 in terms of its upper range, is way more flexible. I think the same thing generally holds true for languages. Java is seen as being good for big, 'enterprisey' sorts of things... and it probably is - it has a lot of mechanisms to keep people from getting in one another's ways. On the other hand, writing a quick sysadmin program in Java is, at least for me, not all that fun compared to a language like Tcl or Ruby. Tcl is more or less in the opposite corner. Sure, if you know what you're doing, you can write massive programs with it, but it's probably not its sweet spot. Currently, I'm pretty happy with where Ruby is: it lets me do the simple stuff quickly and easily, and has decent mechanisms for growing and organizing a codebase, although of course you have to be careful with things like reopening classes ("monkeypatching") lest they interfere with the work of others.