Role Migration and Advancement Processes in …wscacchi/Papers/New/Jensen-Scacchi-ICSE...Role...

Role Migration and Advancement Processes in OSSD Projects:A Comparative Case Study

Chris Jensen and Walt ScacchiInstitute for Software Research

Bren School of Information and Computer SciencesUniversity of California, Irvine Irvine, CA USA 92697-3455

{cjensen, wscacchi}@ics.uci.edu

AbstractSocio-technical processes have come to the forefrontof recent analysis of the open source softwaredevelopment (OSSD) world. Interest in making theseprocesses explicit is mounting, from industry and thesoftware process community, as well as among thosewho may become contributors to OSSD organization.This paper serves to close this gap by providing anempirical analysis of the role migration and projectcareer advancement process, and role-sets within,that we have observed through comparative casestudies within three large OSSD projectorganizations: Mozilla.org, Apache.org, andNetBeans.org.

1. Introduction

In recent years, organizations producing bothopen and closed software have sought to capitalize onthe perceived benefits of open source softwaredevelopment (OSSD) methodologies and technologies.Recent years have seen a substantial number of full-time developers employed to contribute to, extend,customize, or provide support for the bigger namedOSSD projects. Whether a full-time contributor, anoccasional hobbyist, or an end-user eager to report abug, people new to an OSS project face the samechallenge: learning how to participate in the project.Although most developers do not typically join aproject with the intent to lead it, understanding thejoining and participation processes can be as large anentry-barrier as the technical contribution itself.

Studies of OSSD processes are increasing innumber (e.g., [28, 29]), while OSSD organizationalstructures, technical roles, and career opportunities aremuch less studied. Ye and Kishida [33] and alsoCrowston and Howison [8] observe that OSSD project

Figure 1. An “onion” diagram representing ageneric OSSD project organizational hierarchy

members gravitate towards central roles over time,which they depict with “onion” diagrams such as inFigure 1.

Precedent for this sort of layered organizationaldepiction is well established outside of OSSD, such asin management, economics, and software engineeringliterature [24, 3, 9, 1]. These diagrams indicate multi-layer organizational hierarchies across communities,but do not indicate how participants might transitionbetween layers, or what roles are available at eachlayer. Moreover, the onion model as presented fails todraw out the presence of multiple tracks of projectcareer advancement through different role-sets,suggested in Figure 2. Similarly, Christie and Staley[5] argue that social and organizational processes,such as those associated with moving betweendifferent developer roles in a project, are important indetermining the outcome of software developmentprocesses. However, much like their developmentprocesses, OSSD communities typically provide littleinsight into role migration and advancement processes.

What guidance is provided is often directed atrecruitment-- initial steps to get people in the door.Guidance for attaining more central roles is oftencharacterized as being meritocratic, depending on thegovernance structure of the project [10, 27]. Softwareengineers have traditionally been limited to roles likerequirements analyst, software designer, programmer,

29th International Conference on Software Engineering (ICSE'07)0-7695-2828-7/07 $20.00 © 2007

or code tester with little/no expected movementbetween roles during a development project (exceptperhaps in small projects). In contrast, OSSdevelopment roles and how developers move betweenthem seem different from and more diverse than thoseoffered by the traditional view of softwareengineering.

In previous studies, we have examined softwaredevelopment processes within and across OSSDcommunities [26, 27, 28]. Here, we examine tworelated socio-technical processes used in OSSD as away of merging the social/cultural andtechnical/developmental OSSD activities.Specifically, we focus on the role migration andproject career advancement processes of developersfrom end-users/observers towards roles more centralroles within the Mozilla, Apache, and NetBeans OSSDproject communities. Such processes characterize botha hierarchy of roles that OSS developers play (cf.[12]), as well as how developers move through orbecome upwardly mobile within an OSSD project (cf.[32]). While anecdotal evidence of these processesexists, the lack of precision in their description servesas a barrier to project entry, continuous processimprovement, and process adoption by otherorganizations. A goal of our work is to provideprocess transparency through explicit modeling ofsuch process in ways that enable increasedparticipation, process improvement, and morewidespread adoption.

In the remaining sections, we outline details aboutthese role migration and advancement processes wefound, while analyzing cases within and across each ofthese three OSSD project communities.

2. Background

Role migration and career advancement havepreviously been studied in both education andmanagement literature. These studies bring us awealth of topics ranging from gender specific issues,such as glass ceilings in the workplace [17] topromotion and tenure in academia [25]. Managementliterature has long argued over the two ladder system

of technical and managerial role advancement withincorporations [2]. However, there may only be onepath of advancement available. In such cases,technical people can be forced into managerialpositions in order to advance in the organization,denoting a migration in career tracks.

Here, we show that the two ladder system doesnot hold for role migration processes in OSSdevelopment organizations. Rather, we see severalpatterns at work dictated by the organizationalconfiguration of the community. The traditionalassumption of two ladder system follows thatindividuals move up the ladder towards to positions ofgreater authority. Open source project participants,however, ascend and descend the organizationalhierarchy much more fluidly. Moreover, it is notuncommon to see lateral movements to other tracks ofcommunity involvement. Further, participation inOSSD projects is volunteer-driven and advancement isusually meritocratic. Participants advance by provingthemselves technically in the responsibilities of theirposition. At the same time, participants prove theirsocial commitment to project success by facilitatingothers' OSSD work and by mediating conflicts [29,30]. There is a growing body of work in modelingOSS processes and enumerating roles in such projects,however, the research is lacking in detail of howparticipation changes over time through role migrationand advancement.

3. Research approach and methods

To help explore the preceding themes, we presentfindings from empirical studies of cases within threelarge OSSD project that we have investigatedlongitudinally starting in 2002. We do not claim thatthe observations we report here is meant to describeall/most OSSD projects, since they probably do not.They do, however, represent case studies from three ofthe largest OSSD projects whose software productsconstitute a core software infrastructure for the WorldWide Web. The goal of our effort is to comparativelyexamine and explicate semi-structured models ofinteresting socio-technical processes found in OSSDprojects that appear to be key to overall projectsuccess and longevity. These processes and the rolespeople play within them guide and coordinate large-scale OSSD activities without a traditional softwareproject management regime. As such, we haveengaged a variety of qualitative and ethnographicresearch methods (including participant interviews,collection and cross-coding of OSSD artifacts, semi-automated Web site data mining, and multi-modemodeling (cf. [26, 30, 31, 32]) to discover and analyzerole migration and advancement processes in thissample of OSSD projects, as well as the set of roles

Figure 2. An “onion” pyramid representation of ageneric OSSD project organizational hierarchy

with multiple role-sets and advancement tracks.


through which participants advance. Our focus here isto reveal a sample of (otherwise invisible) processeswe have found through our studies with thesemethods, since these projects do not provide explicitdescriptions or models for how such processesoperate. We note that the processes we describe arenot static, and so they evolve and adapt over time,much like most effective work processes supported byevolving computing technologies.

4. Case 1: Role-sets, role migration andadvancement process in Mozilla.org

Developer recruitment in Mozilla has always beendifficult. The opening of the Netscape Web browsersource code a few years ago offered OSS developers aunique opportunity to peek under the hood of the oncedominant Web browser in use. Nevertheless, the largescale of this software application (millions of lines ofsource code) and the complex/convoluted architecturescared many developers away. These factors,combined with the lack of a working release orsupport from Netscape led one project manager to quitearly on [18]. However, with the eventual release of aworking product, the Mozilla project garnered userswho later became developers furthering the cause.

The Mozilla.org project Web site lists severalways for potential developers and non-technicalpeople to get involved with the community [13]. Onepath of involvement focuses on quality assurance anddocumentation, including activities such as maturing,synchronizing, and stabilizing updates to the sourcecode base. Technical membership roles andresponsibilities currently listed include bug reporting,screening, confirming, and fixing, writingdocumentation, and contacting Web sites that do notdisplay properly within Mozilla/Firefox browsers.Compared to more central roles, these activities do notrequire deep knowledge of the Mozilla source code orsystem architecture, and instead serve to allow would-be contributors to get involved and participate in theoverall software development process.

When bugs are submitted to the Bugzilla (the bugreporting system used to support Mozilladevelopment), they are initially assigned to acomponent, which developers review. On occasion,community members will submit patches foroutstanding issues within the bug repository (oftenattached to comments within the defect discussionthread) if module developers have not taken action.This phenomenon can be seen especially in instanceswhere community members wish to share solutionsthat have been rejected by the committers or moduleowner for inclusion in the source tree.

The next task is to recruit others to accept thesoftware repair/modification (i.e., patch) and

incorporate it into the source tree. Recruitment ofpatch review is best achieved through emailingreviewers working on the module for which the patchwas committed, or reaching out to the community viathe Mozilla IRC chat. In repeatedly demonstratingcompetency and dedication by writing useful codewithin a section of the source, would-be developersgain a reputation among those with commit access tothe current source code build tree. Eventually, thesecommitters recommend that the promising developerbe granted access by people who direct or coordinateoverall project activities. These are called the projectdrivers. In rare cases, such a developer may even beoffered the position of module owner if s/he is theprimary developer of that module and it has not beenblocked for inclusion into the trunk of the source tree[19].

Once a project contributor is approved as a sourcecode contributor, there are several roles available tocommunity members. Most of these are positionsrequiring greater seniority or record of demonstratedaccomplishments within the community. As moduledevelopers and owners establish themselves asprominent community members, other opportunitiesmay open up. In meritocratic fashion, developers maytransition from being a QA module contact to a QAowner (cf. [10]). Similar occasions exist on theproject level for becoming a module source reviewer.

Super-reviewers attain rank by demonstratingsuperior expertise for discerning quality and effect of agiven section of source on the remainder of the sourcetree. If a reviewer believes that s/he has done thisappropriately, s/he must convince an existing super-reviewer of such an accomplishment. This super-reviewer will propose the candidate to the remainderof the super-reviewers. Upon group consensus, thehigher rank is bestowed on the reviewer [21].

Project drivers are usually either contributingcompany employees or module owners who areinterested in setting the technical direction of theproject per release. Their primary role is to encouragedevelopers to fix specific high priority or high impactbugs critical to a release. In that sense, they act asrelease managers in a similar capacity to those of theNetBeans.org project described later. At the time ofthis writing, there are seventeen drivers listed on theMozilla project management information page [23],though the recent development branch (version 1.8.1)is directed by five drivers [22].

There is little evidence to offer generalizationsabout how a developer becomes a driver, howeverwhat is visible from the calendar sub-project shows adeveloper informally nominated at a project statusmeeting by other project leads and developers [20].This individual agreed to serve and was affirmed bythe others present online. The change in semantics for


developer roles (i.e. project lead developer) appearscharacteristic to the sub-project, rather than extendingto flagship projects such as Firefox and Thunderbird.

Community level roles include smoke-testcoordinator, code sheriff, and build engineer, althoughno process is prescribed for such transitions. Asindividual roles, they are held until vacated, at whichtime, the position is filled by appointment from thesenior community members and Mozilla Foundationstaff.

The participation tracks and respective hierarchyare given in Figure 3. This is how the Mozilla projectworked for some period of time. It appears thatnotions of module ownership and a formal qualityassurance process have diminished in recent years.The quality assurance track, in particular, appears tohave collapsed into three roles: the defect submitter,the benevolent committer, who may take correctiveand administrative actions on the defect report, and thepatch contributor sharing his/her solution with others(which may or may not be included in the source tree).This is not to suggest that quality assurance is notperformed, but rather to the contrary, that the reviewprocess and the associated role structure, have becomesubsumed by other processes and roles over time.When Mozilla was connected with Netscape, the superreviewership process was created in order to balancecontributions from Netscape developers and the publiccommunity and ensure their quality. As Mozillamatured (and later separated from Netscape), thenumber of expert developers increased. For reasons astechnical as well as social/political (suggested by [7]),several developers split off to create Firefox with morelightweight development processes and a small,though heavily gated, role hierarchy. With Firefox

now the dominant browser project, code reviewingand many of the related quality assurance tasks havemerged into module development processes.Similarly, the reviewer and smoke test coordinatorroles in the development track have similarly faded,along with code sheriff in the build and projectmanagement tracks. Moreover, since the legalincorporation of the Mozilla Foundation in 2005, buildand release roles are assigned to Foundationemployees. Incorporation further added a managementlayer including the board of directors and standingcommittees. The (now deprecated) role migrationprocess for reviewers in the Mozilla.org communityappears in Figure 4.

5. Case 2: Role-sets, role migration andadvancement process in Apache.org

The Apache Software Foundation (ASF) has beenestablished to nurture and nominally coordinate amulti-project software ecosystem that surrounds theApache Web server effort. ASF has laid out a linear(and meritocratic) path for involvement, as shown bythe role hierarchy in Figure 5. Individuals start out asend-users (e.g., Web site administrators), and thenproceed to developer status, committer status, projectmanagement committee (PMC) status, ASFmembership, and lastly, ASF board of directors’membership [14]. Much as in advancement in theMozilla community, Apache membership is byinvitation only. As the name suggests, the Apacheserver is comprised of patches submitted bydevelopers. These patches are reviewed bycommitters and either rejected or accepted into thesource tree.

Figure 3. Role-sets, role hierarchies, and advancement paths (left-to-right) in Mozilla.org


In addition to feature patches, developers are alsoencouraged to submit defect reports, projectdocumentation, and participate on the developermailing lists. When the PMC is satisfied with thedeveloper’s contributions, they may elect to extend anoffer of “committership” to the developer, grantinghim/her write access to the source tree. To acceptcommittership, the developer must submit acontributor license agreement, granting the ASFlicense to the intellectual property conveyed in thecommitted software artifacts.

PMC membership is granted by the ASF. Tobecome a PMC member, the developer/committermust be nominated by an existing ASF member andaccepted by a majority vote of the ASF membershipparticipating in the election [11]. Developers andcommitters nominated to become PMC members havedemonstrated commitment to the project, goodjudgment in their contributions to the source tree, andcapability in collaborating with other developers onthe project. The PMC is responsible for themanagement of each project within the Apachecommunity. The chair of the PMC is an ASF memberelected by his/her fellow ASF members who initiallyorganizes the day-to-day management infrastructurefor each project, and is ultimately responsible for theproject thereafter. ASF membership follows the sameprocess as PMC membership- nomination and electionby a majority vote of existing ASF members.

ASF members may run for office on the ASFboard of directors, as outlined by the ASF bylaws [4].Accordingly, the chairman, vice chairman, president,vice president, treasurer (and assistant), and secretary

(and assistant) are elected annually. A flow graph ofthe role migration process appears in Figure 6.

Although, there is one path of advancement in theApache community, there are several less formalcommittees that exist on a community (as opposed toproject) scale. These include the conferenceorganizing committee, the security committee, thepublic relations committee, the Java CommunityProcess (JCP) committee, and the licensingcommittee. Participation in these committees is opento all committers (and higher ranked members) androles are formalized on an as-needed basis (e.g.conference organization). Non-committers may applyfor inclusion in specific discussion lists by sending anemail to the board-mailing alias explaining why accessshould be granted. Thus, processes associated withthese committees are ad hoc and monolithic.

6. Case 3: Role-sets, role migration andadvancement processes in NetBeans.org

Roles in the NetBeans.org community fordeveloping the Java-based NetBeans interactivedevelopment environment are observable on six levelsof project management, as demonstrated by the role-sets and hierarchy in Figure 7.

These range from users to source contributors,module-level managers, project-level managers, andcommunity-level managers. The NetBeanscommunity’s core members are mostly SunMicrosystems employees, the community’s primarysponsor, and are subject to the responsibilities set onthem by their internal corporate hierarchy. As such,

Figure 4. Deprecated role migration process for reviewers in Mozilla.org. Lateraland reverse migration have been omitted for simplicity.


(and unlike the cases of Apache and Mozilla), not allroles are open to volunteer and third-partycontributors. Non-Sun employed communitymembers wanting to participate beyond end-usage areadvised to start out with activities such as qualityassurance (QA), internationalization, submittingpatches, and documentation [6]. As in the case withMozilla, until they have proven themselves asresponsible, useful, and dedicated contributors,developers must submit their contributions todeveloper mailing lists and the issue repository,relying on others with access to commit the source.However, unlike Mozilla, developers are alsoencouraged to start new modules.

While the community was more liberal withmodule creation early in the project’s history, as thecommunity has matured, additions to the modulecatalog have become more managed to eliminate anabundance of abandoned modules. Also as in Apacheand Mozilla, developers are subjected to the provingthemselves before being granted committer status on aportion of the source tree. Additionally, they may gainmodule owner status by creating a module or takingover ownership of an abandoned module of whichthey have been a primary committer. With moduleownership comes the responsibility to petition theCVS manager to grant commit access to the source

tree to developers working on the module, therebyraising their role status to “committer.”

Rising up to the project-level roles, the Sun-appointed CVS source code repository manager isresponsible for maintaining the integrity of the sourcetree, as well as granting and removing developeraccess permissions. In contrast, the release manger’srole is to coordinate efforts of module owners to planand achieve timely release of the software system.Theoretically, any community member may step in atany time and attempt to organize a release. Inpractice, this rarely occurs. Instead, most communitymembers passively accept the roadmap devised bySun’s NetBeans team. In the latter case, the previousrelease manager puts out a call to the community tosolicit volunteers for the position for the upcomingcycle. Assuming there are no objections, the (usuallyveteran) community member’s candidacy is acceptedand the CVS manager prepares the source tree andprovides the new release manager permissionsaccordingly. Alternatively, a member of Sun mayappoint a member of their development team to headup the release of their next development milestone.

At the community-management level, thecommunity managers coordinate efforts betweendevelopers and ensure that issues brought up onmailing lists are addressed fairly. At the inception ofthe NetBeans project, an employee of CollabNet (the

Figure 5. Role-set, role hierarchy, and advancement paths in Apache.org

Figure 6. Role migration process for committership in the Apache.org community, highlighting the sequenceof a developer becoming a committer. Lateral and reverse migration have been omitted for simplicity.


company hosting the NetBeans Web portal) originallyacted as community manager and liaison betweenCollabNet and NetBeans. However, it was soontransferred (by Sun) to a carefully selected Sunemployee who has held it since. As communitymembers have risen to more central positions in theNetBeans community, they tend to act similarly,facilitating and mediating mailing list discussions of atechnical nature, as well as initiating and participatingin discussions of project and community direction.

Last, a committee of three community members,whose largely untested responsibility is to ensurefairness within the community, governs the NetBeansproject. One of the three is appointed by Sun. Thecommunity at large elects the other two members ofthe governance board. These elections are held everysix months, beginning with a call for nominations bythe community management. Those nominees thataccept their nomination are compiled into a final list ofcandidates to be voted on by the community. A modelof the product development track role migrationprocess is shown in Figure 8.

7. Comparative case analysis

Role migration and project advancement in mostOSS projects does not extend beyond a project's ownWeb site. In the projects observed, recruitmentconsisted of multiple ways for users and observers toget involved. Such activities include submitting defectreports, test cases, source code and so forth. Theseactivities require a low degree of interaction with othercommunity members, most notably decision makers atthe top of the organizational hierarchy. Ourobservation has been that the impact of contributionstrickles up the organizational hierarchy whereasdecisions about socio-technical direction are passeddown. As such, activities that demonstrate capabilityin a current role, while also coordinating informationbetween upstream and downstream (with respect to theproject's role hierarchy) from a given developer arelikely to demonstrate community member capability athis/her current role, and therefore good candidates foradditional responsibilities.

Several themes are present in the role migrationprocesses of these three projects. In the communitieswe have examined, we found different paths tracking

Figure 7. Role-sets, role hierarchies, and advancement paths in NetBeans.org


up towards the center of the developer role hierarchy.Paths we identified include project management(authority over technical issues) and organizationalmanagement (authority over social/infrastructuralissues). Within these paths, we see paths that focus ondifferent software processes. These include qualityassurance roles, source code creation roles, and sourcecode versioning roles (e.g. CVS manager, CVScommitter, etc), as well as role paths for usability,marketing, and licensing. There are roles for upstreamdevelopment activities (project planning). Moresenior members of the community generally take theseup. This is due in part that developers working in theseroles can have an impact on the system developmentcommensurate with the consequences/costs of failure,and requires demonstrated skills to ensure the agentsresponsible will not put the software source code intoa state of disarray.

The presence of corporate and non-profitorganizations as the core of OSS organizations,employing project members in a full time fashion hasbecome common. As a salient example: the Mozillaproject has recently incorporated. With a full timestaff, many of the project management roles (e.g. buildengineering) are not positions available to communitymembers from the general public, but rather staffedpositions. The same is true of NetBeans. Rolemigration and advancement processes for thesepositions follow from the corporate or staffedorganization. These processes are consequently moreopaque than those of community positions. In termsof recruitment, organizations often extendemployment offers to veteran community members.Moreover, though Mozilla, Apache, and NetBeans allhave well defined organizational structures, we also

note the existence a number of unofficial roles, such asfor conference organization in Apache. These rolesare emergent and their migration processes may beone-off in nature. Their existence may be temporary(e.g. conference organizing) but may formalize overtime. Table 1 summarizes the types of role migrationprocesses we have observed.

Recruitment and role migration processes are nota newly observed phenomenon. Like career pathsdescribed in management literature [16], movement inthe organizational structure may be vertical orhorizontal. Most large OSSD project communities arehierarchical, even if they consist of only a few layerswith many members exist at each layer. It is alsocommon for project members to act in multipleoverlapping roles. Source code developers almostunfailingly submit defect reports though their primaryfocus is creating new code, rather than managing testcases, test suites, or defect repository as they are thefocus of the higher levels of the quality assurance thatwe have discussed here. Quality assurance anddevelopment are two tracks that naturally alignthemselves well. With further empirical study, wemay be able to identify additional patterns ofalignment.

In comparison to traditional softwaredevelopment organizations, tracks of advancement inopen source communities are much more fluid. Adeveloper contributing primarily to source codegeneration may easily contribute usability or qualityassurance test cases and results to their respectivecommunity teams. These is not to suggest that amodule manager of a branch of source code willautomatically and immediately gain core developerprivileges, responsibilities, and respect from those

Figure 8. Role migration process for Web team membership in NetBeans.org. Lateraland reverse migration have been omitted for simplicity.


teams. However, industrial environments tendtowards rigid and static organizational hierarchies withhighly controlled growth at each layer.

The depiction of role hierarchies in OSSD projectcommunities as concentric, onion-like circles speaksto the fact that those in the outer periphery have lessdirect control or knowledge of the project’s currentstate and its social and technical direction compared tothose in the inner core circle. Ye and Kishida arguethat these core developers drive project communitydirection by shaping the identities of peripheraldevelopers learning to become more central, accordingto the theory of legitimate peripheral participation(LPP) [33]. The mixed composition (consisting ofpaid/supervised and volunteer contributors) projectsobserved here demonstrate a more complex roleadvancement scheme than suggested by LPP,Nevertheless, as with the communities of practice ofLPP theory, and as we observed with Mozilla,organizational hierarchies and recruitment and rolemigration processes are not static. Although changesin the number of layers stabilize early in communityformation, the size of each layer (especially outerlayers) is highly variable. Evolution of theorganizational structure may cause or be caused bychanges in leadership, control, conflict negotiation,and collaboration in the community, such as thoseexamined elsewhere [15]. If too pronounced, changescan lead to breakdowns of the technical processes.

Meritocratic role migration and advancementprocesses, such as presented here, consist of asequence of establishing a record of contribution intechnical processes in collaboration with othercommunity members, followed by certain “rights ofpassage” specific to each community. For Apache,there is a formal voting process that precedesadvancement. In Mozilla and NetBeans, these are lessformal. The candidate petitions the appropriateauthorities for advancement or otherwise volunteers toaccept responsibility for an activity. These authoritieswill either accept or deny the inquiry.

8. Conclusions

Social or organizational processes that affect theperformance of software development processes havehad comparatively little investigation. This is partiallybecause some of these processes are perceived to bewell understood (e.g., project management processeslike scheduling or staffing), while others are oftentreated as “one-off” or ad hoc in nature, executing indifferent ways in each instantiation. The purpose ofour comparative case study examination rolemigration and project career advancement processes isto help reveal how these socio-technical processes arestructured and intertwined with conventional softwaredevelopment processes, and thus constrain or enablehow OSSD is performed in practice. In particular, wehave examined and modeled these processes within acomparative sample of three large OSSD projects thatembed the Web software infrastructure. As a result,we were able to identify different types of role setsand hierarchy that OSSD projects employ to migrateand advance their participants, from peripheral roles tocore leadership positions. Lastly, we have shownwhere and how they interact with existing softwaredevelopment processes found in our project sample.

Overall, we have found that comparative studiesof socio-technical processes found with even a smallsample of cases, such studies do in fact providesufficient substance and detail to reveal the richness ofprocesses, practices, and roles that shape open sourcesoftware development projects.

9. Acknowledgments

The research described in this paper has beensupported by grants #0534771, #0083075, #0205679,#0205724, #0350754, and #0534771 from the U.S.National Science Foundation. No endorsementimplied. Mark Ackerman at University of Michigan,Ann Arbor; Les Gasser at University of Illinois,Urbana-Champaign; John Noll at Santa ClaraUniversity; Margaret Elliott and others at the UCI

Table 1. Types of role migration processes observed in OSSD projectsRole Acquisition Method Description

Volunteering Implicitly/explicitly volunteering for and performing a task. Example: Mozilla volunteer tester

Earned/Granted An individual or body of authority grants rank to the community member. This may require thatthe community member apply for the position, or that s/he is nominated or sponsored by a higherranking member, possibly involving a vote from the granting body. Example: Apache committer

Appointed/Assigned An individual or body of authority appoints the community member to a position. Example:NetBeans community manager

Elected An individual is voted into a position by the community at large or a subcommittee. Example:ASF board member


Institute for Software Research are collaborators onthe research described here.

10. References[1] Aberdour, M. (2007). Achieving Quality in Open-Source Software, Software, IEEE, 24(1), 58-64,January/February.[2] Allen, T.J., & Katz, R. (1985). The Dual Ladder:Motivational Solution or Managerial Delusion? (Tech. Rep.WP1692-85). Massachusetts Institute of Technology (MIT),Sloan School of Management.[3] Baldwin R.E. (2001). The Core-Periphery Model withForward-looking Expectations. Regional Science andUrban Economics, 31(1), 21-49.[4] Bylaws of the Apache Software Foundation, RetrievedFebruary 7, 2005 fromhttp://www.apache.org/foundation/bylaws.html[5] Christie, A., & Staley, M. (2000). Organizational andSocial Simulation of a Software Requirements DevelopmentProcess. Software Process--Improvement and Practice, 5,103–110[6] Contributing to the NetBeans Project. RetrievedFebruary 7, 2005 fromhttp://www.netbeans.org/community/contribute/[7] Coward, A. (2005). About Firefox and Mozilla.Comment on Slashdot.org forum: Firefox Developer onRecruitment Policy, Retrieved January 31, 2005 fromhttp://developers.slashdot.org/comments.pl?sid=137815&threshold=1&commentsort=0&tid=154&tid=8&mode=thread&cid=11527647[8] Crowston, K. & Howison, J. (2005). The SocialStructure of Free and Open Source Software Development,First Monday, 10(2). February. Retrieved 27 April 2006http://www.firstmonday.org/issues/issue10_2/crowston/index.html[9] Curtis, B., Krasner, H., & Iscoe, N. (1988). A FieldStudy of the Software Design Process for Large System.Communications of the ACM, 31(11), 1268–1287.[10] Fielding, R. (1999). Shared Leadership in the ApacheProject. Comm. ACM, 42(4), 42-43.[11] Fielding, R., Hann, I-H., Roberts, J., & Slaughter, S.(2002). Delayed Returns to Open Source Participation: AnEmpirical Analysis of the Apache HTTP Server Project,Paper presented at the Conference on Open Source:Economics, Law, and Policy, Toulouse, France.[12] Gacek, C., & Arief, B. (2004). The Many Meanings ofOpen Source, IEEE Software, 21(1), 34-40.[13] Getting Involved with Mozilla.org. Retrieved 3 Nov2004, http://www.mozilla.org/contribute[14] How the ASF works, Retrieved 7 Feb. 2005http://www.apache.org/foundation/how-it-works.html[15] Jensen, C., & Scacchi, W. (2005). Collaboration,Leadership, Control, and Conflict Negotiation Processes inthe NetBeans.org Open Source Software DevelopmentCommunity. Proc. 38th. Hawaii Intern, Conf. SystemsScience, Waikola Village, HI, January 2005.

[16] Lash, P.B., & Sein, M.K. (1995). Career Paths in aChanging IS Environment: A Theoretical Perspective,Proceedings of SIGCPR 1995, 117-130. Nashville, TN[17] Liff, S., & Ward, K. (2001). Distorted views throughthe glass ceiling, Gender, Work, and Organization, 8(1), 9-36.[18] Mockus, A., Fielding, R., & Herbsleb, J. (2002). TwoCase Studies of Open Source Software Development:Apache and Mozilla, ACM Trans. Softw. Eng. andMethodology, 11(3), 309-346.[19] Mozilla Bug ID #18574, Retrieved January 10, 2007from https://bugzilla.mozilla.org/show_bug.cgi?id=18574[20] Mozilla Calendar Status Meeting Log 07-26-2006,Retrieved January 10, 2007 fromhttp://wiki.mozilla.org/Calendar:Status_Meetings:2006-07-26_MeetingLog[21] Mozilla Code Review FAQ, Retrieved 7 Feb. 2005http://www.mozilla.org/hacking/code-review-faq.html[22] Mozilla DevNews, Retrieved January 10, 2007 fromhttp://developer.mozilla.org/devnews/index.php/2006/06/20/181-branch-now-under-branch-driver-control[23] Mozilla Drivers, Retrieved January 10, 2007 fromhttp://www.mozilla.org/about/drivers[24] Rosen, S. (1982). Authority, Control, and theDistribution of Earnings. Bell Journal of Economics, 13(2),311-323.[25] Saaty, T.L., & Ramanujam, V. (1983). An objectiveapproach to faculty promotion and tenure by the analytichierarchy process. Research in Higher Education, 18(3),311-331.[26] Scacchi, W. (2002). Understanding the Requirementsfor Developing Open Source Software Systems, IEEProceedings--Software, 149(1), 24-39.[27] Scacchi, W. (2004). Free/Open Source SoftwareDevelopment Practices in the Computer Game Community,IEEE Software, 21(1), 59-67.[28] Scacchi, W. (2005). Socio-Technical InteractionNetworks in Free/Open Source Software DevelopmentProcesses, in S.T. Acuña and N. Juristo (eds.), SoftwareProcess Modeling, 1-27. New York, SpringerScience+Business Media Inc.[29] Scacchi, W., Feller, J., Fitzgerald, B., Hissam, S. andLakhani, K. (2006). Understanding Free/Open SourceSoftware Development Processes, Software Process--Improvement and Practice, 11(2), 95-105, March/April.[30] Scacchi, W., Jensen, C., Noll, J., and Elliott, M., (2006),Multimodal Modeling, Analysis, and Validation of OpenSource Software Development Processes, Intern. J.Information Technology and Web Engineering, 1(3), 49-63.[31] Seaman, C.B., (1999). Qualitative Methods inEmpirical Studies of Software Engineering, IEEE Trans.Software Engineering, 25(4), 557-572, July/August.[32] Sim, S.E., & Holt, R.C., (1998). The Ramp-UpProblem in Software Projects: A Case Study of HowSoftware Immigrants Naturalize, In Proc. 20th Intern. Conf.Softw. Eng, 361-370. Kyoto, Japan.[33] Ye, Y., & Kishida, K. (2003). Towards anUnderstanding of the Motivation of Open Source SoftwareDevelopers, In Proc. 25th Intern. Conf. Softw. Eng. 419-429.Portland, OR


Role Migration and Advancement Processes in …wscacchi/Papers/New/Jensen-Scacchi-ICSE...Role...

Documents

Transcript of Role Migration and Advancement Processes in …wscacchi/Papers/New/Jensen-Scacchi-ICSE...Role...