The Peer Production Illusion: Part I: The Myth of Open Source Software

Essays on technology, psycho­analysis, philosophy, design, ideology & Slavoj Žižek


December 19, 2011

The Peer Production Illusion

Part I: The Myth of Open Source Software

My relationship to the open source movement is a familial one. The idea was passed down to me in the mid 90s by my father, when he installed Slackware Linux on our home computer in a protest against the dominance of Microsoft. He became something of an open source zealot and as a teenager at the time, it was probably inevitable that I would follow. In college, I did run Windows because I needed to write papers and at the time there were no good open source word processing programs, and besides, I wanted to play the latest games – but this deviation was a frequent topic when he would call me, and we would talk about the latest distribution he was running, how much easier it is to install and how much better the driver support is now.

Even if I was less than faithful in the practice of our family computer religion, my heart was in the right place. I followed the open source movement closely, cheered our victories, mourned our losses, and argued for the idea on internet forums. The broader P2P idea grew out of that, and for me it was a natural extension. Because of this proximity, it’s difficult for me to really grasp the extent that the movement has grown beyond an obscure subculture. My filter bubble has been carefully tuned towards open source and P2P, so it’s easy to not notice when those ideas start to spread.

But one thing I have noticed is that non-programmers and people outside the tech industry have begun to advocate for the idea, a development that has been interesting to watch. In some ways, they are outsiders to the open source tech community that is usually focused on Linux and other big projects, and the adoption of the ideals by the newcomers often contains an element of misrecognition. They often attribute a more or less radical, anti-capitalist potential to the movement that many open source programmers don’t agree with, and often explicitly reject.

That’s not in itself a criticism. It’s within the realm of possibility that the newcomers’ perceptions are accurate, and the programmers are simply not aware of what they are really doing, but it is strange to see rising enthusiasm for P2P in a period when I became more and more disillusioned with it. This blog post is about why I’m disillusioned.

Note: I use the term open source software rather than Richard Stallman’s preferred term free software or acronyms like FLOSS, but this is out of habit. The philosophical differences between “business-friendly” open source advocates and the more purist Richard Stallman aren’t significant for the purposes of my argument.

The picture we have of open source software development is that it is the spontaneous activity of volunteer programmers collaborating together in a gift economy with no financial incentives and creating software that’s comparable or better than what’s produced by large for-profit proprietary software vendors like Microsoft. The reality is somewhat different – although this gift economy model is accurate in some cases, most of projects of modest size are funded by corporations in one way or another. This is certainly true of every open source “success story” where the open source product has achieved greater market share than the proprietary one.

The precise form of corporate sponsorship varies: in some situations, the bulk of the code by programmers who are employed by corporations who pay them to contribute to the project. This describes the Linux project. According to an analysis by Linux kernel contributor Jonathan Corbet, 75% of code is written by paid developers working for IBM, Red Hat, Novell, etc. – companies who compete with each other in the marketplace, but cooperate by funding development of the Linux kernel. Another example is WebKit, the main technology behind Google’s Chrome browser, which is run by programmers from Apple, Google, Nokia, Palm, Research in Motion, Samsung and others. The domain is owned by Apple and the corporate connection is apparent on the Contributing Code page, which says “If you make substantive changes to a file, you may wish to add a copyright line for yourself or for the company on whose behalf you work.”

A more common business model is services-and-support – a company owns the copyright for the software, pays for and organizes much of development. This is profitable because the company uses almost as a form of advertising to help sell support and consultation services to large businesses who want to use the software. This describes MySQL, PHP, Red Hat, Ubuntu and many others.

These business models evolved in the late 90s and early 2000s, when the question of how open source could be profitable was a hot topic of debate on internet fora. Rarely, someone asked whether open source should be profitable and questioned its inclusion into capitalism, but they were always shouted down. The conclusion to be drawn is that open source software does attract volunteers, but not for serious projects that are competitive with proprietary software. These almost always have substantial corporate backing.

In 2005, Bruce Perens, co-founder of the Open Source Initiative and coiner of the term “open source”, wrote The Emerging Economic Paradigm of Open Source to explain why it is profitable for corporations to fund open source projects, specifically addressing and refuting the claim that open source software is a gift economy. This claim was made by OSI co-founder Eric Raymond in one of the most well-known explication of open source philosophy, The Cathedral and the Bazaar. Perens says:

Raymond did not attempt to explain why big companies like IBM are participating in Open Source, that had not yet started when he wrote. Open Source was just starting to attract serious attention from business, and had not yet become a significant economic phenomenon. Thus, The Cathedral and the Bazaar is not informed by the insight into Open Source’s economics that is available today. Unfortunately, many people have mistaken Raymond’s early arguments as evidence of a weak economic foundation for Open Source. In Raymond’s model, work is rewarded with an intangible return rather than a monetary one. Fortunately, it’s easy to establish today that there is a strong monetary return for many Open Source developers. But that return is still not as direct as in proprietary software development.

Perens goes on to argue that open source is economically rational for certain classes of software that he calls non-differentiating: technology that is used to support the functions of a business, but isn’t a competitive advantage. These are things like computer operating systems, web servers, web browsers, database software, word processors, spreadsheets, etc. which can be considered part of the infrastructure of a business. Often, differentiating technology is built out of these components, and Perens uses the example of Amazon’s book recommendation software – customers might go to Amazon because of this feature, which Barnes & Noble does not have, so this should be kept proprietary. But customers don’t shop at Amazon because of its amazingly flexible and efficient web servers, so it makes sense for them to collaborate with Barnes and Noble (and vice versa) on this part of their business.

He claims that something like 90% of software is infrastructure, which is a useful analogy. Corporations don’t create their own private roads, they effectively collaborate with their competitors by funding public roads through their tax dollars. Historically, corporations have used private, closed consortia to collaborate on software infrastructure – member companies agree to fund the development of software and make it available to each member. In many cases these have become outmoded and replaced with open source projects, and Perens lists some examples: the Taligent consortium to standardize Unix has been replaced by the open source Linux project, and the Common Desktop Environment was replaced by the open source GNOME Project. But the consortium model continues to be relevant in other areas, especially in developing industry standards: the Unicode Consortium, the World Wide Web Consortium, the Internet Systems Consortium are all funded and staffed by major internet companies.

The history of software consortia is sometimes forgotten even in academic accounts of the open source movement. We’re often presented with an appealing but simplistic David-and-Goliath narrative of a few individual hackers refusing to bend to the trend of proprietary software. The overall picture is the open source movement as a unique space of free and open co-operation in an antagonistic relationship to a vast capitalistic industry characterized by private ownership and monopolistic practices exemplified by Microsoft. In reality, there are many forms of industry collaboration with varying degrees of openness, and open source projects are one example. Perens makes the case that private competition and open cooperation are not opposed to each other – cooperation at the level of non-differentiating technology allows corporations to focus their efforts on proprietary innovation and differentiating technology.

Open source software is often perceived as more or less independent of corporate influence. Not only is this not true, in many important cases, open source software represents a move towards private control rather than away from it. Some open source projects like the Apache Web Server and PostgreSQL began as academic projects, officially the intellectual property of publicly-funded universities. These were spun off into private companies or non-profit foundations funded by private companies, albeit with open source licenses that encouraged academics to continue contributing improvements.

This was not a difficult transition, because in the minds of industry executives, programmers and academics, one purpose of academia is to provide public subsidies for the research and development of infrastructural software, allowing corporations to focus their efforts on proprietary innovations that offer a competitive advantage. Open source projects play a similar role, but instead of state subsidies, these projects are subsidized jointly by corporate sponsorship and the free labor of individual volunteers.

The conclusion that I want to draw is a very simple one: these connections demonstrate that, in practice, the open source software movement is compatible with and influenced by capitalism. This casts doubt on overly optimistic claims that peer production is intrinsically anti-capitalist, but also on less radical perspectives that see open source software as more protective of consumer rights. We see some evidence that Linux kernel development prioritizes the needs of large enterprise customers over the needs of individual home users.

In Part II, I will discuss a narrower hypothesis, that P2P practices have a theoretical basis that gives it some kind of anti-capitalist potential in principle if not yet in practice.