Bug-fixing and code-writing: The private provision of open source software

INFORMATION

www.elsevier.com/locate/iep

Information Economics and Policy 17 (2005) 389–406

ECONOMICSAND POLICY

Bug-fixing and code-writing:The private provision of open source software

Jurgen Bitzer a,*, Philipp J.H. Schroder b

a Department of Economics and Institute for East European Studies, Free University Berlin,

Garystr. 55, D-14195 Berlin, Germanyb Aarhus School of Business, Denmark

Available online 16 February 2005

Abstract

Open source software (OSS) is a public good. A self-interested individual would consider

providing OSS if the benefits to be gained from it justify the cost of programming. Neverthe-

less, each agent is tempted to free-ride and wait for others to develop the software instead. We

model this problem as a war of attrition with complete information, job signaling, repeated

contribution to the public good and uncertainty in programming. The resulting game does

not feature any delay; software will be provided swiftly, by young, low-cost individuals who

gain from signaling their programming skills. The startup (and collapse) of an OSS project dis-

plays bandwagon dynamics.

� 2005 Elsevier B.V. All rights reserved.

JEL classification: H41; L86; L31

Keywords: Open source software; War of attrition; Public goods

0167-6245/$ - see front matter � 2005 Elsevier B.V. All rights reserved.

doi:10.1016/j.infoecopol.2005.01.001

* Corresponding author. Tel.: +49 30 838 53594; fax.: +49 30 838 52072.

E-mail address: [email protected] (J. Bitzer).

mailto:[email protected]

390 J. Bitzer, P.J.H. Schroder / Information Economics and Policy 17 (2005) 389–406

1. Introduction

Open source software (OSS) is a public good made available at no cost by volun-

teer programmers.1 Contrary to what one might expect, the software they produce is

by no means marginal. In fact, a number of OSS projects even capture market sharesfrom their commercial competitors and have a reputation for innovation and reli-

ability. Popular examples are Linux, which is as of 2004 estimated to run on some

18 million computers (Linux Counter, 2004), and the Apache Web Server, which

is installed on 67% (i.e., 34 million units) of reachable web servers worldwide (Net-

craft, 2004). These achievements are even more astounding if one takes into account

the fact that millions of lines of code have been written and thousands of software

bugs have been fixed for each large OSS project, all by individual volunteer program-

mers. This army of programmers only associate with each other through informalcommunities such as Internet newsgroups, and all share a common interest in

OSS. They donate their time and effort free of charge, although they are unable to

choose or limit who will reap the benefits of their labor.

This phenomenon puzzles economists and has thus given rise to a rich and diverse

body of literature (see e.g., Rossi, 2004; for a recent literature survey). The history of

OSS is, for example, documented in Stallmann (1999), Rosenberg (2000), Feller and

Fitzgerald (2002), and Hars and Ou (2002). The existing literature highlights a vari-

ety of motives for OSS developers to engage in voluntary programming, rangingfrom a need for the software solution (user-developers) to intrinsic motives such

as fun and play. Furthermore, it emphasizes the important role of community struc-

tures in the success of OSS; see, for example, Franke and von Hippel (2003), von

Krogh et al. (2003), Shah (2003), and O�Mahony and Ferraro (2005). While these

contributions deal mainly with empirical OSS issues, other more theoretical ap-

proaches to the issue include Lerner and Tirole (2002), who emphasis the role of sig-

naling programming skills, Mustonen (2003), who presents a model of OSS licensing

schemes and their effects on programmer labor markets and software product mar-kets, and Bitzer (2004), who deals with the competitive impact of challenging a com-

mercial software firm with an OSS alternative.

The present paper attempts to contribute to the theoretical literature on OSS by

addressing the OSS phenomenon as a game of the private provision of a public good.

We propose a model that follows on the work of Bliss and Nalebuff (1984), Hen-

dricks et al. (1988), and Bilodeau and Slivinski (1996). We start by developing a sim-

ple war of attrition setting. We build our model on existing results and assumptions,

in particular Bilodeau and Slivinski (1996), who study the private provision of a pub-lic service, i.e., work that no one wants to do but that is best provided by a single

individual. Their approach is novel in that it achieves a characterization of the even-

tual provider of the public service; whereas most of their predecessors had dealt with

the question of whether and when a public good would ultimately be provided. Two

1 The term OSS refers to the fact that everyone can access and alter the program source code; it is a

public good because under the common GNU GPL license, any additions made by one programmer/user

must be made available at no cost to all other programmers/users.

J. Bitzer, P.J.H. Schroder / Information Economics and Policy 17 (2005) 389–406 391

crucial assumptions make this characterization possible: first, that individuals act un-

der complete information, while second and more importantly, that they have a finite

time horizon. The present paper follows their approach, beginning in Section 2 by

developing a complete information game with finitely lived agents. As shown by

Bilodeau and Slivinski (1996), this game has a unique subgame-perfect equilibriumwhich enables us to characterize the provider of the public good. Other papers that

have modeled the private provision of a public good in order to analyze OSS include

Johnson (2002), who develops a static model with incomplete information and stud-

ies the effects of population size on the probability that an OSS product will be pro-

vided; Stenborg (2004), who considers heterogenous agents and heterogeneous

contributions to the public good in a model related to the present framework; and

Bitzer et al. (2004), who introduce intrinsic motives in a model that builds on the

present paper.The present paper contributes to existing literature on the private provision of

public goods by explicitly modeling several OSS-specific characteristics. First, the

element of user-developers is captured in the present specification. This is a unique

feature of OSS; the providers of the software are also consumers of the product,

which may entail that the need for a particular software solution drives the decision

to program it (e.g., Kuan, 2001; or Franke and von Hippel, 2003). Notice that this

phenomenon of user-developers is by no means restricted to the realm of OSS. See,

for example, Franke and Shah (2003), who analyze cases of user communities thatsupport innovation activities for sports-related products. Second, we capture the ele-

ment of signaling: the providers of the public good receive an additional payoff on

top of the utility stemming from consumption of the public good by being able to

signal their programming abilities. The signal creates value both because it improves

their prospects on the job market (Lerner and Tirole, 2002; Raymond, 2000b) and it

enhances their reputations within the community of programmers (cf. Raymond,

2000a; Torvalds and Diamond, 2001). However, the signal lasts only for a limited

period of time after the contribution is made. The OSS license obliges its program-mers/users to document all program changes made (including naming the author of

the changes) in the software itself, thus institutionalizing such signals. Third, the sim-

ple private-provision-of-a-public-good model – where the OSS is a one-off discrete

unit of a public good – is extended to incorporate modular software programming

(Section 3). Agents improve the available OSS by creating complementary software

modules, thus making repeated contributions to the public good. This extension re-

quires that the certainty assumption in the model has to be adapted, acknowledging

the fact that the success of any programming effort is uncertain. The individualagents do not know a priori how many modules will actually exist at any future point

in time, but they do know how many agents are expending effort on developing new

or additional modules, and that the value of any new module will increase with the

number and quality of other software modules developed for the same OSS project.

More precisely, the model assumes that the functionality and applicability of any one

software module depends on how many other new or improved modules are devel-

oped. For example, the improvement of an operating system developed by one agent

increases the value of a newly programmed driver by another agent, and vice versa.


Thus, an agent�s decision to contribute to a certain OSS depends on both the number

and quality of all other volunteer programmers engaged in the project.2

The paper derives the following results from the formal models. In a standard

war-of-attrition game, where OSS is a one-off discrete unit of public good to be

developed, the software will be provided without delay. The actual individualwho provides the unit can be identified. Ceteris paribus, this individual receives a

greater benefit from using the OSS, gains more from being able to signal his pro-

gramming ability, is more patient, has a longer time horizon, and faces lower costs

for software development. In particular, the latter two characteristics are in line

with recent empirical studies which found that the �average� OSS contributor is

about 30 years old and highly educated (e.g., Hars and Ou, 2002; Hertel et al.,

2003; Lakhani and Wolf, 2003; Krishnamurthy, 2002). If the software has a mod-

ular architecture, i.e., if agents can repeatedly contribute new or improved modulesto the public good, the war-of-attrition feature of the game collapses. Instead,

agents have to decide when to join and exit the programming community. Once

again, software will be provided sooner rather than later. Individuals are more

likely to join the programming community (and will start to free-ride at a later

point in time), the greater their potential benefit from the OSS, the longer their

time horizon is, the more patient they are, the lower their costs of developing soft-

ware, the higher the success rate in programming activity is, the greater the com-

plementarity between software modules, and the larger the community ofprogrammers. A greater benefit to be gained from signaling – even though it ini-

tially attracts agents to join an OSS community – also induces them to start to

free-ride at an earlier stage, i.e., to harvest the (now larger) value of the signal.3

More importantly, the model establishes that the startup (and collapse) of an

OSS community of programmers displays bandwagon dynamics. In particular,

when one agent joins the community of programmers, this immediately increases

the probability of other non-members joining, while withdrawal by a member of

the community of programmers makes everyone else more likely to drop out ofan ongoing project. Bearing in mind that these results have been derived under

the stark assumption of no exogenous growth in the community of programmers,

they give rise to empirically testable patterns of project participation.

It is also important to highlight some of the major limitations and weaknesses of

the formal approach presented in this paper. The decision whether to publish a piece

of software as OSS or to sell it as proprietary software instead is not modeled explic-

itly here. This decision problem shows up only indirectly in our approach via the

development cost. In particular, the agent-specific development costs reflect not onlydirect input costs but also indirect opportunity costs, and thus implicitly take into

account the alternative of selling the software. In addition, if a programmer further

2 On the issue of modular versus integral product architecture, see Ulrich (1995). For papers that analyze

the importance of modular architecture in OSS projects see Baldwin and Clark (2003) and Narduzzo and

Rossi (2004).3 This finding can also be related to the duration of the signal, if signals decay more swiftly, free-riding

becomes less attractive.


develops an OSS product already published under the GPL, he or she can no longer

opt for a commercial sales channel, and the only alternative that remains is to keep

the new software version out of the public domain and opt for purely private use.

The latter strategy, however, is only rational if the software in question commands

zero or negative signaling value if published, which may be the case for badly pro-grammed software. Further limitations of our model, apart from the fact that the

decision to publish as OSS is not derived from first principles, are that agent�s pro-gramming contributions (modules) are homogeneous, that agents are assumed to act

under complete information and that central characteristics of the OSS management

process are ignored.

The remainder of the paper is structured as follows. Section 2 introduces the model

and presents the assumptions used for the basic OSS phenomenon that result in a war-

of-attrition setup; it deals only with equilibria where software development (the publicgood) is treated as a single discrete unit. In Section 3, themodel is extended to deal with

software development of a modular nature, where individuals can repeatedly contrib-

ute to the public good. Section 4 concludes the paper.

2. The Model

Consider a population of N individuals. Each individual j has the ability to devel-op one discrete unit of OSS. Once developed, it exists forever, is identical for all indi-

viduals, and its consumption is characterized by non-rivalry and non-excludability.

Time is continuous and individuals discount the future at the rate rj. Utility flows are

as follows. Without the OSS, individuals have to use a commercial closed-source

software alternative and receive the utility flow vj. From the time when the OSS is

introduced on, all individuals receive the flow utility uj = vj + zj, where zj(zj P 0

"j = 1, . . .,N) is the flow value from the OSS being available. Individuals can pro-

duce the software at cost Cj, which will be specified below. Cj is the present dis-counted value of the net costs to the individual j who develops the OSS, i.e., it is

the actual development cost minus any gains from the signaling of programming

ability and the improved reputation within the community of programmers. Given

these specifications, we can state:

Lemma 1. No individual in group m, defined by Cj Pzjrjfor all j = 1, . . .,m, would ever

develop the OSS. The community of potential developers consists of n = N � m

individuals i, for which Ci <zirifor all i = 1, . . ., n.

In other words, Lemma 1 states that those individuals who face relatively low

costs when developing software, or who benefit relatively more from the OSS, are

potential developers of the software.

Assumption 1. Within community n, all costs and benefits are common knowledge.

Even though Assumption 1 is a strong one in relation to any real-world phenom-

enon, OSS has at least some features that facilitate comparatively low-cost informa-

tion exchange. For example, information on the status of projects and the abilities


(programming techniques) of other programmers is available within the community

of OSS programmers, as the source code is open and numerous OSS internet news-

groups exist (e.g., DeBona et al., 1999).

If a simultaneous one-time choice is modeled using the strategy set {develop, do

not develop}, then this game becomes a static game of chicken, where the winningagents are able to free-ride and receive the payoff ui

ri, and the losing agent develops

the software and receives the payoff uiri� Ci. If no one develops the OSS, the payoff

for all is viri. As usual, this type of game features a host of pure and mixed-strategy

Nash equilibria, in which anyone might be the actual developer of the software.

Hence one cannot deduce who will actually develop the OSS.

By allowing individuals the option of postponing their decision to wait and see if

someone else will develop the software instead, some dynamics can be added to the

game. The length of time a member of community n is willing to wait naturally de-pends on the benefit he would gain if the OSS existed, on the costs of developing the

software himself, and on his time preference. In the normal-form version of this

game, a pure strategy is a time ti�[0,1) when i will develop the software if no one

else has already done so.

The following payoffs can be stated. If the OSS is developed by individual j 6¼ i at

time t, i�s payoff is:

4 Ele

the sof5 Bel

OSS p

howev

signal

F iðtÞ ¼virið1� e�ritÞ þ ui

rie�rit: ð1Þ

The net cost of developing the software consists of a one-off development cost

ci, and a net utility flow si incurred forever.4 The term ci includes all costs incurred

through software development and publishing of the program as OSS. Thus, not

only the costs of pizza and Coke consumed during the programming but alsothe opportunity costs of carrying out a paid programming project or selling the

product as proprietary software instead are included in the decision of the agent.

The term si denotes the gain from being able to signal programming skills, i.e.,

the signaling value, which could accrue either in a job market/wage negotiation set-

ting (Lerner and Tirole, 2002), i.e., as a signal to individuals outside the commu-

nity, or from the improved reputation and social standing within the community

(Torvalds and Diamond, 2001).5 If individual i develops the software at time t,

his payoff is

DiðtÞ ¼ F iðtÞ þsirie�rit � cie�rit: ð2Þ

ments ci and si add up to a net cost CiðtÞ ¼ cie�ri t � sirie�rit, i.e., the net cost for agent i of developing

tware at time t.

ow in Section 3, where we examine entry and exit behavior and repeated contribution to modular

rojects, we include the stickiness of signals or rather the decay of signals as a parameter. Here,

er, where only one individual provides the OSS, this issue is ignored and we assume instead that the

persists.


According to Lemma 1 we have ui + si � rici > vi. Thus, every individual in the

community n would develop the OSS in period 0 rather than live without it forever.

Finally, if no one ever develops the software, individual i receives the payoff

Ri ¼ viri¼ limt!1F iðtÞ ¼ limt!1DiðtÞ.

Lemma 2. Any individual i such that ci <siriwill develop the OSS voluntarily and

immediately at time t = 0.

Proof is given in Appendix A. In plain speech, Lemma 2 states that an individual

who gains considerably from being able to signal programming ability simply devel-

ops the software rather than waiting for someone else to provide it.6 According toLemma 2, the game ends at time t = 0. A more complex game emerges under the fol-

lowing assumption.

Assumption 2. ci P sirifor all i = 1, . . .,n.

Through Assumption 2 and Lemma 1, we know Fi(t) > Di(t) > Ri for all t and

the game becomes an n player continuous time war of attrition (Hendricks

et al., 1988).

Using results in Hendricks et al. (1988) and Bilodeau and Slivinski (1996), one can

characterize the following equilibria for this type of game. For every individual i,

there is a subgame perfect equilibrium outcome in which only i will develop the OSS

immediately. If no one but i develops the OSS, then i�s best strategy is to develop

the OSS immediately, and if i develops the OSS immediately, it is everyone�s beststrategy to wait. So the game still permits – as is usual for this type of game – many

subgame perfect equilibria in which anyone might volunteer. As shown in Bilodeau

and Slivinski (1996), the set of subgame perfect equilibria can be radically reduced

once time horizons become finite, regardless of how distant in the future the time

limit is. Using this assumption, it is now possible to fully characterize the individual

who will actually provide the public good.

Assumption 3. All individuals i = 1, . . ., n have a finite time horizon, Ti.

That is, Ti marks the fact that i is a finitely lived agent.7 The altered payoffs

become:

6 Im

created7 Th

i move

time w

could

F iðtÞ ¼virið1� e�ritÞ þ ui

riðe�rit � e�riT iÞ; ð3Þ

DiðtÞ ¼ F iðtÞ þsiriðe�rit � e�riT iÞ � cie�rit; ð4Þ

Ri ¼virið1� e�riT iÞ: ð5Þ

plicitly we assume that several agents can develop the software, but that only one unit of software is

. However, all developing agents receive their signaling payoff.

ere are several possible interpretations of this assumption: Ti could denote the point in time at which

s to a different job (where he is unable to devote any effort to OSS programming), or the point in

hen i�s human capital becomes outdated. Assuming birth of agents has happened in the past, it

also represent the fact that at time t = 0, agents are of different ages.


The effect of a finite time horizon is that the game becomes non-stationary. Thus,

from an agent�s perspective, there is a time �t at which he will no longer choose to

become a developer of OSS. Beyond that point in time, even if the OSS is not pro-

vided, the dominant strategy will be to never develop, i.e., DiðtÞ < Ri; 8t > �ti. Thecritical time �t is defined by Dið�tÞ ¼ Ri.

Lemma 3. Individual i will not develop the OSS after time

�ti ¼ T i �1

riln

zi þ sizi þ si � rici

� �: ð6Þ

Note that if zi + si < rici then time �t is not defined, which is in fact the condition of

Lemma 1; i.e., individuals that are not members of the community n. Using Lemma 3it is possible to state (Bilodeau and Slivinski, 1996):

Proposition 1. Given a finite time horizon for every individual in community n and

assuming that for all i; j 2 f1; . . . ; ng; i 6¼ j : �ti 6¼ �tj, a unique subgame perfect

equilibrium exists in which the individual with the highest �ti volunteers at time t = 0.

Proof is given in Appendix A. The intuition for this proposition is straightfor-

ward. If an individual knows that he is the most interested in having the OSS, and

if he knows that everyone else knows this as well, then he might as well give in right

away. The unique developing individual is characterized by the highest �t. Formally,

Proposition 2. Ceteris paribus an individual who

(i) would gain more from the software, zi(ii) would gain more from signaling, si(iii) has a longer time horizon, Ti (can consume OSS for a longer time)

(iv) has a lower discount rate, ri (more patient) and who

(v) faces lower costs for software development, ci (more efficient) is more likely toprovide the OSS.

Proposition 2 follows from Proposition 1 and Lemma 3. In particular, result (iv) –

the effect of a change in the discount rate – differs from the results that Bilodeau and

Slivinski (1996) derive using intuitive reasoning and indeed differs from the conven-

tional intuition behind the war of attrition, where patience is a good strategy for win-

ning. Formal proof of our result is given in Appendix A.

What are the main factors driving the central findings in Propositions 1 and 2?First consider the result that the programmer will volunteer immediately, i.e., that

the usual delay problem of private public good provision is resolved in the present

setting. The intuition for this result comes from the standard assumption about the

self-interested individual. If an agent knows that she will eventually be the supplier

of the public good she may as well supply the good immediately to ensure a longer

duration of consumption. Delay only pays as long as there is some chance that

someone else will step in and supply the public good. Yet in the present setting,

waiting and delay do not pay, because the agents have information not onlyon their own situation but on everybody else�s as well. Thus, once an agent is


convinced that she will be the eventual provider of the OSS, she will prefer to har-

vest the gains from consuming the software and from being able to signal her tal-

ent over the longest possible period of time, and will thus develop the software

sooner rather than later. The intuition for Proposition 2 items (i) to (iv) runs along

similar lines. In each of these results, the value of the public good to the agent isincreased, either because the agent simply places a higher value on the software (i)

or because the value of the signal is particularly high for the agent (ii) and thus

makes her more willing to provide the OSS. Following from this reasoning, both

the ability to be able to consume for a longer time (iii), and actually placing a higher

value on future consumption (iv, lower ri) have the same effect. Finally, we find

that low-cost individuals are more likely to provide the OSS, Proposition 2, item

(v). Ceteris paribus this result can be interpreted such that within the model,

OSS code comes from more efficient (high-skilled) programmers. The latter inter-pretation is in line with recent empirical findings of Hars and Ou (2002), Hertel

et al. (2003), Lakhani and Wolf (2003), and Krishnamurthy (2002) on characteris-

tics of OSS contributors. However, for a proper examination of the issue, one

needs to address agent heterogeneity more explicitly (e.g., Stenborg, 2004). The

findings of the model can also be interpreted as suggesting that relatively poor

agents are more prone to provide the OSS, since both a lower discount rate and

lower opportunity costs would more likely be found among, e.g., poor graduate

students than among high-paid Silicon Valley engineers.8

3. Modular software: repeated contributions to the OSS

In this section, the assumption that the OSS is a discrete unit of software is

relaxed. Instead it is assumed that the OSS is modular in its product architecture

(cf. Baldwin and Clark, 2003; Narduzzo and Rossi, 2004). This implies, in our

context, that the amount of the public good is determined by the number andquality of modules contributed by agents. This adaptation of the model therefore

includes the possibility of multiple contributions by each of the various participat-

ing agents. Stock effects are eliminated by assuming that agents are only inter-

ested in new and additional advances in software, thus normalizing the utility

in a no-further-module-improvements situation. It is assumed that commercial

software has a certain exogenously given and fixed growth rate, generating the

flow utility Dvj.9 Similarly, the flow utility from progress and growth in the

OSS is denoted by Zj(Dl), where Dl is the number of new and improved OSSmodules developed at a certain point in time. Thus agent j�s utility becomes

uj = Dvj + Zj(Dl).Programming effort invested into OSS does not promise certain success. Thus, it is

assumed that the occurrence of a new, functioning OSS module that is actually

8 We owe this last point to an anonymous referee.9 Accordingly it is inessential to the model whether commercial software employs an integral or a

modular product architecture.


included in the product follows a Poisson distribution with the arrival rate k, where krepresents the common programming ability in the community. So the probability

that Dl such modules are created at a certain point in time, if n agents are involved

in programming is ðknÞDlDl! e

�kn. A specification from the quality ladder model literature

(e.g., Aghion and Howitt, 1992) is borrowed to capture the fact that the OSS�s appli-cability and functionality increase as the number and quality of modules simulta-

neously developed by other agents increases. In particular, we postulate that the

utility flow from OSS is given by Zj(Dl) = zjcDl, where c > 1 measures the resulting

gain in applicability and functionality stemming from the complementarity of soft-

ware modules, and where zj P 0 represents an agent�s preference for OSS software

over commercial software. The expected utility flow from newly developed OSS soft-

ware at any point in time is thus

EðZjðDlÞÞ ¼X1Dl¼0

ðknÞDl

Dl!e�knzjcDl ¼ zjeðc�1Þkn: ð7Þ

The utility flow stemming from OSS depends on the number of other agents

participating; this creates strategic interaction among agents. However, this is

no longer a war of attrition: it is no longer possible for an individual to wait

out his opponents. Rather, agents now have the dilemma of when or whether

to join and leave the community of programmers, whereby their additional

(withdrawn) effort increases (decreases) the probability of new, functioning mod-ules occurring. This problem can be addressed by examining the expected lifetime

utility of an agent i, who is a member of the community n. When all agents

including i develop OSS modules throughout their entire lifetime, this gives the

payoff

Di ¼Dvi þ zieðc�1Þkn þ SiðdÞ � ci

rið1� e�riT iÞ: ð8Þ

This specification acknowledges that in an environment of continuous software

development and repeated contributions, the characteristics of signaling have to

adapt to the fact that reputation and signals decay. We capture this with the functionSi(d), stating that the value of the signal, apart from being specific to the individual

agent, depends – among other factors – on a decay rate d, where oSiðdÞod 6 0 applies,

i.e., a faster decay reduces the value of the signal. Signal decay could be caused by

dynamics either within the community, where only agents who actually make contri-

butions are part of the reputation culture, or on the job market, where, due to con-

tinuous technological progress, last season�s human capital has little value. However,

at the moment in time when an agent leaves the community of programmers, he still

retains his gain from signaling, without actually having to program. Furthermore,having stopped developing modules himself, the agent continues to have access to

the software developed by other agents, so he still receives the full benefit from

the OSS, but without the cost of having to contribute himself. So the payoff for agent

i, who starts to free-ride at time t, assuming that all other agents remain in the com-

munity, becomes:

10 Th

author


F iðtÞ ¼Dvi þ zieðc�1Þkn þ SiðdÞ � ci

rið1� e�ritÞ þ Dvi þ zieðc�1Þkðn�1Þ

riðe�rit � e�riT iÞ

þ SiðdÞe�rit: ð9Þ

Solving F ið�tÞ ¼ Di defines the point in time ð�tÞ at which an individual who is a

member of the community – developing OSS software – will leave it and start to

free-ride.

Lemma 4. Individual i will stop contributing modules to the OSS at time

�ti ¼ T i þ1

riln 1þ riSiðdÞ

zieðc�1Þkðn�1Þ � zieðc�1Þkn � SiðdÞ þ ci

� �: ð10Þ

For free-riding to actually occur during an agent�s lifetime, the following require-

ment has to be introduced.

Assumption 4. zie(c � 1)kn � zie

(c � 1)k(n � 1) + Si(d) � ci > riSi(d) for all i = 1, . . .,n.

Assumption 4 ensures that the logarithm in (10) produces a negative number. For

a very large ci, the condition will be violated, implying that such an individual is not

a member of the community. Also, Assumption 4 will eventually hold for a large en-

ough n, implying that free-riding will occur in large communities.Differentiating (10) with respect to the various parameters,10 we can characterize

free-riding individuals.

Proposition 3. Ceteris paribus an individual will start to free-ride later, i.e., �t will behigher, when he

(i) gains more from the open source software, zi(ii) has a longer time horizon, Ti (can consume OSS for a longer time)

(iii) has a lower discount rate, ri (more patient)

(iv) faces lower costs for software development, ci (more efficient)

(v) is part of a community with a higher arrival rate, k(vi) takes part in a project with larger complementarity among modules, c(vii) is part of a larger community, n(viii) has a lower signaling value, Si(d) and

(ix) is subjected to a faster decay rate, d.

Proof that o�tiori

< 0 and o�tioSiðdÞ < 0 is given in Appendix A.

Results (i) to (iv) re-establish findings of Proposition 2. Furthermore, the model

predicts that good programmers attract good programmers (v), and that high com-

plementarity between software modules creates incentives for programmers to stay

in the project (vi). A larger signaling value – Proposition 3 item (viii) – or a reduceddecay rate – Proposition 3 item (ix) – can induce free-riding, because when the agent

leaves the community, he harvests a temporary gain by maintaining the signaling

e precise expressions of the derivatives are provided in a separate appendix available from the

s upon request.


value while not facing the costs of programming. As this gain increases, the free-rid-

ing payoff also increases and the agent will thus exit the community sooner. Further-

more, an important finding regarding the dynamics of the community emerges from

Proposition 3 item (vii).

Corollary 1. The exit of any agent i from the community n makes all other n � 1

agents revise their stopping time downwards.

Thus, the collapse of an OSS project displays bandwagon dynamics. The exit of

one agent increases the probability that in the next instant, another agent will exit.

The mechanism behind this result is that the exit of another agent from the commu-nity reduces, via the complementarity of modules, the value of all other contribu-

tions, hence making it less attractive for everyone else to program.11

To examine the startup of an OSS project, the incentives to join a programmer

community have to be examined using the same principles. The payoff for an agent

j – who never develops any OSS modules himself – when a community of n active

programmers exists is

11 No

size.

F j ¼Dvj þ zjeðc�1Þkn

rjð1� e�rjT jÞ: ð11Þ

If such an individual joins the community at time t and starts to develop modules,

whose signaling value is generated only after the agent has actually started this activ-

ity, his payoff becomes

DjðtÞ ¼Dvj þ zjeðc�1Þkn

rj1� e�rjtð Þ þ Dvj þ zjeðc�1Þkðnþ1Þ þ SjðdÞ � cj

rjðe�rjt � e�rjT jÞ

� SjðdÞe�rjt: ð12Þ

Then solving Dj(t) = Fj defines the time up to which an agent would still want to

join the community.

Lemma 5. Individual j will not join the OSS community n after time

tj ¼ T j þ1

rjln 1þ rjSjðdÞ

zjeðc�1Þkn � zjeðc�1Þkðnþ1Þ þ cj � SjðdÞ

� �: ð13Þ

Of course, time tj is only slightly less than the stopping time derived in (10), imply-ing that after joining, an agent will continue at least a certain period of time before

starting to free-ride. Furthermore, sinceoDjðtÞot < 0 we can state:

Lemma 6. Any agent j who joins an existing OSS programming community during hislifetime will do so as early as possible.

Finally, because (10) and (13) have identical structures, the qualities laid out in

Proposition 3 are also possessed by those agents who would still find it beneficial

to join the programming community at a later point in time. It is important to note

tice however that this result only applies as long as there is no exogenous increase in the community


that the conditions in Lemmas 5 and 6 might not be fulfilled in small communities,

i.e., for low n. The time up to which an agent would consider joining the community

might become negative for low n, implying that the agent would never become a

member.

It then remains to be shown which characteristics an agent possesses whowould actually start an OSS project from scratch. This type of individual fulfills

tjjn = 0 > 0. Plugging n = 0 into (13) and solving for the cost of programming

gives:

Proposition 4. (Starting module) An agent j with a programming cost cj such thatcj < SjðdÞ � zj þ zjeðc�1Þk � rjSjðdÞ

1�e�rjT jwould develop an OSS starting module.

The requirements for this proposition are in fact more restrictive than those in

Assumption 4. From Proposition 4, it follows that more efficient agents (lower cj),

agents with a longer time horizon (higher Tj), agents who have a lower discount rate,

rj, who gain more from signaling their programming skills, Sj(d), and who have a lar-

ger preference for OSS, zj, are more likely to start up an OSS project. Furthermore,

startup becomes more likely when signal decay rates, d, are low.

Finally, sinceotjon > 0 one can provide a complement to Corollary 1:

Corollary 2. The addition of an agent j to the community n makes all other non-

member agents revise their latest joining time upwards.

Thus, the startup of an OSS project displays bandwagon dynamics as well.12 Anew member entering a community increases the probability that in the next instant,

another agent will join.

4. Conclusion

This paper extends the standard war-of-attrition model of the private provision of

public goods developed by Bliss and Nalebuff (1984) and Bilodeau and Slivinski(1996) to the OSS phenomenon. In order to capture OSS characteristics, we include

the phenomenon of user-programmers, i.e., the need for a particular software solu-

tion (Torvalds and Diamond, 2001; Raymond, 2000a) and the value of boosting

one�s reputation and job signaling (Raymond, 2000b; Lerner and Tirole, 2002) into

the standard model. In a second step, we extend the resulting model by assuming

that OSS is modular in its product architecture, which indeed reflects a key feature

of the OSS development process. In terms of our model, this means that agents can

make repeated contributions to the public good and that they make their decisionunder uncertainty as to how many new or improved OSS modules will be developed

by other agents. Thereafter, an agent�s expected benefits and his or her resulting deci-

sion on whether to join or leave the programming community both depend on the

number of other agents developing OSS modules, the complementarity effects

12 A case study that touches on the issue of joining decisions in real-world OSS projects is found in von

Krogh et al. (2003).


between the single OSS modules, the level of programming ability within the com-

munity of programmers (e.g., the skill level of all other programmers), and the sig-

naling value.

The model generates the following results: In the basic model, where we as-

sume that only one unit of open source software is to be developed, the softwareis provided sooner rather than later. Thus, the problem of delay, often an issue in

private-provision-of-public-goods settings, is resolved in the OSS case. Next, the

individual who will actually provide the OSS ceteris paribus gains more from

using the software, from being able to signal programming skills, has a longer

time horizon, is more patient (i.e., lower discount rate) and faces lower develop-

ment costs. Thus, the model predicts that young and efficient (highly skilled)

programmers are to be found in OSS communities. In addition, by extending

the basic model to include modular product architecture, we can also show thatindividuals are more likely to join the programming community (and start to

free-ride later) the better the programming abilities in the community, the higher

the complementarity between the individual modules, and the larger the number

of other programmers developing OSS modules. Thus, the model predicts that

good programmers attract good programmers, that certain types of software

products – namely those with a high module complementarity – are more suitable

for production under OSS principles, and that the size of the potential program-

mer base – which often is associated with a worldwide communication of pro-grammer community facilitated by the Internet – is key to understanding the

phenomenon.

Due to the impact of community size on the agents� decisions, the startup (and

collapse) of an OSS project displays bandwagon dynamics. Thus, within the model

one would expect successful OSS projects – i.e., those that have developed beyond

the initial phase of only a few programmers – to display exponential growth in both

output volume and the number of participating programmers. Similarly, the model

predicts that with the failure of a once-successful project the exit of active program-mers would occur at an accelerating pace.

Comparing these results of a formal model with the empirical evidence must be

the task of future research. Yet one could argue that several of the commonly ob-

served characteristics of OSS programmers and their projects appear to relate to

some of the results presented here, e.g., that the �average� programmer is young

and highly skilled, as found by Hars and Ou (2002), Hertel et al. (2003), Lakhani

and Wolf (2003), and Krishnamurthy (2002). Still, the reader must keep in mind that

the present paper is based on a stylized and simplified model. Important features,such as the decision of agents to publish their efforts as OSS instead of commercial

software or the role of the OSS management structures, are simply superimposed

within the model and not derived endogenously. Nevertheless, the benefit of this ap-

proach is that we arrive at a tractable model that provides a set of relevant implica-

tions about the provision of OSS by private volunteer programmers. Most

importantly, the paper demonstrates that, once we understand the OSS phenomenon

as a private provision of a public good situation, many of the initially puzzling OSS

features emerge naturally.


Acknowledgments

The authors thank Ulrich Berger, Paul Gregory, Julio Robledo, Wolfram Sch-

rettl, Peter Sudholter, participants in the e-business seminar at the Aarhus School

of Business, the Kiel Workshop on Economics of Information and NetworkIndustries, the International Industrial Organization Conference (IIOC) at North-

eastern University, the European Association for Research in Industrial Econom-

ics (EARIE) at Helsinki University and two anonymous referees for valuable

comments.

Appendix A

A.1. Proof of Lemma 2

Proof. The condition siri> ci implies Di(t) > Fi(t) for all t. Since Di(t) is monotone and

falling in t, Di(0) maximizes utility. h

A.2. Proof of Proposition 1

Proof.13 Relabelling individuals, the different �ti�s can be ordered �tn > �tn�1 > � � � > �t1.When the software has yet to be provided at time t 2 ð�tn�1;�tn�, agent n knows that no

one else will ever develop the OSS. Since DnðtÞ > RnðT nÞ 8t�ð0;�tnÞ and hence also for

all t 2 ð�tn�1;�tnÞ, agent n�s subgame perfect strategy is to develop the OSS, if any time

t�ð�tn�1;�tnÞ is reached. Similarly at any time t 2 ð�tn�2;�tn�1�, agent n and n � 1 are the

last feasible candidates who could provide the software. But there is a time ~t < �tn�1

and sufficiently close to �tn�1, such that F n�1ð�tn�1Þ > Dn�1ð~tÞ, and hence n � 1, and

everyone else, will prefer to wait for n to volunteer at time �tn�1. Hence, in anysubgame perfect equilibrium, n will volunteer at some time t 2 ð~t;�tn�. By backwards

induction, the unique subgame perfect equilibrium has n developing the OSS at

t = 0. h

A.3. Proof that o�tiori

< 0 when software is a single unit

Proof. From (6) we derive

13 Th

o�tiori

¼ �ciriðzi þ si � riciÞ

þln ziþsi

ziþsi�rici

� �r2i

ðA:1Þ

which, given Lemma 1 and Assumption 2, consists of a negative and a positive term.

Following Proposition 2, we have to show that o�tiori

< 0. In manipulating (A.1), one

can restate

is proof follows Bilodeau and Slivinski (1996).


lnzi þ si

zi þ si � rici

� �<

zi þ sizi þ si � rici

� 1 ðA:2Þ

which is always true since a � ln(a) > 1 "a > 0; a 6¼ 1. h

A.4. Proof that o�tiori

< 0 when software is modular


o�tiori

¼ �ba� b

ln 1þ�ba

� �; ðA:3Þ

where a = �ci + Si(d) � zie(c � 1)k(n � 1) + zie

(c � 1)kn and b = riSi(d), and a > b > 0

holds due to Assumption 4. Following Proposition 3, it has to be shown thato�tiori

< 0. Rearranging (A.3) yields:

1� aa� b

< lna� ba

� �:

Finally, defining x ¼ aa�b > 1, this requirement can be restated as

0 < ln1

x

� �þ x� 1: ðA:4Þ

Define the function

gðxÞ ¼ ln1

x

� �þ x� 1 ¼ x� lnðxÞ � 1:

Note that g(1) = 0 and g 0(x) > 0 "x > 1. Condition (A.4) is therefore true for the

relevant parameter range. h

A.5. Proof that o�tioSiðdÞ < 0 when software is modular


o�tioSiðdÞ

¼ 1

ci þ aþ riSiðdÞ � SiðdÞ þ SiðdÞ ð�1Þ þ ðri�1ÞSiðdÞ�ci�a

� � ; ðA:5Þ

where a = zie(c � 1)k(n � 1) � zie

(c � 1)kn < 0; o�tioSiðdÞ is negative for:

ci þ aþ riSiðdÞ � SiðdÞ þ SiðdÞ ð�1Þ þ ðri � 1ÞSiðdÞ�ci � a

� �< 0: ðA:6Þ

Solving (A.6) for ci leads to:

SiðdÞ � a > ci: ðA:7Þ

Inequality (A.7) holds due to Assumption 4. Thus, o�tioSiðdÞ < 0. h


References

Aghion, P., Howitt, P., 1992. A model of growth through creative destruction. Econometrica 60, 323–351.

Baldwin, C.Y., Clark, K.B., 2003. The Architecture of cooperation: does code architecture mitigate free

riding in the open source development model? Harvard Business School Working Paper Series, No. 03-

209.

Bilodeau, M., Slivinski, A., 1996. Toilet cleaning and department chairing: volunteering a public service.

Journal of Public Economics 59, 299–308.

Bitzer, J., 2004. Commercial versus open source software: the role of product heterogeneity in competition.

Economic Systems, 28.

Bitzer, J., Schrettl, W., Schroder, P.J.H., 2004. Intrinsic motivation in open source software development,

Discussion Paper, No. 2004/19. Department of Economics, Free University Berlin.

Bliss, C., Nalebuff, B., 1984. Dragon-slaying and ballroom dancing: the private supply of a public good.

Journal of Public Economics 25, 1–12.

DeBona, C., Ockman, S., Stone, M. (Eds.), 1999. Open Sources: Voices from the Open Source Revolution.

O�Reilly, Sebastopol, CA.

Feller, J., Fitzgerald, B., 2002. Understanding Open Source Software Development. Addison-Wesley/

Longman, Amsterdam.

Franke, N., Shah, S., 2003. How communities support innovative activities: an exploration of assistance

and sharing among end-users. Research Policy 32, 157–178.

Franke, N., von Hippel, E., 2003. Satisfying heterogeneous user needs via innovation toolkits: the case of

Apache security software. Research Policy 32, 1199–1215.

Hars, A., Ou, S., 2002. Working for Free? Motivations for participating in open-source projects.

International Journal of Electronic Commerce 6, 25–39.

Hendricks, K., Weiss, A., Wilson, C., 1988. The war of attrition in continuous time with complete

information. International Economic Review 29, 663–680.

Hertel, G., Nieder, S., Herrmann, S., 2003. Motivation of software developers in open source projects: an

internet-based survey of contributors to the Linux Kernel. Research Policy 32, 1159–1177.

Johnson, J.P., 2002. Open source software: private provision of a public good. Journal of Economics and

Management Strategy 11, 637–662.

Krishnamurthy, S., 2002. Cave or community? An empirical examination of 100 mature open source

projects, First Monday 7 [www.firstmonday.org].

von Krogh, G., Spaeth, S., Lakhani, K.R., 2003. Community, joining, and specialization in open source

software and innovation: a case study. Research Policy 32, 1217–1241.

Kuan, J., 2001. Open source software as consumer integration into production. Working Paper

[www.ssrn.com/abstract=259648], date 29 July 2004.

Lakhani, K.R., Wolf, R.G., 2003. Why Hackers do what they do: understanding motivation effort in free/

open source software projects. MIT Sloan School of Management Working Paper, No. 4425-03.

Lerner, J., Tirole, J., 2002. Some simple economics of open source. Journal of Industrial Economics 50,

197–234.

Linux Counter, 2004. Online Information at www.counter.li.org, downloaded 16 June 2004.

Mustonen, M., 2003. Copyleft – The economics of Linux and other open source software. Information

Economics and Policy 15, 99–121.

Narduzzo, A., Rossi, A., 2004. The role of modularity in free/open source software development. In:

Koch, S. (Ed.), Free/open Source Software Development. Idea Group, Hershey, PA.

Netcraft, 2004. Online Information at [www.netcraft.com], downloaded 16 June 2004.

O�Mahony, S., Ferraro, F., 2005. Managing the boundary of an �Open� project. In: Padgett, J., Powell, W.

(Eds.), Market Emergence and Transformation (forthcoming).

Raymond, E.S., 2000a. Homesteading the Noosphere, Revision 1.22, 24 August 2000, first version 1998

[www.catb.org/esr/writings/cathedral-bazaar/homesteading/].

Raymond, E.S., 2000b. The Cathedral and the Bazaar, Revision 1.51, 24 August 2000, first version 1997

[www.catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/].

http://www.firstmonday.org

http://www.ssrn.com/abstract=259648

http://www.counter.li.org

http://www.netcraft.com

http://www.catb.org/esr/writings/cathedral-bazaar/homesteading/

http://www.catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/


Rosenberg, D.K., 2000. Open Source: the Unauthorized White Papers. IDG Books Worldwide, New

York.

Rossi, M.A., 2004. Decoding the free/open source software puzzle: a survey of theoretical and empirical

contributions. Discussion Paper, No. 424, Dipartimento di Economia Politica, Universita di Siena.

Shah, S.K., 2003. Understanding the nature of participation & coordination in open source software

development communities. Dissertation, Chapter 4, MIT Sloan School of Management.

Stallmann, R., 1999. The GNU operating system and the free software movement. In: DiBona, C.,

Ockman, S., Stone, M. (Eds.), Open Sources: Voices from the Open Source Revolution. O�Reilly,

Sebastopol, CA.

Stenborg, M., 2004. Waiting for F/OSS: coordinating the production of free/open source software,

Keskusteluaiheita. Discussion paper, No. 884, ETLA – The Research Institute of the Finnish

Economy.

Torvalds, L., Diamond, D., 2001. Just for fun: the story of an accidental revolutionary (HarperBusiness).

Ulrich, K., 1995. The role of product architecture in the manufacturing firm. Research Policy 24, 419–440.

Documents

Bug-fixing and code-writing: The private provision of open source software