FREE SOFTWARE: HISTORY, PERSPECTIVES, AND IMPLICATIONS

By Greg Michalec

July, 2002

FREE SOFTWARE: HISTORY,

PERSPECTIVES, AND IMPLICATIONS

Submitted to the

School of Interdisciplinary Studies

(Western College Program)

in partial fulfillment of

the requirements for the degree of

Bachelor Philosophy

Interdisciplinary Studies

by

Greg Michalec

Miami University

Oxford, Ohio

2002

APPROVED

Advisor

William H. Newell

ABSTRACT

FREE SOFTWARE: HISTORY, PERSPECTIVES, AND IMPLICATIONS

by Greg Michalec

Free software development, also known as 'open source,' is a unique phenomenon in which volunteer programmers collaboratively develop software on the Internet, and then make it available, along with its source code, for no cost. This process is particularly interesting in that many free software projects are successfully competing against traditional, proprietary products in the marketplace. This paper discusses the history and origins of free software, then considers various studies of the phenomenon from economic, sociological, and economic perspectives. Finally, I propose several possible social, political, and economic implications of free software.

Copyright (c) 2002 Greg Michalec.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

ACKNOWLEDGEMENTS

This project, like any other human endeavor, has been a social process, and without the help of the following people, it would not exist:

Nancy, Beth, Brian, Mikey, the Denizens of the Green Machine, ATP, Maggie, Maxwell, Mom & Pop, Dmitri, Bill, the WCP Classes of 2000 & 2002, and everyone else who supported me, or at least tolerated me, through this three year endeavor.

Thanks for all your help and support.

I. Introduction

We live in an age of increasing corporate power. The news of the latest mega-mergers is piped into our homes by giant media conglomerates. Each day, power, influence, and control become more centralized and consolidated into fewer and fewer organizations - mammoth bureaucracies that edge their way into every aspect of our lives. Technology only aids this process, and one of the most powerful entities today is the software company Microsoft. With over $40 billion in liquid assets¹, they are the untouchable of the free market – widely recognized as a monopoly, yet no one seems to have the will or the power to hold them back. Microsoft has successfully usurped IBM's place at the vanguard of the computer industry, conglomerated market share from other technology heavy-hitters, and now is managing to survive an antitrust lawsuit. Neither the free market nor the U.S. Government have been able to slow down Bill Gates’ behemoth.

Yet, there is one product that is slowly eating away at Microsoft’s monopoly share of the software industry. It has been sneaking in through the back doors of server rooms for years. It has no advertising budget. It has no billion-dollar war chest. The closest thing it has to a marketing campaign is an icon of a cute, smiling penguin, which may have eaten a little too much herring. This product - Microsoft’s biggest fear - is an operating system called Linux, which is but one product of the phenomenon of Free Software.

The term ‘Free Software' refers to software that has been distributed without restrictions on use. This means that it is not only available for use with no monetary cost, but that one also has access to the inner workings of the software – the source code – to make any changes, fixes, additions, or adaptations one chooses. While such software is often protected by legal licenses, these licenses generally only serve to protect the software from having further restrictions placed upon it.

A free software project constitutes an extremely complex system. The Linux kernel consists of over 3.1 million lines of code², and has thousands of contributors who are scattered all over the world, most of whom have never seen each other. Though English is the lingua franca of most large international projects, many developers only have the most rudimentary knowledge of it. Yet, collectively they are able to create a piece of software which performs millions of complex routines, runs on many different types of hardware, and allows hundreds of devices to communicate with one another – and they give it all away for free.

What is particularly interesting about free software, also known as ‘open source software,’³ is that it is usually developed by several individuals in collaboration with each other via the Internet, usually for no pay, yet it results in products that are of equal or greater quality to those produced in traditional software environments. This project examines what free software is, analyzes various explanations for the phenomenon, and suggests possible implications of free software, both theoretical and practical.

Programming Basics

Before diving into this examination, it is necessary to briefly explain some of the processes and terms used in software development. The process of creating most computer programs involves two steps. The first step is to write the program in a human-readable programming language, such as C++, Java, Perl, COBOL or BASIC. A programming language provides a layer of abstraction between the logic of a program and the actual mechanics of the tasks that must be executed on a computer’s hardware, though the level of abstraction depends on the language used – some languages, such as Perl or BASIC, are very close to English and are fairly easy to comprehend, while others are much more closely related to machine language. This step is known as ‘programming’, and its end product is known as ‘source code’, the human-readable documents that define a program’s logic. For example, the Perl code

#!/bin/perl

$celsius = $ARGV[0];

$fahrenheit = ($celsius * (9/5)) + 32;

print “$celsius degrees celsius = $fahrenheit degrees fahrenheit.\n”;

converts a temperature given in Fahrenheit into its Celsius equivalent, and displays the result on the screen.

The second step is known as ‘compiling,’ in which source code is transformed into a form that can be run on a computer. This is known as a ‘binary’ or ‘executable’ program, and can only be read by a computer, specifically only the same kind of computer that it was compiled on. A useful metaphor for programming is to think of baking a cake. The source code can be thought of as the recipe, which you can alter, add upon, or improve, before baking (compiling) it. And just as most people don’t buy a recipe from the bakery, when you purchase software, you usually only purchase the executable form.⁴

Free Software Development Process

When a software developer wishes to contribute to a free software project, this is usually the process that is followed: The developer downloads the source code from a central repository. These repositories are maintained by the project itself, and often linked from a web page related to the project. This accounts for some degree of authenticity – the project members take pride in their work, and therefore would not distribute malicious code; it is up the developer to assess the trustworthiness of the project, but this is the case with all Internet downloads.

Most free software projects have at least two versions of source code available; one is deemed by the project to be ‘stable’ – that is, reasonably well-tested and bug free, and thus meant for public consumption. The other, known as ‘unstable,’ or ‘development,’ is the current state of the code as it is; this version is intended for developers or users ‘at their own risk.’

Once the source has been obtained, developers may explore it and locate the area they want to change. Source code almost always contains ‘comments’ - side notes in plain English (or another language) describing what each piece of code is doing, notes as to the usage of particular sections, explanations of design choices, etc. which aid a developer in navigating the code. Additionally, the documentation to a piece of software is most often included with the source code. Developers may also find information on the project’s website, or they may subscribe to the project’s email list and ask the other developers about the code.

Once developers have made the desired change, they usually generate a file that compares their changes to the original state of the code. This file is automatically generated by a common program, and is called a ‘patch.’ The developer then submits the patch to the rest of the development community, usually via an email explaining the purpose of the patch (although in some larger projects the patch is given to an individual who maintains a particular section of the code).

At this point, the patch is examined for quality, to make sure it behaves as intended, keeps in line with design goals, does not negatively affect other portions of the code, etc. This is sometimes done by the consensus of the community via email, or by the aforementioned maintainers, or another individual who acts as a gatekeeper. If the change is acceptable, it is then ‘merged,’ or combined into the existing code, so that future developers will download the change.

II. A Condensed History of Free Software

Pre-Software Industry

In the early days of computing, the 1960s and 70s, computers were fairly specialized, simple machines used only by highly trained professionals. In order to make the machine do anything useful, an operator would have to do a fair amount of programming. Because it was necessary to optimize one’s programs to use the early hardware in the most efficient way possible, and because operating systems were not nearly as sophisticated as they are today, operating a computer required an intimate knowledge of both the underlying hardware and software. Thus, it was common practice for computer operators to share the source code of the programs they wrote.

The practice of sharing code has its roots not only in the necessity of knowing how software interacted with hardware at the most basic levels, but also from the scientific tradition most computer operators came from. The majority of early computers were used in research laboratories or the science departments of academic institutions, both of which have a strong culture of sharing results and methods within research communities.⁵ It only made sense that if one had solved a particular problem, or developed a new way of performing a task, one should share that knowledge so that more work could be done.⁶

There was no software industry as we know it back then – most of the software used was either produced by the hardware manufacturer and shipped with the machine, or it was custom-developed in-house. The primary value lay in the machine; software was not sophisticated enough at that point to provide much value of its own.

This slowly began to change in the late 1970s and early 1980s. Hardware became powerful enough to support more sophisticated applications, and thus machines became more generic, while software was tuned to specialized tasks. With the invention of the microcomputer, computer hardware was becoming more common, and thus its price was falling. Corporations such as IBM, Digital, and AT&T anticipated that computer software would hold much greater value in coming years; thus, they sought to protect that value. They began to implement restrictive licenses and non-disclosure agreements with the software they shipped. The era of sharing software was over, and a new industry was born.

Richard M. Stallman and the GNU Project

Richard M. Stallman (often referred to simply as RMS), a computer operator at MIT’s Artificial Intelligence Lab (where some of the most brilliant hackers⁷ of the day worked), felt particularly affected by the change. He felt that the restrictions being placed on software

meant that the first step in using a computer was to promise not to help your neighbor. A cooperating community was forbidden. The rule made by the owners of proprietary software was, ‘If you share with your neighbor, you are a pirate. If you want any changes, beg us to make them.’⁸

Stallman found such restrictions unacceptable. He could not continue working in an environment where he would be forced to deprive others of useful information, nor could he stand by and watch as the effects of proprietary software divided his hacker community.

Thus, in 1982, Stallman began a project that would attempt to build, from scratch, an entire operating system, as well as all of the useful programs one would require, with the intention that they would be made available for free and without restriction. He decided to base this project off the popular Unix operating system, which was designed by AT&T’s Bell Labs and had been distributed under a loose academic license (AT&T then was only allowed to sell telephone service, and was using the universities to develop software to run its phone switches).⁹ The primary advantage of Unix was that it was designed in such a way that it could be made to work on many different types of computers (earlier operating systems were programmed specifically for one type of machine). Stallman dubbed his project GNU, for “GNU’s Not Unix,” following a hacker tradition of recursive acronyms.¹⁰

Stallman left his job at MIT in 1984 to work on the GNU project. He supported himself partially by selling media containing the code to his popular EMACS text-editing program.¹¹ Although the program was freely distributable, it was more convenient for some to receive a tape from Stallman through the mail than attempt to copy the code over the fledgling networks of the early 1980’s. In 1985, he started the Free Software Foundation¹² (FSF), a non-profit organization to manage and support the development of free software. The term ‘free software’ is often misunderstood. Stallman clarifies its meaning by explaining that it refers to software that is ‘Free as in speech, not as in beer.’¹³ Thus, the term describes software that one is able to use freely, without limiting restrictions. There are many software programs that are available at no cost, such as freeware or shareware, yet they do not provide the same freedoms that ‘free software’ provides. Stallman states that a piece of software can be called ‘free software’ if a user has the freedom to use it for any purpose, to modify it, and to redistribute either copies of modified versions, either without cost or for a fee.¹⁴

Also in 1985, Stallman authored the “GNU Manifesto,”¹⁵ which called for other hackers to join the project while championing the benefits of sharing source code. While the GNU project still has not completed its base operating system, it rapidly developed all the necessary programs and utilities needed to use an operating system effectively. Because these programs were compatible with other types of Unix (of which there were many), and were designed to run easily on many different types of computers, they quickly became popular, and gathered support for free software. Many exceeded the quality of proprietary programs that came with the various other Unixes, while others provided new services that simply did not exist in closed source software.

In 1988, Stallman and the FSF created the GNU General Public License¹⁶ (GPL). This license, under which all software produced by the GNU project was placed (as well as many other free software projects), protected the freedoms of free software through copyright law. Its only restriction is that if one changes or uses any portion of the source code of a GPL-protected program, and then redistributes the resulting program in any way, then that program must be released under the GPL as well (thereby requiring that its source code must be made available). Thus, anyone can download the source code to any 'GPL’d' program, make some modifications to it, and sell it as their own product, but only if they release their source code under the GPL as well. This ensures that any improvements or alterations made to GPL software are made publicly available to the community that produced the software in the first place. The GPL “uses copyright law, but flips it over to serve the opposite of its usual purpose: instead of a means of privatizing software, it becomes a means of keeping software free.”¹⁷

UC Berkeley and BSD

Flash back to 1977. The University of California, Berkeley’s Computer Science Research Group had been helping to develop AT&T’s Unix for years. They began to distribute free copies of their work, with source code, packaged as the “Berkeley Software Distribution,” or BSD. After subsequent releases, BSD became one of the most popular operating systems available, and continued on a separate development path from AT&T’s Unix offering. In 1984, as AT&T was broken up by the antitrust trials, they began to view their Unix software as a profit-generator. Thus, they required all parties with access to its source code to sign non-disclosure agreements.¹⁸ Additionally, since BSD was based on the AT&T source code, everyone who wished to run it also had to purchase a source code license from AT&T.¹⁹

Members of the Berkeley group began to feel used. AT&T’s intellectual property rights were restricting their work.²⁰ They began to separate out the code they had developed on their own, and released it separately in 1989. The license this code was released under was extremely loose: it only required that the license remain intact, and that any released product based on the BSD code must make some mention of that fact in its documentation.²¹ There was no requirement to release source code, as exists in the GPL.

The initial freely-distributable release did not contain enough code to run an operating system, and thus was known as ‘Networking Release 1.” However, they did include important bits such as BSD’s implementation of TCP/IP (Transmission Control Protocol/Internet Protocol), the networking protocol used by the Internet. BSD was the first operating system to implement TCP/IP, and many other systems’ use of TCP/IP has been heavily based off the open source release of the BSD code (including Microsoft’s). ²²

The Berkeley group continued to identify the code in their BSD OS release that they had developed in collaboration with AT&T, and replaced it with code written by programmers on the Internet who had never seen the original code. By mid-1991, they had replaced all the necessary files except for six, and released this package as ‘Networking Release 2.” Within 6 months, users had written replacements for the six remaining files, and BSD was distributed as a fully free, open-source operating system.

After the initial release of Networking Release 2, a company called Berkeley Software Design Incorporated (BSDI) began developing their own replacements for the six missing files. They began selling their version of Unix in early 1992 for $995, which they advertised as a 99% discount over AT&T’s system.²³ Despite the fact that there were at least two other Unix derivatives based on the BSD code base that were available for free, BSDI was sued by Unix Systems Laboratories (USL), the subsidiary of AT&T that developed and sold Unix, shortly after they began their advertising campaign.²⁴ USL was attempting to get an injunction against the sale of BSDI’s product, claiming that it contained USL code and trade secrets.

BSDI explained that, save for the six additional files, they were simply using the code they had received from the University of California. USL then re-filed the suit against both BSDI and the University of California. USL’s case began to falter as the Berkeley group demonstrated that their code had been developed independently from AT&T’s. In fact, they even managed to show that AT&T had removed the copyright notices from some of the BSD code and incorporated it into their Unix, thereby violating one of the loosest software licenses in existence.²⁵ The lawsuit continued for over a year, but by that point, AT&T had sold USL to Novell, who agreed to settle out-of-court. In the end, three out of 18,000 files were removed from BSD’s code²⁶, and BSD continued to develop and distribute their software, which has split into three major free software projects: NetBSD²⁷, which supports as many types of computers as possible, FreeBSD²⁸, which concentrates on Intel-based computers, and OpenBSD²⁹, which focuses on security.

Linus Torvalds and Linux

In 1991, around the same time that BSD’s Networking Release 2 was released, a 21-year-old university student in Finland was working on his own free operating system. Linus Torvalds began working on Linux as an experiment to learn more about operating systems and the hardware of an Intel-based machine. It started as being based on Minix, a version of Unix intended for academic purposes that one could purchase the source code to for $150.

Torvalds announced his project on a computing newsgroup in mid-1991 with an email that began as follows:

“Hello everybody out there using minix -

I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.”³⁰

Obviously not thinking much of it at first, Torvalds quickly attracted interest in his project, and more and more people began working on Linux. Participation grew quickly, partially due to the its ability to run on cheap Intel-based computers, and partially due to Linus' charisma. By early 1992, it had soon become a useful, independent operating system, and Linus released it under the GPL.

What had started as an individual hobbyist project rapidly attracted hundreds of developers and thousands of users. While initially limited to only running on Intel-based hardware, hackers from around the world wrote the code to enable Linux to run on numerous types of computers.

What is particularly interesting about Linux is that, up until that point, even free software projects were primarily developed by small, tightly-knit groups of developers who would only make code available when it was deemed ‘stable.’ Linux, on the other hand, was developed almost from the beginning by a large, loose collection of developers collaborating on the Internet, who shared and released code almost constantly. As self-described hacker/anthropologist Eric S. Raymond points out in his seminal work on open source software development, The Cathedral and the Bazaar, this method turned out to work extremely well. ³¹

In the strict sense, Linux refers only to the Linux kernel – the very base of an operating system. In order to have a useful system, one requires many other utilities and programs. Many of these programs were provided by the GNU project, while others are the result of independent developers. (Because of Linux’s extensive use of GNU software, Stallman insists that the operating system be referred to as GNU/Linux, to give credit to his project.³²) When one downloads Linux, one usually downloads a group of these programs in addition to the Linux kernel. This is known as a ‘distribution’. Not only do distributions provide a certain cluster of useful applications, but also they often have their own installation process, and method for installing and removing applications.

After only two years, groups such as Red Hat, Debian, and SuSE began sprouting up to give away – and sometimes sell – their own Linux distributions. New features were added to Linux, such as SAMBA (which was partially developed by WCP graduate John Blair), which allows Linux to transparently share files and printers with Microsoft-based networks, and clustering technology, which combines several computers to act as one (thus, one can have a very cheap, very powerful computer by combining many PC’s with Linux.) 49 of the world’s top 500 supercomputers are in fact clusters running the open source ‘Beowulf’³³ clustering software on top of Linux.³⁴

These technological advances, combined with Linux’s enthusiastic user community, resulted in phenomenal growth. Many network administrators and information technology workers began to sneak Linux into their offices, finding the free software much more reliable and easier to administer than the proprietary solutions favored by management.

Today, Linux runs on at least 15 different types of computers, from IBM mainframes, to old Macintoshes, to Palm Pilots, and has a user base that runs well over ten million, and it is continuing to grow.³⁵

Other Successful Free Software Projects

Some free software applications have become even more successful than Linux and the BSDs. One of the most outstanding free software projects is the Apache web server.³⁶ Begun in 1995, Apache quickly rose to become the most popular server software on the web (a web server is the software that sends web pages to a browser). According to the most recent survey, it is currently running on over 21 million machines on the Internet, capturing 56% of the market share (versus Microsoft Internet Information Server’s 32%). When only active websites are considered, Apache’s dominance rises to 64%, compared to Microsoft’s 27%. ³⁷

Sendmail³⁸ is another extremely successful free software project. A 2001 survey found that Sendmail, an open source email server, is the most common email server on the Internet, at 47% of all publicly available email servers. In contrast, Microsoft’s Exchange makes up only 18% of the Internet email market.³⁹

PHP⁴⁰ (a recursive acronym for PHP: Hypertext Preprocessor) is a free software programming language used to create dynamic web pages. It has become the world’s most popular server-side scripting program, running on over 9 million websites – 24% of all websites. PHP usage has grown 6.5% each month for the past two years.

Although it is not yet as popular as the projects mentioned above, an extremely promising free software project on the desktop is OpenOffice.org.⁴¹ OpenOffice.org is a fully functioning open source office suite, including a word processor, spreadsheet, presentation manager, and drawing tool. Sun Microsystems released the source code to its StarOffice suite to create the OpenOffice.org project in July 2000. The project aims to reach parity with Microsoft Office, and recently had its 1.0 release in May 2002. It should be noted that this senior project was composed entirely in OpenOffice.org.

The Acceptance of Free Software by the Mainstream

As free software continued its rise within the computing community into the mid-90s, several key players in the movement began to worry that it was in need of a face-lift. Free software was seen by the conservative business community to be, at best, anti-business, and at worst, communistic. Such ideas arose mostly out of what hackers refer to as FUD (Fear, Uncertainty, and Doubt) regarding the changes that were taking place within the software industry. Nonetheless, it was felt by some that in order for the ideas of free software to truly take off within the marketplace, a public relations campaign was in order.

Thus, in the spring of 1997, a group of free software leaders, including Eric S. Raymond and publisher Tim O’Reilly got together to discuss possible solutions.⁴² In addition to coming up with rebuttals and answers to counter many of the arguments and concerns often expressed by the corporate sector regarding free software, the meeting also resulted in a new term for free software: “Open Source.” Along with the term, they established the criteria for a piece of software to be considered ‘open source.’ The ‘Open Source Definition’⁴³ allows licenses much more loosely than the GPL, specifically in allowing proprietary use of open-source code. The Open Source Definition, like the GPL, states that software must be released with source code and without restriction. However, where the GPL requires that any derivative work or modification of GPL code must be released as GPL as well, the Open Source Definition includes licenses that allow redistribution without source, such as the BSD license. The group also set up an organization to manage the certification of various software projects, known as the Open Source Initiative.⁴⁴

Stallman disapproves of the use of this term. While he considers software that meets the Open Source Definition to be free software, he disagrees with the use of the term ‘open source’ as opposed to ‘free software’ on the grounds that it de-emphasizes the aspect of freedom involved. ⁴⁵

In 1997, Eric S. Raymond wrote an analysis of free/open source software development entitled The Cathedral and the Bazaar. This document provided a logical explanation for how the decentralized, community-based development of open source software worked so effectively, and extolled the various benefits of this type of development, as well as free software in general. Several months after its publication, in January 1998, Netscape Corporation announced that it would be releasing its popular web browser suite, Netscape Communicator, as open source. Raymond’s publication was cited as one of the primary motivators in this decision.⁴⁶

That announcement is sometimes referred to as the “shot heard ‘round the world.’”⁴⁷ For a corporation as high profile as Netscape – whose browser was the web’s most popular in its early days (before it was beaten by Microsoft through what many believe were anti-competitive practices) – to release its proprietary product as open source at first seemed insane to many. Regardless, it introduced free software as a legitimate idea to the business community. The media began to publish story after story about this odd phenomenon, and soon the world knew about Linux. Though long in development, the open sourced web browser based on Netscape’s code, know as Mozilla,⁴⁸ recently released the first production version of their product in June 2002.

Open source software played a very important role in the technology market explosion of the late 90s. Rising dot-coms and technology companies seeking to stretch their venture funding as far as possible made extensive use of free software solutions. For example, I personally worked for a company that employed several open source applications, running on top of Linux, in the product they marketed (which, ironically, was intellectual property management software!). Without the availability of open source applications such as Perl, MySQL, Apache, CVS, and Linux, the company would have had to close its doors much sooner than it did.

In the years that followed, free software has gained more use, legitimacy, and acceptance. In December 2000, IBM announced that it would dedicate nearly $1 billion to open source development, advertising, and services.⁴⁹ IBM, Dell, and Compaq all sell servers running Linux. Oracle now supports a version of its industry-leading, proprietary database software that runs on Linux. Apple’s new OS X operating system consists of a proprietary front-end running on top of a modified, yet open source, version of BSD. Other major industry players which have either made commitments to free software include Sun Microsystems, Hewlett-Packard, AOL/Time Warner, Silicon Graphics, Motorola, Sharp Electronics, Amazon.com, and Yahoo.com.

Linux can be found at gas stations⁵⁰, it has been to the North Pole⁵¹, and has even traveled into space aboard the space shuttle.⁵² It has become a leader in the processing of computer-generated images – you can now find clusters of Linux boxes crunching numbers at Dreamworks SKG, Industrial Light and Magic, and Disney, and it has been essential in creating the special effects for big-budget movies such as Titanic, The Fellowship of the Ring, and Star Wars Episode I.

Perhaps the best indicator of this trend is the changing response of Microsoft, one of the largest holdouts of proprietary software, and perhaps the company with the most to lose by free software's success. For a long time, Microsoft simply refused to acknowledge the existence of free software, dismissing it as hobbyist, an irrelevant trend, and wholly incompatible with business needs. Then, in October 1998, several internal Microsoft documents were leaked onto the Internet. These memos, known as the 'Halloween Documents,' address Linux and free software as a serious threat to Microsoft’s business, and consider various strategies to combat it, and show that free software has the world’s most powerful technology company worried.⁵³ Since then, Microsoft has gone from merely spreading 'Fear, Uncertainty, and Doubt' concerning free software to addressing its strengths and weaknesses as a true business threat. It has launched ad campaigns against free software, has a web page that compares Linux to its Windows 2000 server software point by point, and has recently admitted that they have needed to change their business strategies to accommodate the competition generated by open source software.⁵⁴ Even more indicative of free software’s acceptance and popularity is Microsoft’s cynically named ‘shared source’ program, in which it shares small pieces of its source code with partner companies under heavily restrictive non-disclosure agreements.

While free software has been widely popular in server rooms for quite some time, only in the past few years has it gained support as a desktop operating system. Desktop window managers, such as the K Desktop Environment⁵⁵ (KDE) and GNOME⁵⁶ have made astounding advances in providing user-friendly graphical interfaces that surpass that of Microsoft’s Windows in terms of features and functionality. Additionally, a wide range of open source applications allow users to write documents, burn CDs, watch movies, send instant messages, and perform many of the other tasks a common desktop user would want to do – all cost-free. It is now possible to order new computers with Linux pre-installed from Walmart.com!

Free software has come a long way since its humble beginnings in BSD and the GNU project. Sourceforge.net⁵⁷, a website that hosts free software development projects, currently lists 27,057 projects under Open Source Initiative-approved licenses, and that number increases every day.⁵⁸ It is estimated that the use of Linux alone increases 200% each year.⁵⁹ In the next section, I examine what it is about free software that makes it so compelling.

III. The Success of Free Software

The Benefits of Free Software Development

Open source software tends to out-perform its proprietary counterparts in a variety of areas, qualitative arguments for freedom aside. When examining free software, one will find that it is usually more reliable, more secure, performs better, or provides more functionality than a comparable closed source product, and often excels in more than one of these areas – not to mention that free software is almost always a better value.

These benefits certainly do not occur because open source developers are paid better! Rather, it is the process of open source development that results in higher quality software. The differences between free software development and traditional closed source development are best explained by Eric Raymond, in his previously-mentioned The Cathedral and the Bazaar. In it he explains how the success of Linux made him reconsider his assumptions about software development:

Linux overturned much of what I thought I knew. I had been preaching the Unix gospel of small tools, rapid prototyping and evolutionary programming for years. But I also believed there was a certain critical complexity above which a more centralized, a priori approach was required. I believed that the most important software (operating systems and really large tools like the Emacs programming editor) needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time.

Linus Torvalds’s style of development – release early and often, delegate everything you can, be open to the point of promiscuity – came as a surprise. No quiet, reverent cathedral-building here – rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches (aptly symbolized by the Linux archive sites, who’d take submissions from anyone) out of which a coherent and stable system could seemingly emerge only by a succession of miracles.

The fact that this bazaar style seemed to work, and work well, came as a distinct shock. As I learned my way around, I worked hard not just at individual projects, but also at trying to understand why the Linux world not only didn’t fly apart in confusion but seemed to go from strength to strength at a speed barely imaginable to cathedral-builders.⁶⁰

A famous work in software engineering states that the more people you assign to an overdue project, the more overdue it will become, as the level of complexity between the developers increases. Written by Frederick P. Brooks in 1975, it reasons that the level of complexity, difficulty in communication, and the potential for bugs increase geometrically as programmers are added to a project.⁶¹ This idea is known as ‘Brook’s Law,’ and, of course, the existence of Linux tends to dispute it.

Linux, and many free software projects since it, are developed by varying numbers of people, in a relatively decentralized fashion, with the primary (and often only) means of communication being email. While it’s not exactly the case that it is a non-hierarchical development model, the hierarchies are much less strict than one might find in a traditional software shop, and are very much merit-based. In most larger projects, there is at least one person, possibly several people, who serve to coordinate and manage the development (such as Linux Torvalds, in the case of Linux), but due to the voluntary and open nature of open source development, they hold those positions entirely at the will of the other developers.

Raymond lists several reasons why this model is successful, and, based on his analysis, and my own experience with free software projects, I put forth the following two primary benefits of the open source development process:

Development is consumer-driven, not profit-driven

This point cannot be overstated. Because the developers of a program are often the ones who use the program the most, the features and issues they address are directly driven by consumer concerns. This practice is augmented by the fact that non-developing users have direct access to the programmers themselves when making feature requests, identifying problems, and providing feedback.

Because users have access to the source code, it is common that they will add a feature or fix a problem themselves, then contribute the change back to the primary development group. This is often how individuals become involved in open source projects – a practice Raymond identifies as “scratching a personal itch.”⁶²

Another custom related to this point is what Raymond identifies as “Release early, release often.”⁶³ Open source developers make their code available in good working order through ‘development releases’ - testing versions – very often. This allows users to try out the software and identify any new issues that may have arisen, as well as test the latest features, keeping interest in the project high. For example, the Mozilla project (the open source web browser) allows interested users to download a new test version of their open source web browser every night.

Another advantage to frequent release cycles concerns security and bug fixes. It is well known that Microsoft will delay the announcement of security problems with their software, sometimes for months, until they have a fix ready. Often the announcement is timed to manage public relations. This is not the case in the open source community – major bugs and security problems are announced immediately, and in most cases, fixes are available within days, sometimes hours, of identification.

On the flip side of the ‘release often’ idea, most open source projects are never released as ‘stable’ or ‘production-ready’ until they have been thoroughly verified and tested. There are no sloppy rushes to meet production deadlines, no premature shipments to coincide with TV spots.

An additional burden of profit-driven development usually not seen in free software is the forced upgrade. Much of Microsoft’s business model is based on the idea that consumers will be forced to continually purchase the latest and greatest operating system in order for their new programs to run. This proves not only costly, but can be quite confusing, as users must constantly reacquaint themselves with new systems every few years. In free software, developers go to great lengths to make software backwards compatible (new versions able to work with older versions), and to ensure that they are programming for the lowest common denominator. And, of course, when a new version does come out, it is available free of charge.

Probably one of the biggest causes for the high quality of open source software seems to be overlooked by Raymond. The developers of free software have direct control over their work, and therefore do not risk becoming alienated from their labor, as is often the case in hierarchical corporate environments. Free software hackers perform their tasks not out of material necessity, but out of internal motivation – because they enjoy solving problems, they feel empowered by the community, they wish to see better software, etc.

I once saw Linus Torvalds speak at a Linux Users Group meeting in San Francisco, at which he was asked about the technical performance of Sun’s proprietary Unix versus that of Linux in some particular area. The individual wanted to know if Linus felt that Linux performed better due to technical detail A or technical detail B. Linus responded, “Those other operating systems aren’t bad because of [technical detail A or technical detail B.] Those systems are bad because the people don’t care.”⁶⁴

“Given enough eyes, all bugs are shallow”⁶⁵

Another great benefit of the open source development model is that the number of people who are available to identify and correct bugs is only limited by the popularity of the project. In the closed source world, there are only as many debuggers as the company can afford to pay. It would be difficult for a traditional ‘cathedral-style’ development process to test its software as widely, in as many different environments, as is possible with the open source model. Although it is not uncommon for a project’s mailing list to receive an identified bug and its fix in the same email, Torvalds states that usually “somebody finds the problem, and somebody else understands it. And I’ll go on record as saying that finding it is the bigger challenge.”⁶⁶ With a wide user base of non-programmers testing the latest development releases, the challenge of locating these bugs is spread among many.

An important issue related to the idea of 'multiple eyes' in free software is security. Many critics point to the availability of source code as making open source software much less secure, since malevolent crackers can see exactly how the software operates in their search for security exploits. However, many in the security industry will tell you that 'security through obscurity' is no security at all. The alternative view is that, because of open source, more people who are interested in keeping the software secure can find the security exploits and fix them, whereas with closed source, the holes remain, they are just a little harder to find.

Free Software and the Marketplace

Good software development models and ideas of freedom aside, free software must still interact with the free market, and programmers still must get paid. Most free software developers are hobbyists. While they often feel very strongly about free software, they usually work on it in their spare time, while programming in closed source environments to pay the bills. Many are not professional developers at all, but network administrators or academics. Some do not even have 'tech-related' jobs.

Not all open source development is done for free. It is becoming more and more common for companies to pay programmers to work on open source software, as businesses begin to realize the potential of open source software. This may come as something of a surprise – why would a company pay someone to develop software that they cannot own?

Many companies benefit greatly from the development of free software, in a variety of ways. In most instances, programmers are not providing the company with a product so much as they are performing a service. This service provides a company with software that adds value to an additional product they sell. Even Stallman himself made money by selling his free EMACS text editor – by providing people the service of sending them a hard copy. As Peter Wayner explains in his book Free for All, “he decided that it wouldn’t be wrong to sell copies of software or even software services as long as you didn’t withhold the source code and stomp on anyone’s freedom to use the source code as they wished.” ⁶⁷

Red Hat,⁶⁸ a leading distribution of Linux, makes much of their revenue providing support and other service contracts to corporations and individuals running their popular release. They employ over 650 employees,⁶⁹ a significant number of whom are free software hackers, who have contributed extensively to 17 free software projects, including Apache, the Linux kernel, GNOME, and their widely used method of installing and managing programs, the Red Hat Package Manager. They have also developed source for at least 20 other projects.⁷⁰

Red Hat views its software distribution as a commodity product – the actual costs and benefits between the various distributions available are negligible.⁷¹ In order to gain the large share of the distribution market that they enjoy, they have had to focus on brand management. People perceive Red Hat Linux to be the highest quality and most convenient distribution available. The Red Hat brand is partially successful due to its considerable contributions to the free software community – people know that Red Hat has used its success to improve the community – and thus the employment of developers has the additional benefit of improving the quality of their brand.

Many trust the Red Hat brand so much that they “prefer to purchase ‘Official’ Red Hat Linux in a box for $50 when they could download it for free or buy unofficial CD-ROM copies of Red Hat for as little as $2.”⁷² By having a well-established brand, Red Hat can focus on selling that brand to new customers. “The challenge is to focus on market size, not market share. ... The more Linux users there are, the more potential customers Red Hat has for our [distribution].”⁷³ And, of course, the users who subscribe to Red Hat’s brand are more likely to purchase Red Hat’s support services.

IBM⁷⁴ primarily produces and sells servers, as well as various services associated with those servers. As open source server software has developed a large user base and good reputation, IBM has realized that, by bundling its hardware and services with free software, it can sell more servers. The software adds value to its hardware and services. Thus, by improving the software – making it more secure and robust – it can improve this value. Therefore, IBM currently employs over 100 developers who have contributed code to over 40 free software projects.⁷⁵

Besides IBM, many hardware companies have invested in free software. Major IT corporations don’t invest in projects simply because they appreciate the freedom-centered philosophies behind them. Rather, they do so because they see an opportunity for profit. One such opportunity lies in the idea that software programs – especially operating systems – are a complementary product to computer hardware; that is, when one purchases new computer hardware, it is often necessary to purchase software as well. The profit motivation comes from an economic theory that states, “All else being equal, demand for a product increases when the prices of its complements decrease.”⁷⁶

Therefore, by contributing to free software projects, IBM, Hewlett Packard, and the like can force software companies such as Microsoft to compete with free (as in beer) products, thereby driving down the price of software. With cheaper software, companies are more likely to purchase more hardware. The same is true of the various support services that these and other companies provide: if the price of web servers falls, additional web servers will be installed, and hence demand for web server support will increase.

It is, for the most part, agreed upon that free software development is rapidly altering the software industry, and the economics of the technology market in general; many go so far as to say it is a revolution.⁷⁷ Regardless of the terminology used, there is no question that the phenomenon of open source software is forcing many to reconsider common assumptions in regards to software and the market. However, one finds drastically different interpretations of free software, coming from different perspectives. The next section will present a survey of different analyses of free software, focusing on the various perspectives from which they are written.

IV. Perspectives on Free Software Development

Contending Interpretations

Free software as a social phenomenon is a highly complex occurrence, and its existence goes against many commonly held assumptions regarding motivation, social organization, and economics. Additionally, as free software has gained momentum and popularity and become a powerful force within the software industry, it has developed real-world political and economic effects with wide-reaching implications. With these ideas in mind, it is not surprising to find that there exist many different, sometimes opposing, explanations of this phenomenon.

Even those within the hacker community have drastically different interpretations of why open source exists and what it means. I have already briefly mentioned one of these debates, perhaps the strongest point of dispute within the community: is the purpose of developing open source software to create ‘free’ (as in speech) software, or is it simply a useful means for creating technologically ‘good’ software? Certainly Richard Stallman and the Free Software Foundation are proponents of the idea of free software as an exercise of rights, protecting the products of the hacker community from proprietary restrictions. It is this more political stance that often gets Stallman and his contemporaries labeled as ‘communistic’ and ‘anti-business’ (neither label holds true), and it was for these reasons that other members of the community formed the Open Source Initiative. As previously mentioned, the OSI was meant to give free software a face-lift of sorts, and to make it clear that large sections of the community accepted business-friendly, profit generating practices. The creators of the OSI realize that the FSF is not necessarily ‘anti-business,’ but they believed that the political ‘free as in freedom’ rhetoric was inhibiting free software’s acceptance in the business community. They believe that the software can stand on its’ own merits:

While [freedom and sharing-oriented arguments] are still beloved by a vocal minority in the open-source development community, experience ... has made it clear that they are unnecessary. An entirely sufficient case for open-source development rests on its engineering and economic outcomes – better quality, higher reliability, lower costs, and increased choice.⁷⁸

On the other hand, there are many who believe that there is much more at play than simply ‘good software,’ and that those who might make compromises in order to gain mainstream acceptance are selling the movement short on its potential. They argue that free software began when concerned individuals began to speak about freedom, and to stop doing so “leads to trouble. Our ability to meet the challenges and threats [to free software] depends on the will to stand firm for freedom.”⁷⁹ As one concerned hacker put it,

Stallman is right, though, we aren’t talking about freedom enough. Do people really spend their weekends helping annoying new people install free software because it has a more efficient development methodology? Of course not. If it were only about efficiency, hobbyists would volunteer to replace the old ballasts in companies’ fluorescent lights. It’s really about the freedom – not just an individual’s freedom to hack, but now, a company’s freedom to decide its own future, not be tied down by proprietary licenses and [non-disclosure agreements]. We don’t have to stop talking about freedom 'just to win over the suits [business leaders].' Suits need freedom too.⁸⁰

Of course, these quotations represent the extreme of the two positions, and even the extremes recognize that this issue should not – and does not – divide the community to the point that it loses sight of its common goal – to spread the use of free, open-sourced software.

This issue is only one of the most obvious of many differing interpretations, theories, and explanations related to open source software. By examining these various perspectives, we not only get a better understanding of the free software phenomenon, and how we have gotten to this point, but, as I will show in this section, differing assumptions concerning the nature of individuals and social institutions will lead us to vastly different conclusions. I have identified six articles that provide interesting and engaging explanations of free software development. I have grouped them by the differing perspectives from which they are written: Traditional Economic, Traditional Sociological, and Radical. Note that I in no way intend to imply that these are the only perspectives that can be found examining free software.

While examining these articles, one finds that some of the same questions emerge over and over. We can assume that their frequency suggests they are central to the explanation of free software. However, each perspective emphasizes different issues related to these questions, and each provides different answers. I have chosen four of these questions that appear most often, and especially highlight the various interpretations the three perspectives have to offer.

The first question deals with the motivations of individual free software developers: What are the factors that cause someone to invest great amounts of time and energy in participating in open source development?

The second question relates to the management of free software development. As explained previously, some of the larger free software projects, such as Mozilla and Linux, are extremely complex, and the independent developers sometimes number in the thousands. What sort of organizational structures and practices are needed to manage these projects?

The third question addresses the larger economic issues surrounding open source. As free software becomes more popular, it inevitably has an effect on the software industry, especially as it begins to compete directly with proprietary products. How does free software interact with the marketplace, and how is the proprietary software responding to open source?

The final question focuses on the future of the free software movement. As this type of software development continues, where is free software going, and what are its long-term implications?

Traditional Economic Perspective

Josh Lerner and Jean Tirole’s “The Simple Economics of Open Source” sets out to account for open source development within existing theoretical economic frameworks.

The Cathedral and The Bazaar, by Eric Steven Raymond, is an ethnographic account and economic analysis of the free software community from its most prominent self-described anthropologist and libertarian.

The final two articles are similar in that they attempt to explain the free software phenomenon primarily through the traditional rules of market economics. Because they both assume human beings as rational, self-interested, and autonomous, and because they focus on individual behavior as opposed to the larger social context, I place them in a traditional economic perspective.

Lerner and Tirole, in “The Simple Economics of Open Source,” begin to explain the open source developer’s motivations as follows: “A programmer participates in a project ... only if she derives a net benefit [which is] equal to the immediate payoff (current benefit minus current cost) plus the delayed payoff.”⁸¹ Immediate benefits and costs include monetary compensation (if it is a commercial project), “fixing a bug or customizing a program for her own benefit,”⁸² and the opportunity cost of time spent, meaning that the developer is unable to engage in other activity while working on this project.

Delayed rewards consist of the ‘career concern incentive,’ which “refers to future job offers, shares in commercial open source-based companies, or future access to venture capital,”⁸³ and the ‘ego gratification incentive,’ or peer recognition. These incentives are grouped together as the ‘signaling incentive.’ They then explain that, while commercial projects “have an edge on the current-compensation dimension,” open source projects, “may well lower the cost for the programmer, for two reasons.”⁸⁴ The ‘alumni effect’ results from the fact that open source software is often used at schools and university as a teaching tool, and thus programmers are often already familiar with it. Additionally, if working on the software brings about a private benefit for the developer, then, too, the cost of contribution may be lowered.

In open source development, the ‘signaling incentive’ is stronger than in traditional settings, for the following three reasons: Because of the open source code, it is easier to measure one’s performance by directly observing the quality of one’s work. The “open source programmer is her own boss and takes full responsibility for the success of a subproject.”⁸⁵ Finally, the “labor market is more fluid in an open source environment,”⁸⁶ allowing developers to easily switch from project to project as they see fit.

Raymond begins his explanation of motives by stating that the “Linux world behaves in many respects like a free market or an ecology, a collection of selfish agents attempting to maximize utility....”⁸⁷ The utility developers are maximizing “is not classically economic, but is the intangible reward of their own ego satisfaction and reputation among other hackers. (One may call their motivation ‘altruistic,’ but this ignores the fact that altruism is itself a form of ego satisfaction for the altruist).”⁸⁸ The reputation gained in the free software community “can spill over into the real world in economically significant ways. It can get you a better job offer, or a consulting contract, or a book deal.”⁸⁹

Raymond folds his reputation-based analysis into the notion of a gift culture. He argues that “human beings have an innate drive to compete for social status,”⁹⁰ and that “most ways humans have of organizing are adaptations to scarcity and want. Each way carries with it different ways of gaining social status.”⁹¹ In our exchange-based economy, “social status is primarily determined by having control of things ... to use or trade.”⁹² The gift culture, as opposed to other methods of organization, is an adaptation “not to scarcity but abundance.”⁹³ In gift cultures, social status is determined by what you give away.

Raymond proposes an additional model to explain motivation, which he labels the ‘craftsmanship model,’ which addresses the “pure artistic satisfaction of designing beautiful software and making it work.”⁹⁴ Yet he contends that these models are complementary – craftsmanship relies on reputation as a measurement of quality. Whether reputation is the developers’ primary motivation or not, the reputation given by the community will affect their behavior.

Lerner and Tirole’s analysis suggests that the most important aspect of a successful free software project’s organization is the presence of credible leadership. Heads of open source projects must provide a vision, ensure that the overall project is divided into smaller, independent tasks, attract other programmers, and “keep the project together”⁹⁵ (prevent it from forking⁹⁶ or being abandoned).

While in some projects there is an undisputed leader (such as Torvalds in the case of Linux), some are managed by committee through voting or consensus process. Lerner and Tirole deny the notion that “the unconstrained, quasi-anarchistic nature of the open source process leaves little scope for leadership.”⁹⁷ For example, a strong vision for a project “helps coordinate expectations,” while “acceptance by the leadership of a modification or addition provides somedelayed certification as to the quality of the [change] and its integration/compatibility with the overall project.”⁹⁸

A leader must win the trust of a project’s developers, by assuring them that “the leader’s objectives are sufficiently congruent with theirs and not polluted by ego-driven, commercial, or political biases.”⁹⁹ This trust is key in preventing the project from forking into separate endeavors. It is also necessary for successful leadership to ‘’clearly communicate its goals and evaluation procedures.”¹⁰⁰

Raymond explains that there are several stages of organization through which a free software project may advance. The simplest organizational model is the single owner/maintainer, wherein one person “makes all decisions and collects all credit and blame.”¹⁰¹ A larger project may employ “multiple co-maintainers working under a single ‘benevolent dictator’ who owns the project.”¹⁰² However, the ‘benevolent dictator’ does not “own his entire project unqualifiedly. Though he has the right to make binding decisions, he in effect trades away shares of the total reputation return in exchange for others’ work.”¹⁰³ Later, as even more contributors join a project, it may develop “two tiers of contributors: ordinary contributors and co-developers.”¹⁰⁴ This often takes the form of individuals claiming responsibility of sub-projects within the main project, or a specific task, such as the management of bugs. In this system, the project leader “is expected to consult with those co-developers on key decisions,”¹⁰⁵ especially when those decisions impact an area maintained by a co-developer. Some larger projects “turn the co-developers into a ‘voting committee’ “ or a “rotating dictatorship, in which control is occasionally passed from one member to another within a circle of senior co-developers.”¹⁰⁶

Lerner and Tirole discuss two primary reactions that commercial software corporations may employ in reaction to the successes of free software: they may try to “emulate some incentive features of open source processes in a distinctively closed source environment,” or they could attempt “to mix open and closed source processes to get the best of both worlds.”¹⁰⁷

Commercial software companies are not able to employ many of the benefits of open source, such as the previously mentioned ‘alumni effect,’ or the permitting of users to modify and customize code. However, it is possible to duplicate some of the signaling incentives found in free software. For example, they may list the developers who have worked on a particular program. Proprietary software companies may also promote “widespread code sharing within the company.”¹⁰⁸

Lerner and Tirole list several strategies by which a company might “capitalize on the open source movement.”¹⁰⁹ One such method is to provide “complementary services and products that are not supplied efficiently by the open source community.”¹¹⁰ In this case, the company may hire developers to work on open source. “Red Hat will make more money on support if Linux is successful.... Similarly, Sun may benefit if Microsoft’s position is weakened.”¹¹¹

Another strategy is to “take a more proactive role in the development of open source software.”¹¹² A company may release source code to a product while creating a governance structure for the process, thereby retaining some influence over the direction of development. There have also been efforts “to certify corporate open source development programs.”¹¹³ Lerner and Tirole suggest that it makes good sense to hire prominent open source developers when a company wants to benefit from open source, as the developers act as intermediaries that gain the trust of other members of the community.

They next discuss whether commercial activities can “pollute the open source process.”¹¹⁴ One way this might occur involves a “participant who builds a valuable module and then offers proprietary [programming interfaces] to which application developers start writing.”¹¹⁵ Another is that “the coexistence of commercial activities may alter the programmers’ incentives.”¹¹⁶ They use the analogy of academic research that is sometimes influenced by commercial interests as an example of this point. Developers may “be tempted to stop interacting and contributing freely if they have an idea for a module that might yield a huge commercial payoff. Too many programmers may start focusing on the commercial side, making the open source process less exciting.”¹¹⁷

Raymond begins his analysis of open source software and the software industry with a discussion of what he calls ‘The Manufacturing Delusion.’¹¹⁸ He argues that “most programmer-hours are spent ... writing and maintaining in-house code that has no sale value at all....”¹¹⁹ That is, most software developers are paid not to work on proprietary products to be sold, but rather to create or maintain specialized code that has value only to the organization that uses it; there is no sale value for a company’s internal expenditure report-generation routines, or the specific programs that display certain pieces of information from a database to their website. They are too specialized to be useful to other organizations. Raymond uses this point to claim that “software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry.”¹²⁰ He bolsters this argument by pointing out that “the manufacturing delusion encourages price structures that are pathologically out of line with the actual breakdown of development costs.”¹²¹ 75% of the average software product’s costs over its lifetime are in maintenance, debugging, and extensions. Thus, the “common price policy of charging a high fixed purchase price and relatively low or zero support fees is bound to lead to results that serve all parties poorly.”¹²²

Raymond suggests that we reject the manufacturing model and replace it with “a price structure founded on service contracts, subscription, and a continuing exchange of value between vendor and consumer.”¹²³ Free software has begun to force the market to adopt such a model, by exposing “what a relatively weak prop the sale value of the secret bits in closed-source software was all along.”¹²⁴

Raymond then points out that “only sale value is threatened by the shift from closed to open source; use value is not.”¹²⁵ He goes on to describe two business models that support funding of open source projects for their use value. One involves sharing the cost of developing a particular program among many parties; the other relies on preventing the risk of a program outlasting its original developers by spreading its maintenance among a community.

There are also several business models that can profit from indirect sales value related to open source software. One such model is the hardware vendor who release the source to software related to its hardware because the software is not its profit center. Some companies sell accessories for open source software; one such example is the book publisher O’Reilly which sells software reference manuals, and “hires and supports well known open source hackers ... as a way of building its reputation...”¹²⁶ Another model involves releasing a software product as open source, which creates a market position for services related to that product. The instance of Netscape describes a situation in which a software client was given away in the hopes that it would create a better market position for its server software. Yet another profit model describes selling software as a proprietary product, but after a certain period of time that product becomes open sourced, giving the company profits for its newest innovations, while passing the maintenance costs onto the community.¹²⁷

Lerner and Tirole identify three primary issues that should be observed as open source development continues. The first asks, “To what extent will reliance on breaking software projects into distinct modules serve to limit the effectiveness of open source?”¹²⁸ As previously described, many open source projects are broken up into smaller, modular components to make parallel development possible. The design principles of Unix augment this technique. However, “as new open source projects move beyond their Unix origins and encounter new programming challenges, the ability to break projects into distinct units will be less possible.”¹²⁹ However, they suggest that new developments in programming languages and computer science “have encouraged further modularization, and may facilitate future open source projects.”¹³⁰

The second question asks, “Can the management of open source projects accommodate the increasing number of contributors?” Currently, many open source projects receive a disproportionate number of contributions from a few developers, while most participants only make a few submissions. As these projects gain popularity and attract more contributors, it is possible that they will receive a large amount of low-quality submissions. The management of these contributions “is likely to be an increasingly onerous task, one that will swamp the efforts of a volunteer staff.”¹³¹ One solution is the model “being adapted by Sendmail, where professional employees of the for-profit firm manage the open source submissions.”¹³²

Finally, Tirole and Lerner ask, “To what extent do open source projects have a greater or shorter effective life span than traditional projects?”_¹³³ A common argument is that since free software source code “is publicly available, and at least some contributions will continue to be made, its software will have a longer duration.”¹³⁴ This is opposed to commercial software, which is often abandoned or no longer upgraded once the developer disappears or even if a replacement upgrade is introduced. However, “another argument is that the nature of incentives being offered open source developers ... might lead to a ‘too early’ abandonment of projects that experience a relative loss in popularity.”¹³⁵

Raymond’s future view of open source software focuses on the question “What will the world of software look like once the open-source transition is complete?”¹³⁶ He begins by dispelling the worry that “the transition to open source will abolish or devalue [programmers’] jobs.”¹³⁷ Again, “most developers’ salaries don’t depend on software sale value in the first place,” and “there will always be plenty of work and a healthy demand for people who can make computers do things.”¹³⁸

Raymond then shifts his focus to how various sectors of the software industry will respond to open source. Infrastructure products (the Internet, the Web, and low-level communications software) will become almost entirely open source, and maintained by consortia and for-profit service companies. Applications (word processors, video games, etc.) will tend to remain mostly closed. “There are some circumstances under which the use value of an undisclosed algorithm or technology will be high enough ... that consumers will continue to pay for closed software.”¹³⁹ Middleware (databases, development tools, etc.) “will be more mixed. Whether middleware categories tend to go closed or open seems likely to depend on the cost of failures, with higher cost creating market pressures for more openness.”¹⁴⁰

However, applications and middleware are not very stable categories; applications “tend to fall into middleware as standardized techniques develop and portions of the service are commoditized.”¹⁴¹ Middleware services “will in turn tend to fall into the open-source infrastructure.”¹⁴² Thus, “in a future that includes competition from open source, we can expect that the eventual destiny of any software technology will be to either die or become part of the open infrastructure itself.”¹⁴³ Raymond concludes that “the free market, in its widest libertarian sense including all un-coerced activity whether trade or gift, can produce perpetually increasing software wealth for everyone.”¹⁴⁴

Traditional Sociological Perspective

Steven Weber’s “The Political Economy of Open Source Software” addresses questions involving the motivation of individuals, the coordination of free software development, and the complexity of open source projects. He then steps through an explanation of free software that combines microfoundations, economic logic, and socio-political structure in which he argues that the most compelling aspect of, and biggest challenge to, open source development is the coordination of projects.

Ko Kuwabara, in “Linux: A Bazaar at the Edge of Chaos,” describes open source as a highly complex system which approaches chaos. He combines complexity theory with ideas from evolutionary biology to describe free software as an evolving system that employs self-organization to maintain order.

These articles are similar in that they place primary emphasis on the social structures surrounding open source development. The sociological perspective acknowledges that reality and perception exist within a social context, and that individuals are flexible beings subject to influence.

Kuwabara mentions several personal motivations influencing free software developers, suggesting that the “most obvious reason for anyone contributing to the Linux project is enjoyment. Programmers program because they enjoy programming; programming directly satisfies utility, and utility is its own reward.”¹⁴⁵ However, “enjoyment is an inadequate explanation by itself in that it fails to account for the norm of cooperation and the norm of ownership.”¹⁴⁶ Another commonly cited motivation is that individuals program free software as part of their primary job, either being explicitly employed to develop a free software project, such as a Red Hat employee, or, more commonly, in a situation where one’s everyday responsibilities require open source programming, such as a network administrator.

Kuwabara poses the notion of ‘anticipated reciprocity,’ in which one “contribute[s] valuable information to the group in the expectation that one will receive useful help and information in return.”¹⁴⁷ Additionally, the notion of reputation gain as a motive is brought up once again, explained in the context of gift economies: in a community driven by abundance, “the basis of social relations shift from dyadic exchange to gift giving in which social status is associated not with ‘what you control but [with] what you give away.’”¹⁴⁸ Yet, he identifies this as somewhat problematic due to the extreme difficulty in assessing “the net benefit of doing a certain task in terms of reputation.”¹⁴⁹ He proposes that the best explanation of motivation is the idea of ‘group efficacy,’ which he describes as the evolutionary process by which an actor contributes to a project if it appears successful or promising. An example is the frequent release cycles of free software projects: “frequent releases serve to stimulate and reward the contributors in the sight of their efforts realized in new kernel releases. The sense of efficacy is a function of their own satisfaction and peer approval.”¹⁵⁰

A final motivation Kuwabara identifies is that of identity – “the attachment to the [free software] community and the degree to which developers identify themselves with the culture of computer programmers.”¹⁵¹ He closes by stating that

the evolutionary model of group efficacy drastically alters the pattern of motivation suggested by rational-choice theory. For rational actors developing Linux is only a means to an end. ...Group efficacy means that the success of the project signals new hackers to join the project and old hackers to continue contributing. The hackers contribute because they are interested in the operating system for what it is, but they continue to contribute because the Linux project also affirms the value of intellectual freedom and the norm of sharing, which are reinforced in each individual by peer reputation.¹⁵²

In Weber’s “The Political Economy of Open Source,” he, too, identifies a form of internal motivation: “the fun, enjoyment, and artistry of solving interesting programming problems clearly motivates open source software developers.”¹⁵³ He adds that “choosing your own work reduces perceived drudgery.”¹⁵⁴ Also, we find reputation as a possible motivating factor in open source development in Weber’s work. He clarifies that reputation as motivation requires some sort of system in place to assure developers “that they will get appropriate credit for what they do.”¹⁵⁵ Programmers can use this reputation for later monetary gains, “in the form of job offers, privileged access to venture capital, etc.”¹⁵⁶ This practice will also encourage cooperation of talented programmers, “since the marginal payoff from hard work in a joint project is higher when your collaborators are as good or better than you are.”¹⁵⁷

However, Weber contends, “reputational concerns by themselves cannot explain successful collaboration.”¹⁵⁸ If reputation were the primary motivating factor, then we would see more examples of hackers competing amongst themselves for more reputation, either by challenging the leadership of existing project heads (such as Torvalds), or by splitting off to form their own projects which they could lead themselves. Because this sort of competition happens very rarely (“there are no significant examples of this kind of behavior in the Linux history”¹⁵⁹), there must be other factors at play. Weber identifies these as “strong elements of shared identity within the community of developers,”¹⁶⁰ the “set of roughly shared beliefs that make up an informal hacker culture.”¹⁶¹

Kuwabara’s explanation of the organizational processes that must occur in order to produce complex software projects draws largely from, of all places, evolutionary biology:

Coordination is hence a crucial element sustaining collective efforts, giving the Linux project its integrity that unfolds the seemingly chaotic yet infinitely creative processes of evolution. In particular, the issue of coordination highlights an important and intriguing aspect of evolution generally overlooked: self-organization.¹⁶²

Self-organization is the force that leads complex, evolutionary systems towards stability, through positive feedback loops that amplify certain conditions of the systems. Kuwabara argues that this principle manifests itself in the complex system of open source software development, “mak[ing] for a spontaneous order, self-imposed from the bottom up.”¹⁶³

Kuwabara extends his ideas of ‘group efficacy’ and reputation to describe a self-feeding cycle in which a developer is attracted to and contributes to a promising project, gaining a certain degree of reputation within that project’s community. This added reputation persuades the developer to stay involved with the project, while improving the overall quality of the project, drawing in more developers.

Reputation ... locks people into particular patterns of collaboration and interaction through reinforcement. ... Reputation opens new opportunities and reinforces existing patterns, which further consolidates reputation. And as one gains presence in the project, one is also fixed into new responsibilities as a maintainer.¹⁶⁴

He concludes, “without global control from the top, the Linux project has achieved a fine balance between evolution and self-organization, order and disorder.”¹⁶⁵

Weber’s explanation of free software’s organizational structure rests on the principles of maintaining coordination and managing complexity. Open source projects maintain coordination through a set of cultural norms. For instance, decision-making authority within a project is mandated by a norm suggesting that “the more an individual contributes to a project and takes responsibility for a piece of software, the more decision-making authority that individual is granted by the community.”¹⁶⁶ Disputes are resolved objectively, on the basis of the shared “general conception of technical rationality,” otherwise described as “let the code decide.”¹⁶⁷ This norm is exemplified, Weber argues, by the establishment of the Open Source Initiative, which establishes “a clear priority for pragmatic technical excellence over ideology or zealotry (more characteristic of the Free Software Foundation).”¹⁶⁸ There exist two primary mechanisms to sanction individuals who violate the norms of a project community: ‘Flaming,’ which is “’public’ condemnation (usually over email lists)” and ‘shunning,’ refusing to cooperate with [someone] after they have broken a norm.”¹⁶⁹

To manage the extreme complexity of software projects, Weber explains, open source developers employ ‘modular design’ of code, meaning “a large program works by calling in relatively small and relatively self-contained modules. Good design and engineering is about limiting the interdependencies and interactions between modules.”¹⁷⁰ This “limits the reverberations that might spread out from a code change,”¹⁷¹ and thus eases parallel development. Thus, the “organizational demands on the social/political structure”¹⁷² are reduced through engineering principles. He then brings up the idea of ‘institutional isomorphism,’ a sociological argument which states that “institutions that interface frequently and deeply with each other will tend to adopt similar organizational structures as a means of improving communication and reducing a broad range of transaction costs.”¹⁷³ Weber proposes that this idea applies to open source in its relationship to large commercial interests. Thus, many free software projects have adopted structures that “reduce the complexity of relationships between the open source process, and the increasing range of organizations that use open source software.”¹⁷⁴

Kuwabara has little to say on free software’s effects on the software industry. At most, he offers up New Class Theory, an idea rooted in Marxist thought which asserts that intellectuals (academics, engineers, managers, and other skilled professionals) form a new class which belongs to neither the owning nor the working class, “with distinct ideologies directly associated with their productive functions in society.”¹⁷⁵ “The New Class believes that science and technology, rather than profit, should be the basis of productivity,”¹⁷⁶ and resists forms of centralized control over the processes of production for the increase of productivity and quality (I discuss New Class Theory at greater length in Section V). Kuwabara links New Class Theory to the free software movement by identifying the hacker culture as a resistance against managerial control: “Hackers and programmers ... deeply resent the growing proprietary control that place legal restrictions in source codes and disrupt hacker communities through rigid division of labor and specialization under corporate management.”¹⁷⁷ He then poses that

in the software industry, the New Class ideology finds perhaps its purest expression in the GNU Public License.... Part legal documentation, part political manifesto, Copyleft formulates into concrete and binding terms the norm of cooperation in hacker communities that began to lose its ground against the growing tide of commercialism.

Weber’s statements on the economics of open source software focus on the notion of free software as a public good. There is no way for anyone to restrict access to free software, and thus it falls into the economic category of ‘non-excludability.’ Additionally, anyone may download free software “without decreasing the supply that remains for others to use,”¹⁷⁸ so it is des