The puzzling success of open source

Against many economic, production and social norms, open-source software has emerged as a serious challenger to proprietary software products. Steven Weber’s new book comprehensively tells the story | IslamOnline.net

You perhaps consider, as I do, Titanic and Lord of the Rings as cinematic marvels. The special effects of both movies were made on machines running the Linux operating system; the most famous of open-source software products. And, notably, some of the world’s most celebrated commercial and non-commercial institutions are running their daily operations on Linux-mounted machines—including Google, Amazon, Reuters, Merrill Lynch, DreamWorks, the American Departments of Defense and Energy and the National Security Agency in the US. What is it in open-source software that has made it such a success?

Steven Weber’s book, “The Success of Open Source“, attempts to explain how the open-source software development process emerged, what factors make it work and what knowledge we can discern that can be applied in other, completely different arenas.

But why is software important? Weber, a political scientist at the University of California in Berkeley, believes that software is an “essential tool with which humanity will continue to create wealth and serve itself with more value.” What is unique about the open-source process is that it is “a real-world, researchable example of a community and knowledge production process.” There is thus the possibility of recognizing new perspectives on problems like social cooperation, and the institutional, political and economic consequences of the Internet revolution on human societies.

The Unix Culture

The open-source process takes its roots from the late 1960s when Ken Thompson, a programmer at AT&T, wrote in 1969 the ‘kernel’ (or the core program) of a new operating system he named UNICS (uniplexed information and computing services), and later modified to Unix. To avoid anti-trust lawsuits that might result from entering any market other than “phones and telegrams,” AT&T preferred not to go ahead with the crude operating system or try to tap it for any commercial gain.

Thus, the company started to license the software to universities and later military agencies that requested it with minimal terms. “The software came ‘as is’ with no royalties to AT&T, but also no support and no bug fixes,” wrote Weber. This represented a green light to users at computer science departments to “share support and bug fixes with one another because no one at AT&T was going to help them.”

Unix found its way into the University of California at Berkeley, Rand corporation (an American think-tank), University of New South Wales, Massachusetts Institute of Technology (MIT), among others, where students and researchers alike were profoundly modifying the code and developing it jointly and freely.

By the beginning of 1983, Unix had become a widespread operating system and the business climate in the US changed, so AT&T decided to rewrite the Unix license making dramatic changes, including license fees rising up to US$ 100,000. Worse yet, users/developers were denied access to the code as well as the right to modify it.

‘Free’ Like in ‘Free Speech’

In 1983 a new Xerox laser printer arrived at the artificial intelligence lab of MIT, where programmer and researcher Richard Stallman worked. But unlike any other piece of hardware to come to the lab, the software that runs the machine was withheld. This meant that whenever a paper jam occurred, the lab researchers couldn’t do what they used to do—tinker with the software to solve the problem.

Stallman considered the shift in attitude unethical, and the next year resigned from his position at MIT to devote his life to free software, founding the Free Software Foundation (FSF), a non-profit organization. For Stallman, software was not “just a tool to run computers. It ultimately was a manifestation of human creativity and expression,” Weber quoted the FSF's founder.

More important still, Stallman deemed software “a key artifact of a community that existed to solve problems together for the common good.” He stresses the essence of what Free Software stands for: “free like in free speech, not free beer,” thus, free doesn’t mean zero price, rather it means retaining the freedom for users/developers to see or modify the code as they please.

The confusion between freedom and zero price remained, however.  Then it was Eric Raymond, an open-source pioneer, who proposed ‘open-source’ in a conference of the programmers’ community in 1998. The new term was approved as a more neutral and business-friendly alternative to the ideology-charged FSF, with its presumed anti-corporate attitude.

The open-source community has embraced two radical schemes from the FSF.  First was the four freedoms governing the way programmers (individuals or organizations) deal with the code. This includes the freedom to run the program for any purpose; to study how it works; to redistribute copies of it for free or for a fee that covers distribution costs; and to change and improve the program and redistribute the modified version so the public can benefit from it.

Second was the General Public License (GPL) that Stallman designed to protect the contributions of voluntary programmers from being exploited by big corporations. The GPL, a special license enforced by copyright laws, states that everyone is free to use-modify-distribute the code as long as they pass back to the community any modifications they make to the original code. This way, any code based or built on code licensed by the GPL becomes itself ‘GPLed’.

The Process or the Code?

Weber believes that however great the open-source products are, the process employed to produce them is far more important.

The first step in understanding this process is to know what motivates programmers to voluntarily contribute their time and mind space to projects that will not bring them any (direct) financial gain. The author cites a 2001 survey by the Boston Consulting Group (BCG) that aimed to segment programmers participating in open-source projects based on what motivates them. About a third of the respondents were “believers” who believed the code should remain open. About a fifth were “professionals” who said working on such projects helps with their jobs. A quarter of the respondents were “fun-seekers” participating mainly for intellectual stimulation, and about a fifth were “skill-enhancers” seeking to gain learning and experience from open-source programming.

But supposing the open-source code is a product freely available for the taking, then conventional economics tells us that everyone would prefer a free ride rather than developing the product. After some time the product would disappear or at least lose its “scarcity” value and the system (or the open-source process) would unravel backwards and vanish—which obviously is not the case.

What helps sustain the open-source process is that each participant prefers to contribute positively in search of a benefit rather than just piggybacking on the work of others. And we can’t even consider those who only use open-source products developed by others—as downright free-riders. It is in their interest to have efficient programs, thus they continually give feedback on the bugs they stumble upon; which is an added-value contributing to the whole process.

Trial and Error

In open-source everyone is free (and encouraged) to take the code and build on it using a different and innovative path— a process called “forking” in the community's vernacular. But forking appears only occasionally. How does the open-source community drive progress with neither too frequent forking that may lead to incompatible versions of the programs nor too rare forking that could result in an innovation impasse?

The open-source community used its intuitive trial-and-error method to come up with unconventional solutions. With the release of earlier versions of Linux, the emphasis of Linus Torvalds, the Finnish programmer who wrote the kernel of the operating system, was directed at leveraging the large numbers of programmers in fixing bugs in order to release stable versions. Yet, he soon spotted the need among many developers to use their energy in innovating new services for the system rather than debugging the existing code. Torvalds solved this by starting the tradition of making available two versions of the open-source products at the same time. One is stable and almost bug-free for users, the other is experimental for developers. This solution helped the innovations in the open-source products to run hand-in-hand with the debugging and stabilizing activities.

Meanwhile, programmers found the choice of forking the code and starting over less appealing. And thus consistency of products like Linux or Apache (the dominant open-source software managing interaction between your Web browser and servers hosting Web sites) was maintained.

Misconceptions?

A widespread fallacy about open-source communities is the idea that they are hostile to copyrights. (Part of the reason is that Richard Stallman famously called the GPL license ‘copyleft’). Weber argues against this perception: “open-source intellectual property aims at creating a social structure that expands, not restricts, the commons.” Thus, the author considers the open-source process a platform of contributions and learning depending on copyrights to be based on distribution; not exclusion.

While the logic behind the current copyright laws is that having a right to a property gives me the privilege of excluding you from benefiting from it, the open-source copyrights are based on distribution—where a sustainable value creation process results from distributing the code freely. And we can see signs of the viability of this new copyright paradigm in some successful companies that have figured out ways to make money out of the open-source products without restricting or putting a premium on the code itself. IBM, for instance, is making money from open-source by selling software customization and maintenance services. Also, it manufactures customized hardware servers for Linux and releases them at competitive prices, compared with other vendors who charge clients for both the software and the hardware components.

So, will open-source software knock down proprietary software companies? Not exactly. Weber says that contrary to claims by both proprietary and open-source software advocates “that their worldview was self-evident, obvious and an inevitable consequence of the material forces and constraints that exist in computing…neither proprietary nor free software is ‘blind destiny’. Both continue to exist in a kind of software industry ‘dualism’.”

* Note from the editor: all information in this article is based on information from Steven Weber’s book, “The Success of Open Source.”



---