the emergence of governance in an open source community

8/6/2019 The Emergence of Governance in an Open Source Community

1/29

THE EMERGENCE OF GOVERNANCE IN ANOPEN SOURCE COMMUNITY

SIOBHAN OMAHONYUniversity of California, Davis

FABRIZIO FERRAROUniversity of Navarra

Little is known about how communities producing collective goods govern themselves.In a multimethod study of one open source software community, we found thatmembers developed a shared basis of formal authority but limited it with democraticmechanisms that enabled experimentation with shifting conceptions of authority overtime. When members settled on a shared conception of authority, it was more expan-sive than their original design. A statistical test of the predictors of leadership rein-forced this finding. By blending bureaucratic and democratic mechanisms, the gover-nance system evolved with the communitys changing conceptions of authority.

One of the most significant problems in organi-zational scholarship concerns how social collec-tives govern, organize, and coordinate the actionsof individuals to achieve collective outcomes.Many classic works of organizational scholarshiphave grappled with this problem, leading to a vari-ety of proposed optimal organizing forms and gov-ernance systems (Blau, 1955; Gouldner, 1954;March & Simon, 1958; Ouchi, 1979; Stinchcombe,1959). Most attention has been devoted to bureau-cratic forms, with very little attention given to com-munity forms of organizing.

However, organizational forms that do not use abureaucratic basis of authority have a long history(Coleman, 1970, 1974, 1993). Such forms have not

received the attention they deserve (Marsden, 2005;Stern & Barley, 1996), perhaps because the institu-tional persistence of the dominant corporate bu-reaucratic form (DiMaggio & Powell, 1983; Zucker,1977) inhibits other sources of variety (Stinch-combe, 1965). In particular, relatively little isknown about the process of organizing in commu-nitiesthat is, how social groups accomplish thecritical task of coordinating the actions of multipleindividuals to achieve important outcomes (Heath& Sitkin, 2001; Weick, 1979). Furthermore, under-standing community forms of organizing is impor-tant to organizational theory because greater varietyin organizational forms increases the range of toolsor solutions that society can bring to social prob-lems (Hannan & Freeman, 1989; Rao, 1998; Ro-manelli, 1991; Stinchcombe, 1965).

This research takes a step toward filling this gapby examining how a social group designed a sharedbasis of authority and thus, a governance system. Inconducting this research, we heeded Heath andSitkins (2001) advice to devote more attention tothe general processes of organizing that help revealhow groups of people carry out their goals. Histor-ically, the inability to develop a shared basis ofauthority has led many collectivist groups to fail(Coleman, 1980; Etzioni, 1959; Harrison, 1960;Swidler, 1979). Thus, governance in communityforms not only offers a critical lens into concep-tions of organizational control (Fligstein, 1990) butalso provides an indicator of how communities can

be sustained (Rothchild & Russell, 1986).Our examination of the emergence of a gover-

nance system in an open source software commu-nity shows how a community uses a formal bu-

This research has been supported by the Stanford Cen-ter for Work, Technology and Organization, the StanfordTechnology Ventures Program, the Social Science Re-search Council, the Harvard Business School Division ofResearch, a Spanish Government Research Grant (Minis-terio de Educacion y Ciencia - SEJ2006-11833) and thePublic-Private Sector Research Center at IESE BusinessSchool. The data collection and processing efforts of John

Sheridan, Vikram Vijayaraghavan, Daniel Berch, Mari-ano Belinky, and Jordi Colomer and editorial supportprovided by Clare Flaherty and Alyssa Razook weremuch appreciated. We thank Steve Barley, Beth Bechky,Bruno Cassiman, Michael Cohen, John King, MarkMortensen, Woody Powell, Matteo Prato, Marc Ven-tresca, JoAnn Yates, and participants in Harvard Quali-tative Inductive Research and the Strategy Research Fo-rum for their helpful comments on previous versions. Wealso thank Sara Rynes and our reviewers for thoughtfuland detailed comments that improved the article. Allerrors or omissions are our own. Both authors contrib-uted equally to this work.

Academy of Management Journal

2007, Vol. 50, No. 5, 10791106.

1079Copyright of the Academy of Management, all rights reserved. Contents may not be copied, emailed, posted to a listserv, or otherwise transmitted without the copyright holders express

written permission. Users may print, download or email articles for individual use only.


2/29

reaucratic basis of authority to reinforce itsmeritocratic norms. However, this approach de-pends upon democratic mechanisms that notonly limit that basis of authority, but also allowthe system to adapt with members changing in-terpretations of leadership. After showing howthe community introduced formal authority, we

analyze conceptions of authority to explore howcommunity members interpreted leadership overtime. We find that although technical proficiencyis an important criterion for leadership in such agroup, it is not sufficient. Despite communitymembers espoused preferences for hands-offleaders, skill in building the organization be-came increasingly important over time. We showthis not only through our analysis of espousedconceptions of authority, but also by modelingthe behaviors most likely to be associated withthe communitys leadership. We conclude byfurthering a grounded theoretical perspectiveon governance in communities and explore therelevance of these findings for traditionalorganizations.

COMMUNITY FORMS OF KNOWLEDGE

SHARING AND PRODUCTION

To further the research agenda describedabove, we focused on communities involved inknowledge sharing and production. Communityforms appear to be increasingly important tosolving problems and sharing knowledge (Brown

& Duguid, 1991, 2000, 2001; Hargadon & Bechky,2006; van Maanen & Barley, 1984) and may bewell suited to an economy that relies upon theproduction and diffusion of knowledge (Adler,2001; Powell & Snellman, 2004). More broadly,theorists now recognize that community formscan provide an alternative to market and hierar-chical forms of organization and production(Adler, 2001; Bradach & Eccles, 1989; Ouchi,1980; Powell, 1990). Yet little is known abouthow communities organized around productiongovern themselves.

Production communities typically shun bu-reaucratic elements such as an authoritative di-vision of labor (Rothschild-Whitt, 1979). Thegoals of collective forms of production vary, yetthey tend to share a common means: namely, onethat embraces democratic participation in bothproduction and management (Rothschild & Rus-sell, 1986). Traditional forms include kibbutzimand cooperatives (e.g., Ingram & Simons, 2000;Kanter, 1968; Kieser, 1989; Rothschild & Russell,1986; Rothschild & Whitt, 1986; Rothschild-Witt,1979; Simons & Ingram, 1997; Swidler, 1979), but

their study has remained largely on the peripheryof organizational theorys terrain (Coleman, 1970,1974, 1993). More recently, research on commu-nities engaged in learning and knowledge sharinghas flourished.

Scholars have shown how members of occupa-tional communities and communities of practice

inside firms cooperate to further problem solv-ing, learning, and skill development (Brown &Duguid, 2001, 2000, 1991; Lave & Wenger, 1991;Pickering & King, 1995; Wenger, 1998, 2000). De-spite the fact that occupational communities ex-tend outside the boundaries of an organization(Van Maanen & Barley, 1984), this construct hastypically been used as a means to understandhow individuals exert autonomy and control overtheir work inside organizations (Bechky, 2003;Orr, 1996). Although communities of practicehelp individuals achieve their learning goals,they typically do so within the context of a firmsobjectives (Lave & Wenger, 1991; Wenger, 1998,2000). In both cases, community members areengaged in managing production not for its ownsake, but for the benefit of their employers. Thus,they are limited in the degree to which they cangovern production. Because occupational com-munities and communities of practice operatewithin an authority structure that already exists,how such forms learn to govern themselves hasnot been a focus of this research.

Scholars have also shown how online communi-ties outside firms share information and social sup-

port (Cummings, Sproull, & Kiesler, 2002; Fayard &DeSanctis, 2007; Smith & Kollock, 1999; Parks &Floyd, 1996; Parks & Roberts, 1997; Rheingold,2000). However, little empirical work has exam-ined how such communities manage production. Inmodern production communities, contributors, in-dependently of their employment context, volun-tarily collaborate to create goods or services foreither public or private benefit (von Hippel & vonKrogh, 2003). Members are typically geographicallydispersed and depend upon the Internet as a meansof communication and coordination (Kollock,

1998). Within the last decade, online productioncommunities have begun producing informationgoods such as scientific knowledge,1 art,2 generalknowledge,3 and software.

Open source software communities are the exam-ple of online production most often recognized byorganizational theorists (Kogut & Metiu, 2001; Lee

1 See www.sciencecommons.org.2 See www.creativecommons.org, ccmixtr.org, flickr.org.3 See www.wikipedia.org.

1080 OctoberAcademy of Management Journal


3/29

& Cole, 2003; Moon & Sproull, 2002; von Hippel,2005; von Hippel & von Krogh, 2003). Scholarlyanalysis of open source software communities hasaddressed status dynamics (Stewart, 2005), mem-

ber contribution patterns (Mockus, Fielding, &Herbsleb, 2002; Shah, 2005), and why individualsare likely to contribute to such efforts (Dalle &

Jullien, 2003; Hars & Ou, 2002; Hertel, Niedner, &Herrman, 2003; Lakhani & Wolf, 2005; Lerner &Tirole, 2002). Researchers have learned that opensource communities create informal and formal so-cial structures to manage membership and joiningprocesses (OMahony & Ferraro, forthcoming; vonKrogh, Spaeth, & Lakhani, 2003), but little has beendone to understand how these projects are gov-erned (see Shah [2006] for a recent exception).

Production communities may be a fledgling formof organization, yet scholars and practitioners alikesee them as increasingly important to an informa-tion- and knowledge-based economy (Armstrong &Hagell, 1996; Powell & Snellman, 2004; Sawhney &Prandelli, 2000; Seidel & Stewart, 2003; Williams &Cothrel, 2000). Production communities differ fromthe community forms that have previously beenresearched in three ways that make them theoreti-cally distinct and ripe for study. First, unlike com-munities of practice or occupational communities,production communities are not associated with asingle employer or workplace. Second, unlike on-line communities, production communities mustintegrate individual contributions into a commonpool, which can heighten interdependencies and

the need for coordination mechanisms (e.g.,Thompson, 1967). Third, production communitiesoften own the output of their efforts, and mem-

bers work toward collective goals outside of thescope of their employment (OMahony, 2003).

Taken together, these three distinctions suggestthat production communities need a way to man-age their interdependence to achieve commongoals. Yet, without the benefit of markets or hi-erarchies, they may have few resources withwhich to do so. Scholarly conceptions of commu-nity forms as ideal types tend to overweight the

roles that norms, trust, mutuality, and reciprocityplay in organizing community activities withoutaddressing how people actually coordinate theirwork to achieve collective ends (Adler, 2001). Tomove beyond ideal types, we take seriously thecomplicated nature of directing individual effortstoward a common goal without the benefit ofcontractual or hierarchical reinforcement. In anyorganization, there is a constant tension betweenfulfilling individual goals and integrating themwith a common objective (March & Simon, 1958;Ouchi, 1979). A focus on governance allows us to

explore how community forms resolve thistension.

GOVERNANCE IN COMMUNITY FORMS

Before an organization can develop a form ofgovernance, it must establish a shared basis of au-

thority (Etzioni, 1959). Organizations without aconsensual basis of authority lack an importantcondition necessary for their survival (Coleman,1980; Etzioni, 1959; Harrison, 1960). Organizationswith directly democratic forms of participation donot manage to scale well and are noted for havingdifficulty managing complexity and decision mak-ingall of which can hasten their demise (Johnson& Whyte, 1977; Rothschild & Russell, 1986; Roths-child & Whitt, 1986; Whyte & Whyte, 1988). Theneed to coordinate interdependent member activi-ties and integrate member contributions in a pro-

duction context is likely to exacerbate the need fora shared basis of authority.However, modern collective forms of produc-

tion do not tend to rely on any single one of thethree bases of authority (tradition, law, and cha-risma) theorized by Weber (1978). These formsare created with few traditions to guide them andso do not inherit any traditional basis of author-ity. Since there is no authoritative division oflabor, collective production communities do notrely upon what Weber would call a legally ration-al basis of authority rooted in position. And fi-nally, since many contributors may not have met

in person, given that such communities are usu-ally geographically distributed, developing a ba-sis of authority that rests on charisma, althoughpossible, is less likely (Wellman & Gulia, 1999;Wellman, Salaff, Dimitrova, Garton, Gulia, &Haythornthwaite, 1996).

Weber recognized that anti-authoritarian sys-tems that placed a high value on individual auton-omy existed (Weber et al., 1978), but he did notsystematically analyze the problems of authorityand power peculiar to these groups (Harrison,1960: 233; Satow, 1975; Willer, 1967). However,

developing some form of authority is a particularproblem for voluntary social groups that can lead tothe compromise of their goals:

The ideology of voluntary social groups in Americatends to be anti-authoritarian. The constituency ofthese groups is distrustful of centralization and fur-ther rationalization of their organizations. However,to achieve the imperative goals of these voluntaryassociations, bureaucracy is necessary, social ten-sion increases, and the problems of authority andpower become increasingly acute. (Harrison, 1960:232)

2007 1081OMahony and Ferraro


4/29

For a production community to retain the in-terest and commitment of voluntary members,any form of authority introduced must simulta-neously preserve democracy and accountabilityto its members. To achieve the efficiencies forwhich bureaucracy is known, some form of ra-tionalization is necessary (e.g., Chen &

OMahony, 2007). How communities resolve thisconflict is underexplored, largely because of un-resolved theoretical issues in the conceptualiza-tion of bureaucracy.

In a bureaucratic system, a legal and rationallybased positional authority decouples the authorityof a person from that of his or her position toprevent incumbent patrimony or favoritism (We-

ber, 1978). In Webers eyes, meritocracy was aninevitable outcome of bureaucratic rule. Thosewith more technical competence were rewardedwith positional authority; that is the essence of theexercise of control on the basis of knowledge(Weber, 1978). Parsons (1947) and Gouldner (1954)were among the first to note that Webers notion of

bureaucracy could lead to contradictory outcomes,arguing that positional authority and technicalcompetence could be decoupled and lead to bu-reaucracy without meritocracy.

Adler and Borys (1996: 62) traced organizationscholars conflicted approach to bureaucracy

back to this source of ambiguity and proposed away to help reconcile conflicting evidence on theimpact of bureaucratic rule. They argued that

bureaucratic rules can be applied to either help

people in their jobs (enabling), or to control them(coercive). They suggested that enabling bureau-cracies are better suited for creating knowledgeand that autocratic bureaucracies are bettersuited for predictable environments. Adler ex-tended this line of thinking by exploring the con-tours of community forms, tentatively conclud-ing that community forms of knowledge creationare likely to grow only if community norms are

balanced by hierarchical rules to ensure stabil-ity and equity (2001: 228; see also Adler & Heck-scher, 2006). This view suggests that community

forms must blend some type of positional author-ity with more participatory and democraticmeans. However, little empirical work has ex-tended this theoretical framing.

Recent scholarship on open source communi-ties suggests that any governance system intro-duced to them must be meritocratic to attracthigh-quality contributions from voluntary mem-

bers (Lee & Cole, 2003; Kogut & Metiu, 2001;Moon & Sproull, 2002). By rewarding merit withgreater status, responsibility, or opportunities toenhance development (Stewart, 2005; von Krogh

et al., 2003), production communities can satisfycontributors needs for recognition and reward inways that their work lives may not (e.g., DiMag-gio & Anheier, 1990; Drucker, 2001). Although itis widely recognized that successful open sourceprojects often have strong leaders (Mockus et al.,2005; Moon & Sproull, 2002), few have examined

the roots of such governance systems.To further a grounded theoretical understand-ing of how communal forms organize, we col-lected both qualitative and quantitative data toexamine how one open source community de-signed and implemented a governance systemover 13 years. We identified four distinct phasesof this process: de facto governance, designinggovernance, implementing governance, and sta-

bilizing governance. We found that the failure ofautocratic rule in the de facto governance phasespurred the design of a formal governance struc-ture that included a positional basis of authority.To reinforce the communitys meritocraticnorms; this bureaucratic basis of authority wassimultaneously limited with a directly demo-cratic mode of governance. However, the role of aleader in the community remained open to inter-pretation. Thus, we evaluated espoused concep-tions of authority in the implementing gover-nance and stabilizing governance phases to learnhow members interpreted the leadership rolesthey created. Finally, to move beyond analysis ofthe rhetoric of the community, we investigatedwhat leadership behaviors became most valued

by members of the community in their finalphase of governance.

This research provides two distinct theoreticalcontributions. First, we clarify earlier specula-tion about how production communities organize(e.g., Adler, 2001; Adler & Borys, 1996) and findevidence of a limited form of bureaucracy that ismore enabling than it is coercive. The simulta-neous introduction of democratic and bureau-cratic practices not only limits the reach of bu-reaucracy, but also allows members toexperiment with varying interpretations of au-

thority. These findings provide insight as to howcommunity forms develop both a shared basis ofauthority and a governance model, thus speakingto a fundamental, long underaddressed questionfor organizational theory (Coleman, 1980; Harri-son, 1960; Satow, 1975). Second, we show thateven in a community of open source program-mers that espouses the value of technical contri-

butions above all else, members conceptions ofleadership change over time to increasingly valueorganization-building contributions. Democraticmechanisms enable the communitys governance



5/29

system to adapt as members learn how to inter-pret leadership and authority in a communitycontext. This observation suggests an evolvingand context-dependent notion of meritocracy andthat democratic mechanisms serve an importantadaptive function in emerging organizationalforms.

PART I: INDUCTIVE APPROACH

In Part I, we use ethnographic and archival datato explore how the governance system designed bythis community operated over a 13-year period,and how different conceptions of leadershipemerged that invoked varying degrees of authorityover time. An inductive approach is particularlyapt for examining phenomena that are emergent orpoorly understood (Strauss & Corbin, 1990), allowsroom for the unanticipated, and is most suitable for

grounded theory building (Edmondson & McMa-nus, 2006)the goal of this research. In Part II, withquantitative data gathered from the same setting,we pursue a deductive approach to examine the

behaviors that were most important to communitymembers in filling the leadership positions theycreated.

Research Setting

We used theoretical sampling (Glaser & Strauss,1999; Strauss & Corbin, 1990) to select an open

source community that had two features that wouldallow us to explore governance in depth: long du-ration and leadership turnover. Successful leader-ship turnover implies that leadership positionshave become institutionalized or decoupled fromthe founder of a project. Of several open sourcesoftware communities studied in the first authorsprior research, the Debian community was selectedfor further analysis because its longevity (it wasformed in 1993) exposed it to governance issuesthat occur only over time. Preliminary fieldworkalso revealed that the Debian community had, un-like other open source projects previously exam-ined (e.g., Lee & Cole, 2003; Moon & Sproull, 2002;Raymond, 1999), experienced frequent leadershipturnover since the founder left the project in 1996.As one informant explained, this was perceived to

be a strength of the project and a source oflongevity:

I have complete confidence in the Debian project tofind its own path to the future. Four different projectleaders over the past five years have done nothing toshake that confidence. We have shown ourselvesquite capable of thriving despite changes in leader-

ship, and without leaders who felt a strong desire tochange Debians vision.

As of this writing, nine different leaders have ledDebian over 13 years, suggesting that the commu-nity has created a mode of governance independentof its founder.

Debian is a free operating system that uses theLinux kernel developed by Linus Torvalds; it is aLinux distribution. An operating system is the setof basic programs and utilities that make computersrun. The kernel is the most fundamental programon a computer that manages demands on system

resources: It allows you to run multiple programssimultaneously. According to industry analysts,Debian has 25 percent of the market for Linux dis-tributions, second only to the Red Hat distribution,which is produced by Red Hat, a publicly tradedcompany (Netcraft, 2005). Over 1,000 Debian com-munity members in over 40 countries contribute tothe development of the Debian Linux distribution(which comprises over 9,000 packages of code).Developers who contribute to the community con-sider themselves to be part of an association or aclub, much like your local LUG [Linux user group]or Rotary, with the principle exception being that

we hardly ever meet face to face.4 Although theDebian community does not sell the code they pro-duce, over 150 vendors commercially distribute theprojects software. In return, Debian receives cor-porate support and equipment donations from atleast ten firms, two of which are Fortune 500 firmscommercializing Linux (e.g., Casadesus-Masanell &

4 From step 2, Debian New Maintainer process, locatedat http://ukdebian.mirror.anlx.net/devel/join/nm-step2.

TABLE 1Data Sources

Data Source InterviewsProject

Records

Debian project leaders 4Debian contributors 14User contributors 30Leader candidate platforms (1999

2006)34

Election debates (2000, 2003,200506)

4

Meetings (19982005) 32Project general resolutions (1999

2006)5

Mailing list postings (19982006) 17,317Project documents (constitution,

policy manual, social contract)100 pages



6/29

Ghemawat, 2006; Fosfuri, Giarratana, & Luzzi,forthcoming).

Methods

Data on the Debian Linux community were col-lected as part of a larger ethnographic study of the

open source community. Table 1 lists the sources ofdata used for the current study. Forty-eight semi-structured interviews were conducted with Debiancontributors, focusing on membership, sponsor-ship, decision making, and governance. These datawere supplemented by observations and analysis of34 leader candidate platforms, 4 election debates,notes from 32 meetings, 5 general resolutions, and17,317 postings to the project mailing list. Wesearched mailing lists and collected project datafrom online archives to identify topics related toleadership and governance. These archives in-cluded the projects constitution, policy manual,reference manual, social contract, charter, and by-laws. Triangulation among multiple sources of ev-idence provided greater depth and accuracy by al-lowing us to draw upon different perspectives(Campbell & Fiske, 1959; Yin, 1994).

We analyzed these ethnographic data using AtlasTI software, an open coding application for quali-tative data. Our analysis proceeded through fourrounds of coding. In the first round, we codedgovernance decisions and events in chronologicalorder; the recall of Debians second leader and thesubsequent creation of a constitution that outlines

the parameters of a leaders authority are examplesof such events.

In the second round of coding, each author inde-pendently identified phases in the evolution ofDebians governance system: (1) de facto gover-nance (199397), (2) designing governance (199799), (3) implementing governance (19992003),and (4) stabilizing governance (200306). We iden-tified these phases by noting the presence of defin-ing governance events from the first round of cod-ing. Table 2 lists the events, examples of evidencefor them, and information on the type and strength

of evidence. We resolved any discrepancies be-tween our independent codings by revisiting anddiscussing the data and coding.

In the third round of coding, we wanted to deter-mine how conceptions of authority evolved. After1999, the Debian community formally elected lead-ers. Thus, we independently coded data on leadercandidates electoral platforms and election de-

bates from 1999 to 2006. In these leadership plat-forms and debates, leader candidates articulatedtheir visions for the project, their ideas to improveit, and their claims as to what they would do as

leaders. They also made prescriptive statementsabout what they thought a leader should andshould not be able to do in the community. Weassessed leader candidates degree of authority byevaluating the decision-making power that candi-dates associated with the leadership position. Afterresolving minor disagreements in classification, we

identified and named five conceptions of leader-ship that varied in their degree of authority and theextent of their focus on organizational versus tech-nical concerns: (1) hands-off leader, (2) technicalmanager, (3) visionary leader, (4) organization

builder, and (5) organization leader. Table 3 depictsthese sequential conceptions and provides exem-plary evidence for them.

We replicated this coding with available datafrom de facto leaders from the period 199398. Weasked an external researcher to classify the plat-forms independently and compared this classifica-

tion with ours. The independent researcher ratedthe leadership platforms on the basis of the descrip-tions articulated here. Comparing this researcherscodes with ours, we calculated our interrater reli-ability using Cohens kappa and obtained very sat-isfactory results ( .80; 84 percent agreementrate). After considering the relevance of the dis-agreements encountered, we deemed it safe to pro-ceed with our original coding. In identifying thesefive conceptions of leadership, we noticed a shiftfrom technical to organization-building concerns.To further understand the contours of this shift, we

studied the content of leadership platforms at an-other level.In the fourth round of coding, each author inde-

pendently coded the 34 leadership platforms andclassified parts of the texts as focused on address-ing organizational issues, engaging in technical dis-cussions and debates, or providing biographical in-formation. One platform statement from 2003provides an example of a text item coded as [re-lated to] organizational issues: I think one of themain tasks of the Project Leader is to coordinateand motivate peopleto lead. This is why I saidthat while the external functions of the DPL areimportant, the internal functions are even moreimportant. While it is quite hard to lead a projectconsisting of so many people with so diverse ex-pectations and personalities, I think that it can ac-tually be done. Thus, my main aim as DebianProject Leader is to lead, motivate and coordinate.An example, from another 2003 platform, of textcoded as [related to] technical issues is, Simi-larly, while everyone complains about the releasecycles of Debian, it is not clear at all how frequentlywe should release. For example, SuSE and Red Hat



7/29

have introduced offerings of their distributions thathave similar release cycles to that of Debian. Thereare many reasons why you can upgrade your sys-tem only every two years. Yet, there are also users

who want the newest software and like to upgradetwice a year.

Finally, an example of text, also from 2003,coded as [related to] biographical information is

TABLE 2Phases of Governance in an Open Source Community

Defining Eventa Exemplary Evidence Evidence Strengthb

Phase I: De facto governance,19931997

Autocratic leadership emergesand is challenged

But the big thing, which changed with [the 2nd DPL],like he was really managing everything and kept tightcontrol, which, was plausible because Debian wasmuch smaller. Then actually [with the third leader]he never wanted to have someone like [that] again,and that is why he started to write the constitution,which splits the power. (Debian developer member)

Medium

Phase II: Designing governance,19971999

Formal authority is developed The Project Leader may . . . define an area of ongoingresponsibility or a specific decision and hand itover to another Developer or to the TechnicalCommittee; . . . lend authority to other Developers;. . . make any decision which requires urgentaction; [or] for whom no one else hasresponsibility. (Debian constitution, article 5.1)

High

Formal authority is limitedthrough democratic means Together, the Developers may: 1) Appoint or recallthe Project Leader. 2) Amend this constitution,provided they agree with a 3:1 majority. 3) Make oroverride any decision authorised by the powers ofthe Project Leader. (Debian constitution, article 4.1)

High

Phase III: Implementing governance,19992003

Varying conceptions of formalauthority are debated

Its not clear exactly what the DPL is supposed to do.What do people expect? Because Debian was sobig, everyone expects something else. So, somepeople say, Yeah the DPLs should only go toconferences, and present Debian to the outsideworld, but he shouldnt do anything internalbecause that is working anyway. (Debiandeveloper member)

High

Community members electleaders through democraticmeans

Ill cast my DPL vote towards the end of the cycle, asusual. Heres why: At the start of the cycle, I hadntmade up my mind. . . . I havent finished readingthe candidate platforms and debate material yet.. . . This year, since once again I couldnt attendthem live, I have to read them afterward, whichtakes time. . . . Voting in Debian is just like votinganywhere else, you often have to do a lot ofreading to understand the issues. (Debian developermember)

High

Phase IV: Stabilizing governance,20032006

A shared conception of formalauthority emerges

When community members became disgruntled with aleaders actions, they worked within the system byproposing a General Resolution to recall the leader.

However, members voted to discuss the matterfurther and, in a second vote, the leaders authoritywas re-affirmed. (general resolutions, 2006)

Medium

a All three types of datainterviews, secondary sources, and project documentationprovided evidence for for all four phases.b High indicates that a finding was apparent in most of the data. Medium indicates a finding was consistently repeated. Low

indicates that a finding was suggestive.



8/29

TABLE3

De

bian

Pro

jectLea

der

Conceptionso

fAuthor

ity,1

993

2006

Conceptions

ofAuthor

ity

Degreeo

f

Pos

itiona

l

Author

ity

Exemp

lary

Ev

idence

b

De

FactoGoverna

nce

Des

ign

ing

Governance

Imp

lementing

Governance

Stabi

liz

ing

Governance

1993

96b

199

6

97b

1998b

1999

2000

2001

2002

2003

20

04

2005

2006

Hands-off

leader

Limited

The

DPLshould

h

aveafairly

h

ands-off

approach...

the

D

PLwillneedto

d

elegatesomeof

h

isresponsibilities

toothers.

2

1

1

1

1

The

DPListhe

p

ublicfigurehead

o

fDebian.

(2000

leaderelection)

Technical

manager

Medium

Ac

hronicproblem

inDebianhasbeen

o

uroverlylong

releasecycle,

if

electedthisshall

b

emymajorfocus.

(2000leader

election)

1

1

1

1

1

Visionary

leader

Medium

Ith

asbeenalong

timesinceDebian

h

adaclearly

articulatedvision.

Itstimetofixthat

.

..

thereisno

reasonthatwe

canteventuallybe

a

trulyuniversal

o

peratingsystem!I

cantimaginea

m

orecompelling

v

isionforour

future.

(2002

leaderelection)

1

1

1

Organization

builder

High

We

havelearneda

h

arshlessonabout

theorganizational

s

tructurein

D

ebian.

Debianis

c

ontinuously

g

rowingand

c

hangingandwe

n

eedtoknowhow

tohandlethat.

O

ldstructuresand

ideaswillneedto

b

erevised,and

n

ewoneswill

a

rrive.

(2000

leaderelection)

1

2

2

1

1

1

1

1

Continuedonnextpage


9/29

TABLE3

Continue

d

Conceptions

ofAuthor

ity

Degreeo

f

Pos

itiona

l

Author

ity

Exemp

lary

Ev

idence

b

De

FactoGoverna

nce

Des

ign

ing

Governance

Imp

lementing

Governance

Stabi

liz

ing

Governance

1993

96b

199

6

97b

1998b

1999

2000

2001

2002

2003

20

04

2005

2006

Organization

leader

High

Lea

dershipin

v

oluntaryorganiza-

tionslikeDebian

lacksthe

instrumentsof

p

owerthatare

u

sedinbusiness

environments

....

D

ebiansgoalisto

p

roducean

excellentfree

o

peratingsystem

andhavefun

d

oingso.

The

leaderstaskisto

k

eepthatvision

aliveandvivid

andtoencourage

p

eopletowantto

gothere.

(2005

leaderelection)

1

1

4

4

Autocratic

leader

Veryh

igh

Wellprojectleader

w

asessentially

d

ictator.Because

therewasno

formalstructure

w

hatsoeveratthat

time.

(1996

97

leader)

1

a

Thenumberinacellindicates

how

manyleadercandidatesarticulate

daspecificconceptionofauthorityin

eachyear.Boldtypeindicatesthatoneofthedeveloperswho

articulatedthatconceptionofautho

ritywontheelectionthatyear.

b

DPListheDebianprojectleader.

c

Leadershipwasinformalinthis

year,whichwaspriortotheconstructi

onofformalauthorityviatheconstitution.


10/29

the following: I hold a Master degree in Philoso-phy and have recently completed a Master of Sci-ence in Psychology. Im currently doing a Master ofSoftware Systems Engineering at the University ofMelbourne and am looking forward to pursuing aPhD in Software Engineering about Debian andFree Software afterwards. We counted the number

of words dedicated to each of these three themesand compared their evolution. To ensure the ro- bustness of our results, we asked another re-searcher to code the platforms independently andcompared his results to ours. There was a .85 cor-relation in the results for organizational issues, .95for technical issues, and .90 for biographical con-tent. Given these results, we deemed it safe to pro-ceed with our original coding.

Analysis and Results

In this section, we present results of our anal-ysis of our qualitative data to show how the com-munity transitioned from a de facto governancemodel to one that integrated positional authoritywith directly democratic means. We then tracehow community members subsequently inter-preted a leaders authority. In Part II of the arti-cle, we present a model based on quantitativedata from the first year (2003) of the final phase(stabilizing governance) of our study. This modelpredicts which developers were the most likelyto become members of the projects leader-ship team.

Phase I: De facto governance (199397). Wefound that for its first five years, the Debian projectoperated reasonably well without a formal meansof representing its contributors in project gover-nance. The founder of the project considered con-tributors opinions as they were expressed but hadthe final say on decisions. When the founder leftthe project to pursue personal interests, he infor-mally passed the leadership to one of his trustedlieutenants, who maintained a very active role onthe project. The decision to transfer authority wasmade unilaterally, and the second leader continued

in the absence of any formal governance process toprovide contributing members with formal repre-sentation or to resolve disputes. However, he didhold a more expansive conception of the leadershiprole than did the founder. We found that subse-quent misinterpretation of the appropriate role of aleader in the community led to the failure of auto-cratic leadership and the construction and delimi-tation of positional authority.

Without agreement on the leaders authority,members resisted what some characterized as auto-cratic leadership. Aware of the problem, the second

leader recalled, There was no formal structurewhatsoever at that time. You had to lead wherepeople would follow otherwise they would justwalk off. When the second leader began referringto his role as that of president and initiated aseries of organization-building projects to manageDebians growing scale, community members

balked at his actions. In assuming the title of pres-ident, the second leader had essentially assignedhimself positional authority without developing ashared basis for it.

The project leader felt this strain and, to bothenhance his legitimacy with project members anddevelop a shared basis of authority, proposed thatthe community elect a board of directors. In a mes-sage to the community, he explained that thiselection relieves me of the (often quite awkward)position of being the only person with any realauthority over Debian. His intent was to create aleadership team for Debian that can survive thedeparture of any team member. In the months thatfollowed, members lost faith in his leadership andasked him to withdraw from the projects first elec-tion. A number of developers convinced me that itwas time for a leadership change, and I thus with-drew from the project leader election. Althoughthe second leader had initiated the design of a moreformal means by which project members couldachieve representation in governance, he mighthave introduced too many changes too quickly forproject members concerned about a potential con-centration of power. The recall of the second de

facto leader led directly to a phase in which mem-bers designed a governance system that could rep-resent their interests.

Phase II: Designing governance (199799). Wefound that community members shared experiencein recalling the second leader inspired the design ofa governance system that could operate indepen-dently of any one persons conception of leader-ship. The third leader to assume the title did soonly by vowing to be less directive than the secondand leading the collective drafting of a constitutionto formalize leadership roles, rights, and responsi-

bilities. As one community member recalled, [Thethird project leader] said we should formalizethings and come up with a structure that couldaddress the problems faced by a Debian ProjectLeader. . . . The project leader was looking at theway the project was going . . . and saying, no way isthis going to work, we have to do something. Thethird leader led a debate on the mailing list inwhich a constitution was drafted, revised, and fi-nally ratified by 357 developers. As the third leaderexplained, We basically ratified the constitutionusing itself. That was sort of a test case as well,



11/29

which went pretty well, so we use it for projectleader elections. The governance system designedat this time embraced two important and poten-tially contradictory elements: (1) formal positionalauthority and (2) limitation of that authoritythrough democratic means.

Positional authority is rooted in a defined role,

decoupled from a persons individual character-istics; it separates the personal from the officialand provides a legal-rational basis of authority(Coleman, 1980; Merton, 1940; Weber et al., 1978).The Debian constitution outlines positional author-ity by specifying the rights and limitations of con-tributing members and positions of power, such asthat of Debian project leader (DPL). As one memberexplained, We had this DPL project leader but wenever really said what he could or could not do. Hehad been doing things, so it [the constitution] kindof codified what he had been doing or what wewanted to be doing and what we did not want himto be doing. With the constitution in place, theproject held its first election in January 1998, intro-ducing the role of project leader (as opposed topresident). However, we found that Debian mem-

bers were only interested in supporting a positionalbasis of authority if this role was also limited inways that facilitated democratic control by the restof the community.

We found that positional authority, once created,was limited in four ways that preserved democraticrule. First, the Debian constitution requires thosewith positional power to defer to the wishes of the

collective by making decisions which are consis-tent with the consensus of the opinions of the de-velopers. In practice, this tenet was emphasizedoften, and the project leaders ability to make uni-lateral decisions explicitly questioned. For exam-ple, years later, a participant in the 2006 leadershipdebate emphasized that technical decisionsshouldnt be made by the DPL, period. In re-sponse, another participant wrote, The DPLs roleis to lead discussion within Debian, and technicaldiscussions are what makes Debian great. Thatsdifferent from actually making the final decision

though, which generally isnt the DPLs place. Theconcept of leader in this community is thus basedon consensus building as opposed to autocraticrule, and the power of a leader only comes from hisor her deference to democratic values.

Second, a Debian project leader is subject to thesame rules as any member; he or she is not entitledto special privileges. In practice, this means thatthe project leader has no more power over whatgoes into Debians code base than any other mem-

ber. The authority that comes with the role is justenough to encourage consensus building. As an-

other community member explained, The DPL inthis case is just a normal developer, with a highersoap-box. People are more likely to listen to himand will perhaps decide to follow his attempts atmoderation. Just like a developer, a project leadercan only enact a policy change through a generalresolution, which must be approved by a majority

of members. Developers vying for the leadershiprole realized that they thus needed a rationale as towhy they wanted the position. For if a leader didnot have more authority than any other member,why would one want to pursue the position? Awinning candidate in 2006 admitted as much whenexploring this question: I dont believe this [theDPL position] would dramatically alter my workfor Debian, rather it would allow me a bit moreflexibility in achieving the goals I just mentionedand thus let me give them a higher priority.

A third limit on positional power is the failsafe

measure of recall by the collective via general res-olution. Any member has the right to propose ageneral resolution that can counter a leaders ac-tions. As one project leader candidate noted, TheDPL is not particularly empowered to stand againstthe will of the developers, since they can overruleanything he or she does with a General Resolution[GR]. However, a GR is a weighty process and a DPLwho consistently acts in discord with the will ofthe developers can do damage simply by wastingthe Projects time. Our analysis of the history ofuse of general resolutions noted that they wereused very rarely (five times in eight years).

The fourth way that democratic rule constrainspositional authority is through a countervailingsource of authority. For example, projectwide de-cision-making power is split between the projectleader and a technical committee empowered todecide any technical matter where developers ju-risdictions overlap. The technical committee can-not introduce new proposals but has the authorityto resolve disputes. In order to overrule a devel-oper, a supermajority (three-fourths) of the commit-tee must agree; in effect, consensus is mandated. Asone long-time member explained, the technical

committee actually has more power than the DPLin some regards and further limits positionalauthority.

The technical committee is able to say, we havelooked at both sides of the discussion, if we do ityour way, every single maintainer in Debian has torecompile his packages, we just dont think that is agood idea. So they will say, you know they willvote against you. And that is what it really is for, iswhen the DPL cant really say it, when the rest ofDebian cant decide or wont decide or whatever, the



12/29

DPL says fine, we will decide with the technicalcommittee.

The Debian project leader can call upon the tech-nical committee to help reach a decision but cannotforce a decision, so the leaders ability to unilater-ally settle disputes is limited.

By approving the constitution, project membersdeveloped a shared basis of positional authority.The four mechanisms described above limited thereach of bureaucratic rule by reinforcing demo-cratic rule by community members as a whole. Inthe next two phases, the integration of democraticmechanisms also ensured that the governance sys-tem, once implemented, could evolve with thewishes of the collective.

Phase III: Implementing governance (19992003). In 1999, with the constitution ratified,Debian developers began electing project leadersfor one-year terms, effectively initiating a phase

of experimentation with the leader role. Candi-dates nominated themselves and posted leader-ship platforms on the Web site outlining theirgoals for the project nine weeks before the end ofthe previous leaders term. Platforms were de-

bated in a three-week polling period that pro-vided ample time for members from all timezones to participate. A long polling period wasimportant so that volunteers who did not work onthe project every day, or even every week, had achance to vote. Participation in early leader elec-tions ranged from 51 to 60 percent and somewhat

declined (to 43 percent) in later years.Although most developers happily went about

their work without too much thought to gover-nance, a leader could now be singled out when thecommunity ran into difficult or ambiguous situa-tions, and our data show that members valued this.The year following the passage of the constitution,one project leader candidate noted that it intro-duces a bit of official rules and politics, but I thinkit will allow us to work as the sort of organizedanarchy that we have always used while addingsome much needed safety nets. Still, a governance

system designed on paper had to be put into prac-ticethat is, Debian members had to interpret ex-actly what this new role would entail. Our ethno-graphic data indicated that our informants varied agreat deal on their interpretation of the projectleader role. To provide better traction on how theleader role was interpreted, we turn to our analysisof the leader candidate platforms.

Given the importance the community placed ondelimiting positional authority in phase II, design-ing governance, we expected community membersto prefer hands-off leadership. However, our data

suggested otherwise, as a hands-off conception ofleadership never received a majority vote fromcommunity members. Table 3 indicates how ofteneach conception of authority was represented ineach election year and which one won the majorityvote.5 We found that a hands-off conception ofauthority was characterized by a belief in the self-

organizing ability of the community and the dangerof expanding the authority of the project leader. Forexample, a leader candidate in 1999 stated that hedidnt see the project as something that can besteered or directed, and submitted no specificplan in his leadership platform. A candidate in2001 stated that the leader role was important butlimited, with the majority of the power to act right-fully left in the hands of developers. Despite thecommunitys interest in limiting positional author-ity, no leader won an election with such a platform.

The technical manager conception of authorityfocused on the coordination of technical work.These leader candidates were concerned withshortening and enhancing the predictability of re-lease cycles. Technical managers focused on engi-neering management skills and tools to remove ne-glected packages, reduce bugs, and improve thesoftware development process. Accomplishingthese goals would require more authority thanhands-off leadership entailed. For example, a can-didate in the 1999 elections wanted to create astable and bug-free distribution for our users anddevoted most of his election platform to specifictechnical issues, arguing that once there is a deep

freeze, a group should be assigned to assess the bugs affecting the current frozen distribution.6

Technical managers also never won an election.Candidates with a visionary leaderconception of

authority focused on the need for a cohesive projectvision, without advocating specific technical or or-ganization-building activities. These leader candi-dates argued that the community needed to definea clear vision for the future. However, they sug-gested that it was their prerogative to define suchvisions, implicitly questioning the communitys

5 Although the first three leaders did not create plat-forms nor run for office, we coded their conceptions ofauthority based on our interview and mailing list dataand included that data in Table 3. Inclusion of these dataallow for a comparison of the evolution of interpretationof authority over the projects lifetime (19932006).

6 Code in deep freeze cannot have new featuresadded to it. This leader wanted to stop the addition ofnew features (which was more interesting to volunteercontributors) and assign people to work on fixing new

bugs (which was less interesting and more mundanework) so that the release could be produced.



13/29

ability to collectively do so. Visionary leaders feltcomfortable taking unilateral initiatives consistentwith their visions, without necessarily makingthem collective efforts. For example, a winningcandidate in 2002 stated, Debian has achievedsome wonderful results, but whether we will con-tinue to improve is largely a function of how moti-

vated we are. My experience leading volunteer ef-forts suggests to me that the best motivators [have]a strong shared vision which each participant canfeel connected to, and processes that allow contrib-utors to see results from their efforts. Leaders withvisionary platforms won elections in 1999 and2002 but not after 2002.

Some candidates espoused a conception of au-thority that emphasized skill as an organizationbuilder and the ability to develop organizationalstructures and processes to improve the commu-nity as a whole. Organization builders proposedprojects that were more organizational than techni-cal. For example, an unsuccessful candidate in the2001 election proposed culling developers from theproject who were no longer really contributing. Ipropose that we experiment with and ultimatelyapply, automated tools for tracking package anddeveloper activity, and act accordingly, this can-didate stated. This proposal, which would haverequired explicit monitoring of members, wasnever implemented. Such a change would obvi-ously have expanded the Debian project leadersauthority to new domains. Candidates with organ-ization-building platforms won elections in 2000

and 2001. Phase IV: Stabilizing governance (200306).

Variation in conceptions of leadership that pre-vailed throughout the third phase began to reachsettlement with the emergence of a new conceptionof authority, the organization leader, in 2003 (seeTable 3). Organization leader platforms connected

both organization-building and technical activitiesto the projects vision and goals. Unlike organiza-tion builder candidates, who often presented ex-tensive lists of process improvement projects,candidates with an organization leader concept fo-

cused on the challenges of motivating volunteersand aligning their interests with those of the com-munity. These leader candidates were more likelyto recognize the importance of communication,culture, and relational skills relative to proceduralimprovements. One unsuccessful candidate in2005 argued that the overall goal is to makeDebian a fun and rewarding context to work andspend time in, so much so that one misses andlongs for it when one cant be or work on in it. Toachieve this goal, this candidate recommendedsmall teams . . . , a more friendly and helpful en-

vironment . . . , making people aware of their lead-ership role . . . and having more frequent real-lifemeetings.

Organization leaders openly acknowledged thatalthough there were many things they would like tochange, their ability to implement them was lim-ited. They thus recognized that powers of persua-

sion would be critical, given the limited authorityassociated with the project leader position. For ex-ample, an unsuccessful 2006 candidate said:

I must also acknowledge the fact that the DPL doesnot have the power to simply impose changes ashe/she sees fit. The best that the DPL can do here isto encourage us to improve, sometimes by discus-sion and debate and sometimes by leading by exam-ple. . . . My own priority would be to fix some of thesocial issues first, as these are most pressing and inmy opinion the most likely to cause long-term dam-age to the project.

Like visionary leaders, organization leaders wereaware of the need to develop a compelling visionfor the community. However, they did not think itwas their job to do so alone. Rather, they saw thejob of the leader as corralling and organizing mem-

bers around a common vision. Organization leaderswere also more cognizant of the limitations of aproject leaders authority to actually implement or-ganization-building projects than were visionaryleaders. This awareness may reflect the communi-tys learning what a leader could actually accom-plish in this environment as well as a growing

recognition of the importance of other membersmotivations to contribute to the project. However,the amount of authority needed to carry out such aplatform was still high. The last four elections inour study period (200306) were won by organiza-tion leaders and represent a limited consensus onthe degree of authority appropriate for a projectleader.

To verify whether a general trend from technicalto organizational concerns was present in theseconceptions of leadership, we turn to our textualanalysis of leader platforms conducted in the

fourth round of coding. This analysis confirmedthat, over time, project leader candidates focusedtheir electoral platforms increasingly on organiza-tional issues, as opposed to technical issues. Figure1 graphically depicts these thematic patterns overtime. For example, in 2006, 73 percent of the text ofa leader candidates platform, on average, was de-voted to organizational issues, compared to only 37percent in 1999. To test whether these changeswere statistically significant, we regressed the pro-portions of text dedicated to organizational or tech-nical issues and to biographical information on a



14/29

trend line, measured with a scale ranging from 1 to8. The regression models testing the changes in theproportion of technical issues and biographical in-formation were not significant, but when we re-gressed the proportion of text dedicated to organi-zational issues on a trend line, the resulting modelwas statistically significant (F 19.3, df 6, p .01; R2 .76), and the coefficient for the trend linewas 0.05 (t 4.39, p .01), meaning that, onaverage, the proportion of text dedicated to organ-izational issues increased every year by 4.7 percent.

Debians achieving some consensus on a pre-

ferred conception of leadership does not imply thatthe community was free from strife or conflict (e.g.,Coleman, 2005). Our claim is merely that in phaseIV, when conflict over a leaders authority oc-curred, community members resolved the issueswithin the new governance framework that had

been created and debated in phases II and III. Anevent in 2006 offers evidence of such settlement; agroup of developers used the general resolutionprocess to recall the project leader when they be-came unsatisfied with his management of the

boundaries of the project. This was the first leader

recall in ten years, but now a formal process existedto handle challenges to a leaders authority. Therecall did not pass the general resolution process,

but it provides evidence of members ability andwillingness to work within the governance systemthey designed.

Conclusion. Under a de facto governance system(199397), Debian members had little shared basisof authority, and autocratic leadership failed.When Debian members entered a phase of design-ing governance (199799), they focused on bothdeveloping and limiting a positional basis of au-

thority that could be checked by democratic means.However, translating governance design into prac-tice (19992003) introduced much interpretationand variation as to the level of authority appropri-ate for a project leader, since democracy encour-aged variety. During this time, we identified fivedifferent active conceptions of leadership. Our

multimethod approach revealed, however, that ourinformants espoused preferences, in the designphase, for hands-off leadership was not supported

by later systematic evaluation of leadership data.After four years of implementation, a new con-

ception of authority emerged in 2003: organizationleadership. This year marked a transition to ashared conception of authority and a period of sta-

bilized governance that survived a crucial test: theattempted recall of a leader. As Selznick explained,Giving life to a constitution is partly a matter ofachieving general consensus regarding proper waysof winning power and making laws (1957: 6). Bythe end of 2006, the Debian community hadachieved such a consensus. With statistical tech-niques, we now explore the actual behaviors asso-ciated with becoming a leader in this community in2003, the start of the final phase of our study (sta-

bilizing governance).

PART II: DEDUCTIVE APPROACH

From our qualitative data, it would appear thatdevelopers engaged in organization building would

be more likely to assume leadership than those whowere more hands-off or more concerned with tech-nical issues. To test this prediction, we modeledthe results of one leader election four years after thesystem was designed (in 2003) with statistical anal-ysis. This approach allowed us to move beyondanalysis of discursive and rhetorical strategies used

by leader candidates to an evaluation of the behav-iors that were important to community membersconception of leadership.

Implicit in the literature on open source commu-nities is the assumption that these communities

operate in a meritocratic manner (e.g., Kogut &Metiu, 2001; Lee & Cole, 2003; Raymond, 1999).Thus, positions of authority should be allocatedaccording to merit. However, it is not clear whatmerit really means in this contexttechnical con-tributions or organization building? Our interviewdata suggested that informants were aware of astatus hierarchy based on technical contributionand observed the movement of people through it.One developer, commenting on the 2001 election,noted, I have seen a lot of developers go fromnobodies to being absolutely huge on the project.

FIGURE 1

Word Use in Leader Candidate Platforms



15/29

You know for instance, [Dan Evans], one of theguys who is running for the DPL right now.

The same informant who commented on Dansevolution from a nobody to huge also notedthat there is no hierarchy to really say you know Iam bigger than you so I will win. And it is a goodthing and a bad thing. A lot of Debian is I say a

meritocracy. You know if my code is better thanyour code, they will use it. Right? Our informantsinterpretation of meritocracy implied that the qual-ity of ones code would be predictive of leadership.Thus, we hypothesized that contributors withgreater technical contributions were more likely to

become leaders. To operationalize this hypothesis,we explicitly considered both the amount of tech-nical contributions as well as the impact of a de-velopers contributions on the community.

Hypothesis 1a. The greater the amount of acommunity members technical contribution,

the higher the probability that the communitymember becomes a leader.

Hypothesis 1b. The greater the impact of acommunity members technical contribution,the higher the probability that the communitymember becomes a leader.

However, our qualitative data suggested that de-velopers valued different strengths in a leader. Al-though some leadership candidates thought it wasa social position, others thought it was a merit

badge rather than a position of trust. In the 2002

election, one candidate noted that neither technicalexpertise nor social capital was sufficient: The

best candidate will not necessarily be the mostpopular or technically accomplished candidate,

but the candidate who has the strongest grasp ofwhat it will require to lead the Debian Project ef-fectively. This statement suggested that organiza-tion building might be as important as technicalcontribution but did not specify what activitieswould enable people to grasp what it takes. Ouranalysis of the organization building and organiza-tion leadership conceptions of authority in Part I of

this research showed that such leaders tended tofocus on enhancing communication and face-to-face interactions to better coordinate individual ef-forts within the community.

One former leader explained the importance ofknowing people and their needs to foster internalcoordination on the project. Internally its likecoordination, and checking that everything isworking well. So, for example, those people whowere playing important roles, Ive asked them,What can I do for you? For example, the securityteam was quite overloaded, so I was trying to find

some people for them . . . asking what is up? Whatcan I do? Although organization building hasmany facets, we realized that in a distributed globalcommunity, it would be impossible to do any or-ganization building without posting messages on-line or meeting people face-to-face; these are nec-essary conditions for organization building in such

a setting.Three recent studies of the emergence of informalleaders in online communities showed that leadersposted more messages than nonleaders (Cassell,Huffaker, & Tversky, 2005; Misiolek & Heckman,2005; Yoo & Alavi, 2004). Furthermore, the extentof offline interaction is likely to influence theamount of effort people put into building onlinecommunities (Butler, Sproull, Kiesler, & Kraut,forthcoming). In their study of Internet engineeringtask force (IETF) committees, Fleming andWaguespack (2007) discovered that, after an indi-vidual reached a certain level of technical contri-

bution, collaborating with high-status contributorsbecame a more important predictor of leadership.Thus, we propose that community members whocommunicate more with each other in both offlineand online forums are more likely to be on theleadership team.

Hypothesis 2a. The more a community mem-ber participates in online discussions, thehigher the probability that a community mem-ber will become a leader.

Hypothesis 2b. The more people in the com-

munity one meets face to face, the higher theprobability that a community member will be-come a leader.

If we found that Hypotheses 1a and 1b were sup-ported but Hypotheses 2a and 2b were not, thenwe could assume that community members fa-vored a purely technical management approachto leadership. This result would contradict ourfindings on espoused conceptions of leadershipin Part I of the study. If we found that Hypotheses2a and 2b were supported, than we would havemore systematic confirmatory evidence of mem-

bers evolving sense that organization buildingwas a legitimate expansion of a project leadersauthority.

Methods

Our field research helped us identify datasources that could be used to predict the leadership

behaviors that were important to the community.These data sources included the projects directory,developer database, bug-tracking database, package



16/29

popularity database, and identity authenticationdatabase. We collected data from these differentsources and integrated them into one database,merging the observations on the basis of develop-ers names and e-mail addresses. With these data,we estimated a logit regression model to predictwho became a member of the communitys leader-

ship team in 2003. Since the dependent variablewas dichotomous, logistic regression was appropri-ate (Long, 1997).7 Next, we explain how we opera-tionalized each variable.

Leadership team. In measuring our dependentvariable, we considered not only the position ofproject leader, but the communitys full leadershipteam, which also includes the project secretary,software release coordinator, developer accountsmanager, and members of the technical committee.Release coordinators and developer accounts man-ager are volunteers for indefinite appointments. Re-

lease coordinators shepherd the project to closureand developer account managers are responsiblefor allocating account rights to the projects coderepository. As explained earlier, the technical com-mittee (selected by the project leader) has the con-stitutional right to resolve technical disputes. Weviewed these positions as providing critical leader-ship for the community, and our informants con-curred. We coded these positions for the year 2003,the latest year for which a full set of data wasavailable. In 2003, 831 developers were recognizedas full-fledged members of the community, but we

could only find complete data on 815 developers.Rather than imputing values for the missing data,we tested our hypotheses on these 815 observa-tions. We also compared the missing observationswith the ones used in the analysis and found thatonly one of the developers on the leadership teamhad missing data. The developers with missingdata were primarily not leaders and, on average,maintained fewer packages, maintained packageswith less impact, posted fewer messages online,and had met fewer developers than developerswith complete data. Given the direction of our hy-potheses, the missing data do not introduce mean-ingful bias in the analysis since, if anything, theymake our estimates more conservative.

Independent variables. We operationalizedtechnical contribution and organization-buildingactivities with two different measures for each con-struct. Technical contribution was measured interms of the number of software packages main-tained by each developer and by the number ofpeople that used these packages. Together, these

measures capture both the quantity of a developerscontribution and his or her impact on the commu-nity. We operationalized organization-building ac-tivities as the amount of communication a devel-oper engaged in on the projects central mailing listand as degree centrality, measured by the numberof other developers the focal developer had metface-to-face (Wasserman & Faust, 1994). We de-scribe these variables in more detail in the follow-ing paragraphs.

To measure each developers amount of techni-cal contribution, we collected data from theprojects bug-tracking database on the number ofsoftware packages a developer maintained in 2002.A package is a discrete unit of software code thatcan be maintained independently of the rest of anoperating system but has a standardized interfacethat allows integration with other packages. Tomaintain a package is to manage the receipt andreview of code contributions from other contribu-tors and to package these smaller contributionsinto a discrete module.

To measure the impact of technical contributionfor each developer, we measured the popularity ofthe packages he or she maintained. Since early

2001, Debian users have been able to install a pop-ularity-contest package that automatically calcu-lates the number of people that download, install,and use a particular package. The popularity countis akin to a citation count in academic circles: itsignifies how many people in the community useor rely upon your work. We computed the sum ofthe votes for all the packages maintained by devel-opers as a measure of the criticality of their contri-

butions for others. Although these data might bebiased by the fact that not all developers had in-stalled the pop-con package as of 2003, the sam-

ple of data we obtained provides a good proxy forpackage use. Since 2004, the results of the popular-ity contest have been used to determine whichpackages to include in Debian distribution CDs aswell as to determine which packages to eliminatefrom the archives. We tested to see whether therewas a substantial difference between the results ofthe popularity contest in 2003 and in more recentyears (2004 and 2005) and found that the resultswere highly correlated, supporting our claim thateven for 2003, this was a robust measure of a pack-ages use by others.

7 We also estimated the full model with the rare eventlogit procedure developed by King and Zeng (1999) todeal with cases in which the dependent variable as-sumed the value 1 in only a small number of cases (fewerthan 1 percent). The model is significant and there is nosubstantial difference from the results we report with atraditional logistic regression in Table 5.



17/29

Since members are globally distributed, onlinemailing lists are the key infrastructure that enablescommunication and coordination in the Debianproject. On the mailing lists, developers discusschanges to the code, coordination issues, and thefuture direction of the project. Debian has over 100different mailing lists, focused on different sub-

groups of developers and specific technical issues.To measure projectwide online communication, wefocused on one list, debian-devel, to which alldevelopers subscribe. We downloaded all the post-ings to this list and measured each developersnumber of e-mail postings as a first proxy for or-ganization-building activity. Although discussionon debian-devel can also address technical issues,this mailing list is the one where most of the crit-ical organizational discussions in the communityare initiated, mainly because it contains the mostmembers. Therefore, we believe that the numberof e-mails a developer posted on this mailing list

provided a reasonable proxy for his or her propen-sity to communicate publicly with the rest of thecommunity. Our qualitative data suggested thatleaders interested in organization building would

be more likely to make proposals on the mostcentral list.

The other variable we used to measure a devel-

opers involvement in the organizational life of thecommunity was his or her degree centrality, acount of the number of other community membersthe developer had met as of January 1, 2003. Ouranalysis in Part I indicated that meeting other de-velopers face-to-face required some effort and wasassociated with interest in building the organiza-tion. To measure who met whom, we took advan-tage of an interesting practice that the projectadopted in 1994 to authenticate member identities.In 2000, this practice, which uses public key cryp-tography, became a condition for becoming aDebian project member.

EXHIBIT A

Keysigning Party Invitation

Subject: Reminder for Signers, SigneesFrom: xxxxxx@yyyDate: 16 Feb 2001 14:53:56 -0800

So, people who need their key signed, remember to:

1. Send me your key by tonight, so I can assemble them into a nice keyring printout for the signers.2. Bring the following tomorrow:

*Positive form of ID, like a drivers license or passport*Your own copy of your key fingerprint

3. Tomorrow Ill have:*Nice name key fingerprint printouts for signers to use.

4. Signers should bring:*A pen or pencil to mark off the fingerprint printouts once theyve checked IDs.

If youve never done a keysigning party before, heres how it works: the keysigner and keysignee meet.Keysigner checks the signees ID against his/her printout, to make sure that he/she is talking to the rightperson. Then, signer makes a check next to the signees name, to indicate identified. Keysignee thenreads out key fingerprint to keysigner. If the fingerprints match, and the ID is good, they make anothercheck mark next to the name on their printout, indicating key fingerprints match. ONLY IF BOTH

CHECKMARKS EXISTS should the signer sign the key.

After the party, the next steps are:

Every signer downloads the unsigned keyring from the Web URL Ill publish. Every signer signs the keys they verified (i.e., checked their print out). Every signer sends me their edited keyring with now-signed keys. I combine the signatures and make a new keyring, with all the signed stuff, and make that available on

the Web.

Note that to be a Debian New Maintainer you only need one signature from one Debian maintainer.However, its good for the Web of Trust for you to give and get lots of (valid) signatures.



18/29

Public key cryptography works with asymmetrickey pairs (one public and one private). One partyhas a private key that is not shared and uploads apublic key to a central keyring file. Other devel-opers can then retrieve this public key and use it toconfirm that messages sent from the first party areindeed from the sender. This procedure confirms

that the content of any electronic message is fromthe avowed sender but does not verify the real-world identity of the sender. Thus, to make publickey cryptography a useful means of authenticatingidentity, a real-world identity must be linked to apublic key.

The Debian project does this through the practiceof key signing. Developers sign each others keysto verify that they have met a person face-to-face.Members consider this to be an expression of trust:the signer meets the person, reviews government-issued identification, and then indicates belief thata particular public key belongs to the person whoclaims it via a digital signature. These digital sig-natures are uploaded to a central file where alldevelopers can access them. Developers can gettheir keys signed in various ways. For example, theDebian Web site lists developers who want to havetheir keys signed and willing key signers aroundthe world. This way, Debian developers who aretraveling for other reasons can arrange to meet eachother. Community members also attend key-sign-ing parties where people meet to expressly signkeys, but these parties are often combined withother project activities. Exhibit A is a sample invi-

tation to a Debian key-signing party.Since each key signing is dated and requires a

face-to-face meeting, these data indicate whenproject members met each other. We collected datafrom the Debian keyring, consisting of keys signed

by dyads from 1994 (when the practice began) untilJanuary 1, 2003. We used these data to measure thedegree centrality of each developer, or the numberof community members each developer had metface-to-face. Since this measure only counts eachsingle face-to-face meeting, we consider it a veryconservative measure.

We controlled for a members tenure on theproject (in months), taking the square root of thevalues because tenure did not follow a normal dis-tribution. We also controlled for a members geo-graphical location, which could only be establishedat the continent level.

Results

Table 4 shows means, standard deviations, andcorrelations among the variables we considered. Bycomparing the means of community members on

the leadership team with those of the average de-velopers (columns 1 and 3 in Table 4), we foundthat in 2003, the leadership team members had

been in the community longer (on average, 72.4versus 38.8 months)8 but maintained approxi-mately the same number of packages (10.9 vs. 9.3)as the average developers.9 However, the packages

that leaders maintained were used more widelythan those of the average developers (411.6 vs. 34.8users). Members of the leadership team were alsomuch more active on the mailing list (52.5 vs. 3.9messages posted) and had met many more otherDebian developers (43.1 vs. 9.2). The descriptivestatistics are thus in line with our hypotheses thatdevelopers who were making greater technical con-tributions (in terms of impact but not effort) andwho were more engaged in organization buildingwere more likely to become members of theleadership team.

Table 5 reports the logit coefficients and the oddsratios for the logistic regression models predictingmembership in the leadership team in 2003.10 Inthe final model, the independent variables weretenure, continent (with Europe as the default cat-egory), the number and popularity of code packagesmaintained (to measure technical contribution),and the amount of participation in online discus-sions and degree centrality (to measure organiza-tion building).

Technical contribution. The results reported inTable 5 suggest that the sheer amount of technicalcontribution, as measured by the number of soft-

ware packages maintained, has a negative associa-tion with the likelihood of becoming a member of

8 Many of the independent variables were transformedto address nonnormal distribution. In this section, inorder to facilitate the comparisons between leaders andthe rest of the developers, we report the descriptive sta-tistics in the original scale. For the case of tenure, wetook the power of the value in Table 5, since (x)2 x.Therefore: (8.52)2 72.4 months.

9 For packages, usage and mailing list postings, wealso report the descriptive statistics in the original scale,

by taking the exponential of the value in the Table 5 sinceeln(x) x. Therefore: e2.39 10.9.

10 To help the interpretation of the logit coefficients,we report the odds ratios in parentheses in the completemodel (but only for coefficients that are statistically sig-nificant). Odds ratios were computed by taking the anti-logarithm of the logit coefficient; thus, for the effect ofdegree centrality on leadership in 2003, we took thecoefficient from model 5 in Table 6 and simply computede0.055 1.056. Values exceeding 1 indicated an increasedlikelihood of becoming a member of the leadership team,and values less than 1 indicated decreased odds.



19/29

TABLE4

DescriptiveStatisticsandCorrelationsa

Variable

Meanfor

Leadership

Team

Members

s.d.

MeanforAll

Observations

s.d.

Minimum

Maximum

1

2

3

4

5

6

7

8

1.Leadershipteam,2003

1.00

0.00

0.01

0.10

0.00

1.00

2.Tenure

b

8.52

1.29

6.23

1.53

2.15

10.66

.15*

*

3.NorthAmerica

0.50

0.54

0.32

0.47

0.00

1.00

.04

.07*

4.Europe

0.38

0.52

0.52

0.50

0.00

1.00

.03

.03

.71**

5.Othercontinent

0.13

0.35

0.16

0.37

0.00

1.00

.00

.05

.29**.46**

6.Technicalcontributionc

2.39

1.55

2.23

1.47

0.00

6.93

.01

.01

.06

.04

.03

7.Impactoftechnicalcontributionc

6.02

2.54

3.55

2.68

0.00

9.51

.09*

.01

.00

.02

.03

.73**

8.Onlinecommunicationc

3.96

2.12

1.35

1.68

0.00

6.43

.16*

*

.05

.02

.02

.05

.38**

.47**

9.Degreecentralityb

43.13

40.45

9.55

13.43

0.00

114.00

.25*

*

.14**

.08*

.15**

.10**

.24**

.21**

.33**

a

n

815.

b

Squarerootofthenumberofm

onths.Measuredfor2002.

c

Log-transformedvariable.

*p

.05

**p

.01


20/29

the leadership team. Hypothesis 1a therefore findsno support. However, the impact of a developerstechnical contribution, as measured by the numberof users who installed the packages a developermaintained, is positively associated with the pro-pensity to be on the leadership team. For every 100users who installed a package, the package owner

(developer) was 2.3 times more likely to become amember of the leadership team.11 Hypothesis 1b istherefore supported.

Organization building and leadership. The re-sults reported in models 4 and 5 in Table 5, do notprovide strong supporting evidence for Hypothesis2a. Although the variable online communication ispositively associated with the likelihood of joiningthe leadership team in model 4, this effect losesstatistical significance when degree centrality isincluded, in model 5. Therefore, we have to con-clude that the sheer amount of communicationdoes not lead to the attainment of leadership posi-tions. We attribute our lack of results for onlinecommunication to the quality of our measure. In-deed, our ethnographic evidence leads us to con-clude that communication with the communitythrough the mailing list is an important antecedent

of the attainment of leadership positions, but onlyif other community members recognize this impactas significant. Our communication measure mayconflate critical conversations with casual talk and,in future research, selected content-coding of themessages could help tease apart these effects.

To test Hypothesis 2b, we used the conservative

measure of face-to-face meetings obtained from thecryptography keyring. In Table 5 (model 5), wefound that meeting ten more developers in the com-munity increased the likelihood of becoming amember of the leadership team by 56 percent (oddsratio 1.06). Three mechanisms may be responsi-

ble for these results. One, Debian developers maybe more likely to vote for someone they have metface-to-face, because they have developed a moretrusting relationship with that person (e.g., Jarven-paa, Knoll, & Leidner, 1998; Rocco, 1998; Weisband& Atwater, 1999). Two, candidates who have met

more people face-to-face may be more proactive increating coalitions or in seeking votes from othermembers (e.g., Thompson, 2005). Three, reciprocalconcerns may be at play; members may be morelikely to vote for developers theyve met becausethey believe that, once in leadership roles, thesedevelopers will be able to help them in the future.Given the data with which we are working, we arenot in a position to adjudicate among these mech-anisms. However, all three mechanisms are consis-tent with our theoretical argument that both tech-nical contribution and organization building are

11 The natural logarithm of 100 is 4.6, and a one-unitincrease in the log of users increases the odds by 46percent; therefore, to interpret the meaning of the oddsvalue we obtained for this measure, we computed 4.6 0.50 2.3.

TABLE 5Results of Logistic Regression Analysis for 2003 Leadership Team Membershipa

Variable

Model 1 Model 2 Model 3 Model

the emergence of governance in an open source community

Documents