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:
DedaSys Journal 