the mit press perspectives on free and open source software jun 2005

Wolf 2 Understanding Free Software Developers: Findings from the FLOSS Study 23 Rishab Aiyer Ghosh 3 Economic Perspectives on Open Source 47 Josh Lerner and Jean Tirole II The Evaluation

TEAM LinG

The MIT Press

Cambridge, Massachusetts

London, England

All rights reserved No part of this book may be reproduced in any form by any electronic or mechanical means (including photocopying, recording, or informationstorage and retrieval) without permission in writing from the publisher.

MIT Press books may be purchased at special quantity discounts for business or salespromotional use For information, please e-mail special_sales@mitpress.mit.edu orwrite to Special Sales Department, The MIT Press, 5 Cambridge Center, Cambridge,

MA 02142

This book was set in Stone sans and Stone serif by SNP Best-set Typesetter Ltd., Hong Kong Printed and bound in the United States of America

Library of Congress Cataloging-in-Publication Data

Perspectives on free and open source software / edited by Joseph Feller [et al.]

p cm

Includes bibliographical references and index

ISBN 0-262-06246-1 (alk paper)

1 Shareware (Computer software) 2 Open source software 3 Computer software—Development I Feller, Joseph, 1972–

QA76.76.S46P47 2005

005.36—dc22

2004064954

Arís as Gaeilge: Buíochas mór le mo chlann, Máire, Pól agus Eimear Is mór agam an iarracht a rinne sibh ar mo shon.

BF

With heartfelt warmth, I dedicate this book to my wife, Jacqueline, and

my two sons, Derek and Zachery, who bring meaning to everything I do.SAH

To Shaheen, Doulat, and Sitarah, your love makes it all possible

A special note of thanks to Eric von Hippel for being a great mentor and

a true chum

KRL

Foreword by Michael Cusumano xi

Acknowledgments xv

Introduction xvii

by Joseph Feller, Brian Fitzgerald, Scott Hissam, and Karim R Lakhani

I Motivation in Free/Open Source Software Development 1

1 Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects 3

Karim R Lakhani and Robert G Wolf

2 Understanding Free Software Developers: Findings from the FLOSS Study 23

Rishab Aiyer Ghosh

3 Economic Perspectives on Open Source 47

Josh Lerner and Jean Tirole

II The Evaluation of Free/Open Source Software Development 79

4 Standing in Front of the Open Source Steamroller 81

Robert L Glass

5 Has Open Source Software a Future? 93

Brian Fitzgerald

6 Open Source Software Development: Future or Fad? 107

Srdjan Rusovan, Mark Lawford, and David Lorge Parnas

7 Attaining Robust Open Source Software 123

Peter G Neumann

8 Open and Closed Systems Are Equivalent (That Is, in an Ideal World) 127

Ross Anderson

9 Making Lightning Strike Twice 143

Charles B Weinstock and Scott A Hissam

III Free/Open Source Processes and Tools 161

10 Two Case Studies of Open Source Software Development: Apache and Mozilla 163

Audris Mockus, Roy T Fielding, and James D Herbsleb

11 Software Engineering Practices in the GNOME Project 211

IV Free/Open Source Software Economic and Business Models 265

14 Open Source Software Projects as “User Innovation Networks” 267

Eric von Hippel

15 An Analysis of Open Source Business Models 279

Sandeep Krishnamurthy

16 The Allocation of Software Development Resources in Open Source Production Mode 297

Jean-Michel Dalle and Paul A David

17 Shared Source: The Microsoft Perspective

Jason Matusow

V Law, Community, and Society

18 Open Code and Open Societies

20 Nonprofit Foundations and Their Role in Community-Firm Software Collaboration 393

Anna Maria Szczepanska, Magnus Bergquist, and Jan Ljungberg

23 Libre Software Policies at the European Level 447

As with other researchers and authors who study the software business and software engineering, I have had many opportunities to learn aboutfree and open source software (FOSS) There is a lot to know, and I am especially pleased to see this volume of essays from MIT Press because

it provides so much information—both quantitative and qualitative—

on so many aspects of the open source movement It will answer manyquestions as well as continue to inspire more research for years to come

The research in this book is authoritative and thoughtful and offerssomething for everyone For example, economists will want to know themotivations of people and companies (such as IBM or Hewlett Packard),who give freely of their time to create or improve a “public good.” Not sur-prisingly, the research indicates that many FOSS developers are motivatedboth by the creative challenge as well as self-interest, such as enhancingtheir reputations as programmers, and then take advantage of this effectwhen searching for jobs Because both for-profit and nonprofit organiza-tions pay many programmers to work on open source projects, we findthere is also some overlap between the free and open source and com-mercial software worlds

Management specialists will want to know if there are business modelsthat enable for-profit firms to take advantage of free or open source soft-ware We learn that there are several seemingly viable commercial oppor-tunities, even though open source, in many ways, is the ultimatecommoditization of at least some parts of the software products business.The major business opportunities seem to be the hybrid approaches thatmake money from selling services (such as for system installation and inte-gration, and technical support) and distributing convenient packages thatinclude both free and open source software as well as some commercialutilities or applications This is the strategy that Red Hat, the poster child

of commercial OSS companies, has followed, and it is finally makingmoney as a distributor and by servicing Linux users.

Social scientists are fascinated by the coordination mechanisms used inopen source projects and will learn a lot about how the process works.Computer scientists and software engineers, as well as IT managers, willwant to know if open source development methods produce better soft-ware than proprietary methods produce Most of the evidence in this booksuggests that the open source methods and tools resemble what we see inthe commercial sector and do not themselves result in higher quality There

is good, bad, and average code in all software products Not all open source

programmers write neat, elegant interfaces and modules, and then fully test as well as document their code Moreover, how many “eyeballs”actually view an average piece of open source code? Not as many as EricRaymond would have us believe!

care-After reading the diverse chapters in this book, I remain fascinated butstill skeptical about how important open source actually will be in the longrun and whether, as a movement, it is raising unwarranted excitementamong users as well as entrepreneurs and investors On the developmentside, I can sympathize with the frustration of programmers such as RichardStallman, Linus Torvalds, or Eric Raymond in not being able to improvecommercial software and thus determining to write better code that is freeand available Eric Raymond has famously described the open source style

of development as similar to a “bazaar,” in contrast to top-down, chical design philosophies similar to how the Europeans built cathedrals

hierar-in the middle ages

We also know from the history of the mainframe industry, UNIX, andgovernment-sponsored projects that much software has been a free “publicgood” since the 1950s and that open source-like collaboration has led tomany innovations and improvements in software products But, on thebusiness side, most companies operate to make money and need someguarantee that they can make a return on investment by protecting their

intellectual property To suggest that all software should be free and freely

available makes no sense On the other hand, most software requires aniterative style of development, and at least some software is well suited tobeing written by programmers for other programmers in an open sourcemode Increasing numbers of the rest of us can take advantage of thispublic good when “programmer products” like Linux, Apache, and SendMail become more widely used or easier to use

The conclusion I reach from reading this book is that the software world

is diverse as well as fascinating in its contrasts Most likely, software users

will continue to see a comingling of free, open source, and proprietary ware products for as far as the eye can see Open source will force somesoftware products companies to drop their prices or drop out of commer-cial viability, but other products and companies will appear The business

soft-of selling ssoft-oftware products will live on, along with free and open sourceprograms This is most likely how it will be, and it is how it should be.Michael Cusumano

Groton and Cambridge, Massachusetts

February 2005

We would like to express our sincere thanks to Bob Prior and to the wholeeditorial staff at The MIT Press, for their professionalism and supportthroughout the process We would also like to express our appreciation tothe many contributors in this volume This work would not have been pos-sible without their passion for scholarship and research.

Special thanks to Lorraine Morgan and Carol Ryan for their help withpreparing the manuscript

Most of all, we are grateful to the individuals, communities, and firmsthat constitute the free and open source software movements Their inno-vations have challenged our “common knowledge” of software engineer-ing, of organizations and organizing, of the software industry, and ofsoftware as a component of contemporary society

JF, BF, SAH, and KRL

Joseph Feller, Brian Fitzgerald, Scott Hissam, and Karim R Lakhani

What This Book Is About

Briefly stated, the terms “free software” and “open source software” refer

to software products distributed under terms that allow users to:

 Use the software

 Modify the software

 Redistribute the software

in any manner they see fit, without requiring that they pay the author(s)

of the software a royalty or fee for engaging in the listed activities Ingeneral, such terms of distribution also protect what the publishing worldcalls the “moral right” of the software’s author(s) to be identified as such.Products such as the GNU/Linux operating system, the Apache Web server,the Mozilla Web browser, the PHP programming language, and theOpenOffice productivity suite are all well-known examples of this kind ofsoftware

More detailed, formal definitions for the terms free and open source are

maintained—and vigilantly watch-dogged—by the Free Software tion (FSF)1and Open Source Initiative (OSI).2However, the definitions aresubstantively identical, and the decision to use one of these terms ratherthan the other is generally ideological, rather than functional; the FSFprefers the use of a term that explicitly refers to freedom, while the OSI

Founda-believes that the dual meaning of the English word “free” (gratis or tas) is confusing, and instead prefers the emphasis on the availability and

liber-modifiability of source code.3In Europe the French-English construct libre software has been widely adopted to unambiguously capture the connota-

tion intended by the FSF.4

Free and open source software (F/OSS), however, is more than a set ofterms of distribution F/OSS is also—or, perhaps, primarily—a collection of

tools and processes with which people create, exchange, and exploit software and knowledge in a manner which has been repeatedly called

“revolutionary.”

Revolutions are a lot like caterpillars—they don’t grow old Either theydie young, or they undergo metamorphosis into something quite differ-ent Successful caterpillars become butterflies and successful revolutionsreplace, or at least transform, the status quo What is the status of the F/OSSrevolution? Has it successfully transformed the software industry? Otherindustries? Governments and societies? Or, is the revolution still in

“chrysalis,” with the great change to come tomorrow? Or, has the tion already died young? Or is it, perhaps, doomed to do so?

revolu-In the broadest sense, this book was written to address these questions

Perspectives on Free and Open Source Software

“In the broadest sense” won’t get you very far, though, so we’ll be a bitmore precise The earliest research and analysis on F/OSS emerged fromwithin:

 The F/OSS community itself (including the writings of Richard M Stallman and Eric S Raymond)

 The technology press (for example Wired magazine, O’Reilly and Associates)

 The software engineering research community (for example the ACM andIEEE)

It didn’t take long, however, for a substantial and well-rounded literature

to emerge—one addressing F/OSS as not only a software engineering nomenon, but as psychological, philosophical, social, cultural, political,economic, and managerial phenomena as well The bibliography of thisbook5is testament to the variety and richness of this scholarship

phe-We wanted this book to bring together, under one roof, provocative and exemplary research and thinking from people within a number of different academic disciplines and industrial contexts Specifically, we’vegathered together work from many of the leading F/OSS researchers and analysts and organized them into five key “perspectives” on the topic.These parts are:

Part I Motivation in Free/Open Source Software Development

Part II The Evaluation of Free/Open Source Software DevelopmentPart III Free/Open Source Software Processes and Tools

Part IV Free/Open Source Software Economic and Business Models

Part V Law, Community and Society

Next, we describe each of these parts, offering short summaries of the ters and suggesting key questions that the reader might bear in mind.

chap-Part I: Motivation in Free/Open Source Software Development

Many first-time observers of the F/OSS phenomenon are startled by thesimple fact that large numbers of highly skilled software developers (andusers) dedicate tremendous amounts of time and effort to the creation,expansion, and ongoing maintenance of “free” products and services This

seemingly irrational behavior has captured the attention of reflective F/OSS

community participants and observers

The three chapters in Part I seek to better describe and understand themotivations of individuals who participate in F/OSS activities

Lakhani and Wolf (chapter 1) report that the largest and most cant determinant of effort (hours/week) expended on a project was an individual sense of creativity felt by the developer They surveyed 684developers in 287 F/OSS projects on SourceForge.net and found that morethan 60 percent rated their participation in the projects as the most (orequivalent to the most) creative experience in their lives Respondentsexpressed a diverse range of motivations to participate, with 58 percent ofthem noting user need for software (work and non-work-related) as beingimportant Intellectual stimulation while coding (having fun), improvingprogramming skills, and an ideological belief that software should befree/open were also important reasons for participating in a F/OSS project.The authors’ analysis of the data shows four distinct clusters (approxi-mately equal in size) of response types:

signifi-1 Those that expressed enjoyment and learning as primary motivators

2 Those that simply need the code to satisfy non-work-related user needs

3 Those that have work-related needs and career concerns

4 Those that feel an obligation to the community and believe that ware should be free/open

soft-These findings indicate an inherent source of strength within the F/OSScommunity By allowing individuals with multiple motivation types tocoexist and collaborate, the F/OSS community can and does attract a widerange of participants Individuals can join for their own idiosyncraticreasons, and the F/OSS community does not have to be overly concernedabout matching motivations to incentives

Ghosh (chapter 2) presents a study conducted for the European Union

of more than 2,700 F/OSS developers, and reports that more than 53

percent of the respondents indicated “social” motivations to join and tinue in the community The single most important motivation was “tolearn and develop new skills.” About 31 percent of the respondents notedcareer and monetary concerns, 13 percent indicated political motivations,and 3 percent had product requirements Contrary to many altruism-basedexplanations of participation, Ghosh reports that 55 percent of respon-dents note “selfish” reasons to participate; that is, they state that they take in more than they contribute Interestingly, he finds no difference

con-in participation levels con-in projects between those that are motivated

by social concerns and those that are motivated by career/monetary concerns

Ghosh’s study also showed that a majority of the developers are male,and that more than 60 percent are under age 26 Surprisingly (given thenerdish stereotypes prevalent in the mainstream view of F/OSS develop-ers), more than 58 percent of the developers indicated having “significantother” partners with a large fraction (40 percent) living with their partners.About 17 percent of the respondents also indicated having at least onechild

Finally, chapter 3 presents a modified version of Lerner and Tirole’s 2002

Journal of Industrial Economics paper, “Some Simple Economics of Open

Source,” one of the most widely cited papers in the F/OSS research ture Lerner and Tirole employ a simple economic rationale of cost andbenefit in explaining why developers choose to participate in F/OSS pro-jects As long as benefits exceed costs, it makes rational economic sense for

litera-a developer to plitera-articiplitera-ate in litera-a project Costs to the developers litera-are definedmainly as opportunity costs in time and effort spent participating in cre-ating a product where they do not get a direct monetary reward for theirparticipation Additional costs are also borne by organizations where thesedevelopers work if they are contributing to F/OSS projects during workhours

Lerner and Tirole propose that the net benefit of participation consists

of immediate and delayed payoffs Immediate payoffs for F/OSS tion can include meeting user needs for particular software (where work-ing on the project actually improves performance) and the enjoymentobtained by working on a “cool” project Delayed benefits to participationinclude career advancement and ego gratification Participants are able toindicate to potential employers their superior programming skills andtalents by contributing code to projects where their performance can bemonitored by any interested observer Developers may also care about theirreputation within the software community, and thus contribute code to

participa-earn respect In either case, delayed payoffs are a type of signaling tive for potential and actual contributors to F/OSS projects.

incen-Part II: The Evaluation of Free/Open Source Software Development

Part I asked “Why do they do it?”; Part II asks “Was it worth it?” In thissection, we seek to address a wide range of issues related to evaluating thequality—security, reliability, maintainability, and so on—of both the F/OSSprocess and its products Both pro- and anti-F/OSS rhetoric has too oftenbeen characterized by grandstanding and FUD6flinging We are confident,then, that the chapters in this section meet some very real needs in boththe academic and practitioner communities for objective, empiricallygrounded assessment

Glass takes up this theme (the need for objectivity and sobriety) inchapter 4 He positions himself (with great ease and familiarity, it wouldseem) in front of what he calls the “steamroller” of unexamined hype.Glass raises a wide range of claims about F/OSS, regarding the talent ofF/OSS community members, the security and reliability of the software,the sustainability of F/OSS economic and business models, amongst otherissues It is a provocative chapter, and we began Part II with it knowing itwould wake you up and sharpen your wits While you might not agreewith all of Glass’s arguments, his one overarching claim is irrefutable: if

we are to understand and benefit from the F/OSS phenomenon, we cannot

do so without robust research and hard evidence

Fitzgerald (chapter 5), while not quite in front of the steamroller, is atleast on the construction site Drawing on a wide range of research andF/OSS writings, Fitzgerald articulates a number of what he calls “problem-atic issues,” arising from software engineering, business, and socioculturalperspectives These issues include the scarcity of developer talent (ques-tions of motivation aside), the potentially negative effects of the modu-larity that characterizes many F/OSS products, the problems with “porting”the F/OSS process into sector-knowledge-intensive vertical softwaredomains, and the churn caused by changing project (or even movement)leadership

Rusovan, Lawford, and Parnas (chapter 6) change our tack slightly,moving away from the broader and more discursive tone of chapters 4 and

5 Instead, they focus on a single, concrete example, the findings fromapplying experimental software inspection techniques (Parnas 1994b) to aparticular part of the TCP/IP implementation in GNU/Linux Althoughthey caution against resting an evaluation of the F/OSS process on a single

investigation, they do assert that the Linux ARP code was revealed to be

“poorly documented,” the interfaces “complex,” and the module lessly reliant on “what should be internal details of other modules.” Theirstudy points importantly to the need for elegant design and effective doc-umentation in all software, even in the wilds of the “bazaar.”

need-Neumann (chapter 7) in many ways echoes the implied challenges ofthe previous chapter—arguing that F/OSS is not inherently “better” thanproprietary software, but that it has the potential to be He points to, andbriefly summarizes, the dialog that emerged from the 2000 IEEE Sympo-sium on Security and Privacy, and concludes that F/OSS presents us withthe opportunity to learn from mistakes which we should have learned fromyears ago

Anderson (chapter 8) elaborates considerably on the issues raised byNeumann Anderson walks the reader through the logic and formulaewhich demonstrate that releasing a system as F/OSS (thus opening thesource code to public scrutiny) enables an attacker to discover vulnerabil-ities more quickly, but it helps the defenders exactly as much He goes on

to elaborate on the various, specific situations that may cause a break inthe potential symmetry between proprietary and F/OSS products Thebalance “can be pushed one way or another by many things,” he argues,and it is in these practical deviations from the ideal that “the interestingquestions lie.”

Finally, Weinstock and Hissam (chapter 9) address a wide range of ceptions and “myths” related to the F/OSS phenomenon, and present datagathered in five case studies: the AllCommerce Web store in a box, theApache HTTP server, the Enhydra application server, NAIS (a NASA-operated Web site that switched from Oracle to MySQL), and Teardrop (asuccessful Internet attack affecting both F/OSS and proprietary systems).They conclude that F/OSS is a viable source of components from which tobuild systems, but such components should not be chosen over othersources simply because the software is free/open source They cautionadopters not to embrace F/OSS blindly, but to carefully measure the realcosts and benefits involved

per-Part III: Free/Open Source Software Processes and Tools

Software engineering (SE) is a very young field of study The first computerscience department (in the United States) was established in just 1962 (Rice and Rosen 2002) and it wasn’t until after a NATO conference on the

“software crisis” in 1968 that the term “software engineering” came into

common use (Naur and Randall 1969; Bauer 1972), and the first degreeprogram for software engineers in the United States wasn’t establisheduntil 1978 at Texas Christian University.

Software engineering is more than just “coding,” it is applying “a tematic, disciplined, quantifiable approach to the development, operation,and maintenance of software” (IEEE 1990); it is also the engineering ofsoftware to meet some goal, and to see that the constructed software operates over time and that it is maintained during its expected life.7Such definitions of software engineering have led the way to a plethora

sys-of processes, paradigms, techniques, and methodologies, all with the goal

of helping to make the process of engineering correct software repeatableand addressing the concerns raised at the 1968 NATO conference on the

“software crisis,” where it was recognized that software was routinely late,over budget, and simply wrong To enumerate a list of such processes, paradigms, techniques, and methodologies here would be too arduous, but for the most part it, is generally accepted that the construction or engineering of software involves:

which has been tested throughout human civilization Following such law,

if there is no “need,” then there is no one to compensate the craftsmanfor their product, and hence no product As such, nearly all definedprocesses for software engineering include some role for the end-user ordefining-user in a software engineering process (such as requirements engineering (IEEE 1990) or “use cases” and “actors” in the Rational UnifiedProcess (Jacobson, Booch, and Rumbaugh 1999)) Further, software engi-neering is concerned with the principles behind effectively organizing the team of engineers that craft the software, and also with how that crafts-manship is accomplished, in relation to:

 Designing the software (its architecture, modules, and interactions)

 Programming, or coding, the designed software

 Testing the software against design and need

 Documenting that which is designed, programmed, and tested

 Managing those that design, program, test, and document

Through the short history of rationalizing the process by which softwareengineering is, or should be, accomplished, the members of the SE com-munity have reached a fairly common understanding of what softwareengineering is, and how software engineering should be done It is theapparent departure of free and open source software (F/OSS) from thisunderstanding (or belief in that understanding), combined with thesuccess (or perceived success) of many F/OSS projects, that has attractedthe attention of many in the research community In this section, anumber of authors have been selected to bring to the foreground specificobservations from various F/OSS projects.

Mockus, Fielding, and Herbsleb (chapter 10) embarked on an empiricalstudy by examining data from two major F/OSS projects (the Apache HTTPserver and Mozilla) to investigate the capacity of F/OSS development prac-tices to compete and/or displace traditional commercial developmentmethods.8German (chapter 11) proposes that the actual design of the soft-ware (its architecture) is one organizing principle behind the success of theGNOME project, in that it supports open and distributed software engi-neering practices to be employed by a large number of geographically dis-persed code contributors German then corroborates those practices withempirical evidence from the records available for the project to measurethe efficacy of those practices

Following this, Jørgensen (chapter 12) traces the development cycle ofreleases of the FreeBSD operating system and presents the results of asurvey of FreeBSD software developers, which was conducted to under-stand the advantages and disadvantages of the software engineering prac-tices used by FreeBSD The conclusions gleaned from his observations

interestingly suggest that a strong project leader is not necessarily needed

for a F/OSS project (such as FreeBSD) to be successful, although he poses instead that a well-defined software engineering process is, perhaps,critical

pro-Finally, Robbins (chapter 13) looks at the common practices used inF/OSS software development projects and at the tools available to supportmany aspects of the software engineering process He also points out wherethe F/OSS community is lacking in tool support for other software engi-neering processes

Part IV: Free/Open Source Software Economic and Business Models

Previously, we noted that F/OSS seems to challenge many accepted ware engineering norms It also appears to depart wildly from established

soft-software business models, and indeed F/OSS companies, and hybrid proprietary-F/OSS companies have had to create new value offers pre-dicated on software as a service, value of software use rather than value ofsoftware purchase, and so on In this part, we present four chapters exam-ining these new models and the changing relationships between customersand companies, and between companies and competitors.

In chapter 14, von Hippel argues that F/OSS offers extraordinary ples of the power of user innovation, independent of any manufacturingfirm He contends that markets characterized by user innovation “have agreat advantage over the manufacturer-centered innovation developmentsystems that have been the mainstay of commerce for hundreds of years”and discusses, convincingly, the parallels between the F/OSS communitiesand sporting communities also characterized by user innovation

exam-Krishnamurthy (chapter 15) discusses a series of business models thathave emerged in relationship to F/OSS He articulates the relationships thatexist between producers, distributors, third parties, and consumers, andexamines the impact of different licensing structures on these relation-ships In chapter 16, Dalle and David present a simulation structure used

to describe the decentralized, microlevel decisions that allocate ming resources both within and among F/OSS projects They comment onthe impact of reputation and community norms, and on the economicrationale for “early release” policies

program-Finally, Matusow (chapter 17) presents the perspective of what hasalways been the archetypal proprietary software company in the eye of theF/OSS community; namely, Microsoft In discussing the Shared Sourceprogram and related initiatives, this chapter provides interesting insightsinto the impact that F/OSS has had on the proprietary software industryand, perhaps, vice versa

Part V: Law, Community, and Society

It has been said that the average Navajo Indian family in 1950s Americaconsisted of a father, mother, two children, and three anthropologists.Many in the F/OSS community no doubt are starting to feel the same way,

as what began as a software topic has attracted the efforts of so manyresearchers from sociology, economics, management, psychology, publicpolicy, law, and many others The final section of the book presentsresearch focused on legal, cultural and social issues

Lessig (chapter 189) paints a broad picture and challenges us to thinkabout the social implications of F/OSS and the drivers behind the

phenomenon Starting with the collapse of the Berlin Wall, he considersthe move from closed to open societies He discusses the U.S model, wherethe move to having more property that is “perfectly protected” is equatedwith progress For Lessig, the issue is not whether the F/OSS developmentmodel produces more reliable and efficient software; rather it is about thefuture of an open society drawing on F/OSS principles Lessig focuses onthe enabling power of combining a “commons” phenomenon with theconcept of “property” to stimulate creativity, and also the critical differ-ences between ideas and “real” things Lessig also identifies the specificthreats to ideas posed in cyberspace, a space that is not inherently and per-petually free but can be captured and controlled Lessig offers a number ofcompelling examples of double standards where large corporate U.S inter-ests use the power of copyright law to prevent free communication of ideas,whereas they would presumably decry such curtailments on free commu-nication if they occurred in other parts of the world.

As Niels Bohr once remarked about quantum physics, if it doesn’t makeyou dizzy, then you don’t understand it, and the same may hold true forF/OSS licenses McGowan (chapter 19) deconstructs the legal issues sur-rounding F/OSS licensing He presents a primer the structure of F/OSSlicenses (“how they are designed to work”) and a discussion on copyright,

“copyleft,” contract law, and other issues that affect the enforceability oflicenses (“whether the licenses actually will work this way if tested”) Hisdiscussion of the Cyber Patrol hack and the Duke Nukem examples makethese complex issues very concrete and accessible

Moving from licensing to liability, O’Mahony (chapter 20) addresses thefact that as F/OSS moves more into the mainstream, the incorporation ofprojects as a mechanism to dilute the threat of individual legal liabilitybecomes central However, incorporation brings its own set of problems,

in that it imposes a degree of bureaucracy that is anathema to the hackerspirit of F/OSS O’Mahony deals directly with this conflict, an issue exac-erbated by the many F/OSS developers operating on a voluntary basis withnonstandard systems of rewards and sanctions O’Mahony identifies anumber of dilemmas that have emerged as F/OSS has become more popularand the original hacker ethos and values diluted She discusses the differ-ent incorporation models that have emerged historically and considerswhy they are inappropriate as organizational models for F/OSS projects.She then compares the foundations created by the Debian, Apache,GNOME, and the Linux Standards Base projects to study how differentproject “ecologies” approached the task of building a foundation at dif-ferent points in time

In chapter 21, Kelty elaborates on the oft-noted parallels between F/OSSand the scientific enterprise He considers the extent to which they aresimilar, and also the extent to which F/OSS has (or will) become a neces-sary enabler of science He focuses in particular on the social constitution

of science—the doing of science, the funding of science, and the ing of science—and draws parallels between the norms, practices, and arti-facts of science and F/OSS The chapter also considers issues related to law,thus resonating with McGowan’s chapter earlier in this section Likewise,his consideration of the threats facing science (and thus society) are rem-iniscent of those identified by Lessig

valu-The chapter by Szczepanska, Bergquist, and Ljungberg (22) illustrates themanner in which researchers can apply an ethnographic perspective to thestudy of F/OSS They characterize open source as a social movement, andtrace its origins in the literature on the emergence of the network society.They situate F/OSS as a countermovement in opposition to the mainstream

IT culture as exemplified by companies such as IBM and Microsoft Thus,their analysis resonates with the motivation factors identified earlier in thebook The authors use discourse analysis to analyze how the OSS commu-nity is molded and to help understand how collective identity is createdand communicated Understanding these discursive practices is especiallyimportant because of the decentralized and networked character of the OSSmovement The construction of the hacker is discussed, and the tensionsbetween the Free Software and Open Source movements are analyzed Theyfurther analyze “us” versus “them” constructions in the discourse of thecommunity, and the discursive strategies of the anti-OSS constituencies.Interestingly, the rhetoric of the “American Way” is used by both pro- andanti-F/OSS communities to support their arguments Finally, the authorsconsider the power relationships implied by a gift culture, and how thesestructure the work patterns of the F/OSS community

Aigrain (chapter 23) who has written much on F/OSS, has drawn on hismany years of experience with the European Commission to analyze their

policy in relation to F/OSS (He uses the term libre software.) The F/OSS

phe-nomenon is arguably better supported by public bodies in Europe than inthe United States, and European Commission support for F/OSS represents

a very significant factor in the future success of F/OSS initiatives Aigrain’sanalysis identifies choke-points in the EU funding bureaucracy that willdeter many F/OSS practitioners, as well as important policy issues of whichpotential F/OSS researchers in Europe need to be cognizant Aigrain suggests that, until recently, there was limited awareness of F/OSS issues

in the Commission, but that the growing disenchantment with the dissemination and exploitation of software research funded under the tra-ditional proprietary closed model was an important motivating factor Healso identifies as an important motivator the desire to establish an infor-mation society based on the open creation and exchange of informationand knowledge Other drivers include concerns about security, privacy, andoverreliance on a small number of monopoly suppliers of proprietary soft-ware Aigrain also acknowledges the prompting by advocacy groups such

as the Free Software Foundation Europe (FSFE) He insightfully notes needfor sensitive support for the F/OSS hacker community in managing thestatutory reporting requirements of a funding agency such as the EU.Despite this pragmatism, over the 1999–2002 period, only seven F/OSS pro-jects were approved, with a total budget of €5 million, representing only0.16 percent of the overall EU IST program funding for research Aigrainalso identifies some challenges for libre software, specifically in the areas

of physical computing and network infrastructure, the logical softwarelayer, and information and contents layer

Finally, in chapter 24, O’Reilly presents a thoughtful and informed essay

on F/OSS “as an expression of three deep, long-term trends”; namely, the “commoditization of software,” “network-enabled collaboration,” and

“software customizability (software as a service).” He argues that it is byexamining next-generation applications (the killer apps of the Internet,like Google) that “we can begin to understand the true long-term signifi-cance of the open source paradigm shift.” More to the point, O’Reillyasserts that if we are to benefit from “the revolution,” our understandingmust penetrate the “foreground elements of the free and open sourcemovements” and instead focus on its causes and consequences

Rigor and Relevance

We believe that academic research should be both scientifically rigorousand also highly relevant to real-life concerns We also believe that goodresearch answers questions, but great research creates new questions Thus

we conclude this introduction with some suggested questions for you tokeep in mind as you read the book We’ve grouped the question into threeaudience-specific lists for F/OSS project leaders and developers, managersand business professionals, and researchers and analysts We suspect most

of our readers, like most of our authors, wear more than one of these hats

F/OSS Project Leaders and Developers

 What are the major motivations for the developers in your project?

 Is your project culture such that it can accommodate developers with ferent motivations to participate? Or does your project risk crowding outdevelopers by having a culture that supports only a single motivation toparticipate?

dif- How can you manage both paid and volunteer contributors?

 On what basis do you welcome new members and how can you integratethem into your community?

 How can you best manage the “economy of talent” within your project?How can you settle disagreements and disputes? How can you avoid(destructive) churn?

 How can you manage software complexity? Integration? Testing?

 How can you break the “security symmetry” created by F/OSS?

 How are communication and collaboration facilitated in your project?

 How are changes from the F/OSS community accommodated?

 Can you automate day-to-day activities? What tools do you need to use?

 How can you leverage user innovation? How do you enable your users

to contribute to the project?

 Is your project part of a commercial business model/value web? Wheredoes your project fit in?

Managers and Business Professionals

 How can nonfinancial incentives be utilized within your firm’s softwareprojects to motivate internal developers?

 How can you spark the essence of creativity among your software developers?

 How do you build an open community of sharing and peer review withinyour firm?

 How does your firm interact with the wider F/OSS community? Whatthings do you need to be aware of so that you do not drive out F/OSS developers?

 How do you leverage the increasing numbers of F/OSS developers for thebenefit of your firm?

 What criteria are important in your evaluation of F/OSS products? Howdoes your procurement process need to change to adjust to F/OSS?

 How do your implementation and change management processes need

to change to adjust to F/OSS?

 In what way do your existing processes (or tools) have to adapt to supportF/OSS development?

 What criteria do you need to choose a F/OSS license? Or, if you areattempting to emulate the F/OSS process without using F/OSS licensingstructures, what challenges do you anticipate?

 What can your firm learn about collaboration and agility from F/OSSproject organizations? What can they learn from you? (Remember, you cancontribute knowledge, not just code, to the F/OSS community.)

 What business model(s) is your firm engaged in? What role do F/OSSproducts play in your value offer? F/OSS processes? F/OSS communities?

 How can F/OSS play a role in your firm’s “corporate citizenship”?

Researchers and Analysts

 Does the F/OSS phenomenon shed new light on how creativity works inknowledge workers?

 What is it about programming that evokes a creativity response in ware developers? Can this be achieved in nonsoftware environments?

soft- What are noneconomic incentives to innovate in complex productindustries?

 How portable are F/OSS motivations and practices to other domains ofeconomic activity and social organizations?

 How can F/OSS processes be utilized in proprietary settings, and viceversa?

 How can F/OSS tools be utilized in proprietary settings, and vice versa?

 What are the weakness of the F/OSS process and toolkit? How can these

 Does the F/OSS phenomenon force us to rethink the nature of work?

 Does the F/OSS phenomenon force us to rethink the nature of knowledgesharing? Of intangible/intellectual assets?

 Is F/OSS overly reliant on a countercultural identity? How does “success”change the F/OSS process?

 What are the relationships between F/OSS and other forms of creativityand knowledge creation?

 Does F/OSS provide new modes of organizing and collaborating? Whatare they?

 How does F/OSS actually help address the “digital divide” and the needs

of the information society?

5 Most of the publicly available references in the bibliography of this book can befound in multiple citation management formats (EndNote, Bibtex, and so on) athttp://opensource.ucc.ie Additionally, full-text versions of many of the papers citedare also available in the research repository at http://opensource.mit.edu We hopethat these two resources will be very valuable to our readers

6 Fear, Uncertainty, and Doubt

7 Other definitions of software engineering include these same concepts, but go

on to include economic aspects (for example, “on time” and “on budget”) as well

as team management aspects (SEI 2003)

8 Chapter 10 is an edited reprint of Mockus, A., Fielding, R., and Herbsleb, J.D.(2002), “Two Case Studies of Open Source Software Development: Apache and

Mozilla,” ACM Transactions on Software Engineering and Methodology, 11:3, pp.

309–346

9 The contents of chapter 18 were originally presented by Lawrence Lessig as akeynote address on “Free Software—a Model for Society?” on June 1, 2000, inTutzing, Germany

Karim R Lakhani and Robert G Wolf

“What drives Free/Open Source software (F/OSS) developers to contributetheir time and effort to the creation of free software products?” is a ques-tion often posed by software industry executives, managers, and academicswhen they are trying to understand the relative success of the F/OSS move-ment Many are puzzled by what appears to be irrational and altruisticbehavior by movement participants: giving code away, revealing propri-etary information, and helping strangers solve their technical problems.Understanding the motivations of F/OSS developers is an important firststep in determining what is behind the success of the F/OSS developmentmodel in particular, and other forms of distributed technological innova-tion and development in general

In this chapter, we report on the results of a continuing study of theeffort and motivations of individuals to contributing to the creation ofFree/Open Source software We used a Web-based survey, administered to

684 software developers in 287 F/OSS projects, to learn what lies behindthe effort put into such projects Academic theorizing on individual moti-vations for participating in F/OSS projects has posited that external moti-vational factors in the form of extrinsic benefits (e.g., better jobs, careeradvancement) are the main drivers of effort We find, in contrast, thatenjoyment-based intrinsic motivation—namely, how creative a personfeels when working on the project—is the strongest and most pervasivedriver We also find that user need, intellectual stimulation derived fromwriting code, and improving programming skills are top motivators forproject participation A majority of our respondents are skilled and expe-rienced professionals working in information technology–related jobs,with approximately 40 percent being paid to participate in the F/OSSproject

The chapter is organized as follows We review the relevant literature

on motivations and then briefly describe our study design and sample

characteristics We then report our findings on payment status and effort

in projects, creativity and motivations in projects, and the determinants

of effort in projects We conclude with a discussion of our findings

Understanding Motivations of F/OSS Developers

The literature on human motivations differentiates between those that areintrinsic (the activity is valued for its own sake) and those that are extrin-sic (providing indirect rewards for doing the task at hand) (Amabile 1996;Deci and Ryan 1985; Frey 1997; Ryan and Deci 2000) In this section wereview the two different types of motivations and their application todevelopers in F/OSS projects

Intrinsic Motivation

Following Ryan and Deci (2000, 56), “Intrinsic motivation is defined as thedoing of an activity for its inherent satisfactions rather than for some sep-arable consequence When intrinsically motivated, a person is moved toact for the fun or challenge entailed rather than because of external prods,pressures, or rewards.”1Central to the theory of intrinsic motivation is ahuman need for competence and self-determination, which are directlylinked to the emotions of interest and enjoyment (Deci and Ryan 1985,35) Intrinsic motivation can be separated into two distinct components:enjoyment-based intrinsic motivation and obligation/community-basedintrinsic motivation (Lindenberg 2001) We consider each of them in thefollowing sections

Enjoyment-based Intrinsic Motivation Having fun or enjoying oneselfwhen taking part in an activity is at the core of the idea of intrinsic moti-vation (Deci and Ryan 1985) Csikszentmihalyi (1975) was one of the firstpsychologists to study the enjoyment dimension He emphasized thatsome activities were pursued for the sake of the enjoyment derived fromdoing them He proposed a state of “flow,” in which enjoyment is maxi-mized, characterized by intense and focused concentration; a merging ofaction and awareness; confidence in one’s ability; and the enjoyment ofthe activity itself regardless of the outcome (Nakamura and Csikszentmi-halyi 2003) Flow states occur when a person’s skill matches the challenge

of a task There is an optimal zone of activity in which flow is maximized

A task that is beyond the skill of an individual provokes anxiety, and a taskthat is below the person’s skill level induces boredom Enjoyable activitiesare found to provide feelings of “creative discovery, a challenge overcome

and a difficulty resolved” (Csikszentmihalyi 1975, 181) Popular accounts

of programming in general and participation in F/OSS projects (Himanen2001; Torvalds and Diamond 2001) in particular attest to the flow stateachieved by people engaged in writing software Thus F/OSS participantsmay be seeking flow states by selecting projects that match their skill levelswith task difficulty, a choice that might not be available in their regularjobs

Closely related to enjoyment-based intrinsic motivation is a sense of ativity in task accomplishment Amabile (1996) has proposed that intrin-sic motivation is a key determining factor in creativity Amabile’s definition

cre-of creativity consists cre-of: (1) a task that is heuristic (no identifiable path to

a solution) instead of algorithmic (exact solutions are known), and (2) anovel and appropriate (useful) response to the task at hand (Amabile 1996,35) Creativity research has typically relied on normative or objectiveassessments of creativity with a product or process output judged creative

by expert observers Amabile (1996, 40), however, also allows for tive, personal interpretations of creative acts In particular, she proposes acontinuum of creative acts, from low-level to high-level, where individualself-assessment can contribute to an understanding of the social factorsresponsible for creative output Thus in our case, a F/OSS project dedicated

subjec-to the development of a device driver for a computer operating system maynot be considered terribly creative by outside observers, but may be rated

as a highly creative problem-solving process by some individuals engaged

in the project

Obligation/Community-based Intrinsic Motivations Lindenberg (2001)makes the case that acting on the basis of principle is also a form of intrinsic motivation He argues that individuals may be socialized intoacting appropriately and in a manner consistent with the norms of a group Thus the goal to act consistently within the norms of a group cantrigger a normative frame of action The obligation/community goal isstrongest when private gain-seeking (gaining personal advantage at theexpense of other group members) by individuals within the reference community is minimized He also suggests that multiple motivations, bothextrinsic and intrinsic, can be present at the same time Thus a person who values making money and having fun may choose opportunities that balance economic reward (i.e., less pay) with a sense of having fun(i.e., more fun)

In F/OSS projects, we see a strong sense of community identification andadherence to norms of behavior Participants in the F/OSS movement

exhibit strong collective identities Canonical texts like The New Hacker’s Dictionary (Raymond 1996), The Cathedral and the Bazaar (Raymond 2001),

and the GNU General Public License (GPL) (Stallman 1999a) have createdshared meaning about the individual and collective identities of thehacker2culture and the responsibilities of membership within it Indeed,

the term hacker is a badge of honor within the F/OSS community, as

opposed to its pejorative use in popular media The hacker identityincludes solving programming problems, having fun, and sharing code atthe same time Private gain-seeking within the community is minimized

by adherence to software licenses like the GPL and its derivatives, whichallow for user rights to source code and subsequent modification

Extrinsic Motivation

Economists have contributed the most to our understanding of how sic motivations drive human behavior “The economic model of humanbehavior is based on incentives applied from outside the person consid-ered: people change their actions because they are induced to do so by anexternal intervention Economic theory thus takes extrinsic motivation to

extrin-be relevant for extrin-behavior” (Frey 1997, 13)

Lerner and Tirole (2002) posit a rational calculus of cost and benefit inexplaining why programmers choose to participate in F/OSS projects Aslong as the benefits exceed the costs, the programmer is expected to con-tribute They propose that the net benefit of participation consists ofimmediate and delayed payoffs Immediate payoffs for F/OSS participationcan include being paid to participate and user need for particular software(von Hippel 2001a) Although the popular image of the F/OSS movementportrays an entirely volunteer enterprise, the possibility of paid participa-tion should not be ignored as an obvious first-order explanation of extrin-sic motivations Firms might hire programmers to participate in F/OSSprojects because they are either heavy users of F/OSS-based informationtechnology (IT) infrastructure or providers of F/OSS-based IT solutions Ineither case, firms make a rational decision to hire programmers to con-tribute to F/OSS projects

Another immediate benefit relates to the direct use of the softwareproduct Research on the sources of innovation has shown that users ingeneral and lead users in particular have strong incentives to create solu-tions to their particular needs (von Hippel 1988) Users have been shown

to be the source of innovations in fields as diverse as scientific instruments(Riggs and von Hippel 1994), industrial products (von Hippel 1988), sportsequipment (Franke and Shah 2003), and library information systems (Mor-

rison, Roberts, and von Hippel 2000) Thus user need to solve a particularsoftware problem may also drive participation in F/OSS projects.

Delayed benefits to participation include career advancement (jobmarket signaling (Holmström 1999)) and improving programming skills(human capital) Participants indicate to potential employers their supe-rior programming skills and talents by contributing code to projects wheretheir performance can be monitored by any interested observer.3Similarly,firms looking for a particular skill in the labor market can easily find qual-ified programmers by examining code contributions within the F/OSSdomain

Participants also improve their programming skills through the activepeer review that is prevalent in F/OSS projects (Moody 2001; Raymond2001; Wayner 2000) Software code contributions are typically subject tointense peer review both before and after a submission becomes part of theofficial code base Source code credit files and public e-mail archives ensurethat faulty programming styles, conventions, and logic are communicatedback to the original author Peers in the project community, software users,and interested outsiders readily find faults in programming and oftensuggest specific changes to improve the performance of the code (vonKrogh, Spaeth, and Lakhani 2003) This interactive process improves boththe quality of the code submission and the overall programming skills ofthe participants

Study Design and Sample Characteristics

Study Design

The sample for our survey was selected from among individuals listed

as official developers on F/OSS projects hosted on the SourceForge.netF/OSS community Web site At the start of our study period (fall 2001),SourceForge.net listed 26,245 active projects The site requires projectadministrators to publicly characterize their project’s development status(readiness of software code for day-to-day use) as planning, pre-alpha,alpha, beta, production/stable or mature Projects that are in the planning

or pre-alpha stage typically do not contain any source code and were inated from the population under study, leaving 9,973 available projectsfor the sample

elim-We conducted two separate but identical surveys over two periods Thefirst was targeted at alpha, beta, and production/stable projects and thesecond at mature projects Because of the large number of alpha, beta and production/stable projects and the need to mitigate the effects of