SPIP-FOSS-Intro-Dec2005.pdf

download SPIP-FOSS-Intro-Dec2005.pdf

of 11

Transcript of SPIP-FOSS-Intro-Dec2005.pdf

  • 7/27/2019 SPIP-FOSS-Intro-Dec2005.pdf

    1/11

    SOFTWARE PROCESS IMPROVEMENT AND PRACTICE

    Softw. Process Improve. Pract. 2006; 11: 95105

    Published online in Wiley InterScience (www.interscience.wiley.com). DOI: 10.1002/spip.255

    Guest Editorial

    Understanding Free/OpenSource SoftwareDevelopment Processes

    Walt Scacchi1, Joseph Feller2, Brian Fitzgerald3,*,,Scott Hissam4 and Karim Lakhani51 Institute for Software Research, University of California, Irvine, USA2 Business Information Systems, University College Cork, Ireland3 Computer Science and Information Systems, Limerick University, Ireland4 Software Engineering Institute, Carnegie-Mellon University, USA5 Sloan School of Management, Massachusetts Institute of Technology, USA

    This article introduces a special issue ofSoftware Process Improvement and Practice focusing onprocesses found in free or open source software development (F/OSSD) projects. It seeks toprovide a background overview of research in this area through a review of selected empiricalstudies of F/OSSD processes. The results and findings from a survey of empirical studies ofF/OSSD give rise to an interesting variety of opportunities and challenges for understandingthese processes, which are identified along the way. Overall, what becomes clear is that studies

    of F/OSSD processes reveal a more diverse set of different types of processes than have typicallybeen examined in conventional software development projects. The articles in this special issuefurther advance understanding of what processes characterize and shape F/OSSD. Copyright 2006 John Wiley & Sons, Ltd.

    KEY WORDS: open source software development; free software development; free/open source software processes

    1. INTRODUCTION

    This article explores patterns and processes thatemerge in free/open source software development

    (F/OSSD) projects. F/OSSD is a relatively new wayof building and deploying large software systemson a global basis, and differs in many interestingways from the principles and practices traditionallyadvocated for software engineering (SE) (Feller et al.

    Correspondence to: Brian Fitzgerald, Computer Science andInformation Systems, Limerick University, IrelandE-mail: [email protected]

    Copyright 2006 John Wiley & Sons, Ltd.

    2005). Hundreds of F/OSS systems are now in

    widespread use by thousands, or in some cases,millions of end-users. And some of these F/OSSsystems (e.g. Mozilla Web browser, OpenOffice

    productivity suite, Eclipse and NetBeans interactivedevelopment environments,KDE and GNOME userinterface packages, and most Linux distributions)entail millions of lines of source code. So whatis going on here, and how do emerging F/OSSDprocesses build and sustain these different projects?How might new studies of these processes be usedto explore what is new or different?

    One of the more significant features of F/OSSD isthe formation and enactment of complex software

  • 7/27/2019 SPIP-FOSS-Intro-Dec2005.pdf

    2/11

    Guest Editorial Editorial

    development processes performed by loosely coor-dinated software developers and contributors whomay be globally dispersed. On some large F/OSSDprojects, companies are assigning and paying soft-ware developmentstaff to work on F/OSSDprojectsas part of their job. In contrast, many other develop-ers volunteer their time and skill to such effort, andmay only work at their personal discretion ratherthan as assigned and scheduled. Further, thesedevelopers generally provide their own computingresources, and bring their own software develop-ment tools with them. However, most F/OSS devel-opers work on softwareprojectsthat do nottypicallyhave a corporate owner or management staff toorganize, direct, monitor, and improve the softwaredevelopment processes being put into practice. Buthow are successful F/OSSD projects and processespossible without regularlyemployed and scheduledsoftware development staff, or without an explicitregime for software engineering project manage-ment? Why will software developers participate inF/OSSD projects? Why and how are large F/OSSDprojects sustained? How are large F/OSSD projectscoordinated, controlled or managed without a tra-ditional project management team? What is it aboutthe communications, roles, and artifacts that enablesome projects to persist but not others? Why andhow might these answers to these questions change

    over time? These are the kinds of questions raisedin this article, and in the articles that follow in thisSpecial Issue of Software Process Improvement andPractice.

    The remainder of this article is organized asfollows. The next section provides further back-ground on what F/OSSD is and what is alreadyknown about F/OSSD practices, based on bothtrade studies and systematic empirical studies. Thissurvey focuses attention on identifying opportu-nities and challenges in understanding F/OSSDprocesses through empirical studies. Following this

    are brief overviews of each of the five articles thatwere selected for this Special Issue after a compre-hensive submission, review, and selection effort.A final discussion then argues why the softwareprocess research community may itself want toadopt F/OSSD practices for sharing and enablingothers to modify and share explicit descriptions,representations, models, and related software pro-cess source code within and across the software,information systems, computer science, and socialscience research communities.

    1.1. What is Free/Open Source SoftwareDevelopment?

    Free (as in freedom) software and open sourcesoftware (OSS) are often labeled or treated as

    the same thing. However, there are importantdifferences between them with regards to thelicenses assigned to the respective software, andto the beliefs/ideology of their practitioners ofhow and why software should be developed forsharing, modification, reuse, and redistribution.Free software generally appears licensed with theGNU general public license (GPL), while OSSmay use either the GPL or some other licensethat allows for the integration of software thatmay not be free software. Free software is asocial movement (Elliott and Scacchi 2004), whereas

    open source software development (OSSD) is asoftware development methodology, according tofree software advocates like Richard Stallmanand the Free Software Foundation (Gay 2002).However, free software is always available asOSS, but OSS is not always free software1. Thisis why it is often appropriate to refer to F/OSSor FLOSS (L for Libre, where the alternative termof libre software has popularity in some partsof the world) in order to accommodate similarand often indistinguishable approaches to softwaredevelopment. Subsequently, forthe purposes of thisarticle, focus is directed at F/OSSDprocesses, ratherthan to software licenses and social movementsassociated with free or OSS, though each mayimpinge on F/OSSD processes.

    F/OSSD is mostly not about SE, at least not asSE is portrayed in modern SE textbooks. Similarly,F/OSSD is not SE done poorly. Instead, F/OSSDis a different, somewhat orthogonal approach tothe development of software systems where muchof the development activity is openly visible,development artifacts are publicly available over

    the Web, and generally there is no formal projectmanagement regime, budget or schedule. F/OSSDis oriented towards the joint development of acommunity of developers and users concomitantwith the software system of interest.

    F/OSS developers have typically been end-users of the F/OSS they develop, although this

    1 Thus, at times it may be appropriate to distinguish conditionsor events that are generally associated or specific to either freesoftware development or OSSD, but not both.

    Copyright 2006 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2006; 11: 95105

    96

  • 7/27/2019 SPIP-FOSS-Intro-Dec2005.pdf

    3/11

    Guest Editorial Editorial

    appears to be changing somewhat. Similarly, manyend-users often participate in and contribute toF/OSSD efforts by providing feedback, bug reports,and usability concerns. There is also widespreadrecognition that F/OSSD projects can produce highquality andsustainable software systems that canbeused by thousands to millions of end-users (Mockuset al. 2002).

    Subsequently, it is reasonable to assume thatF/OSSD processes are not necessarily of the sametype, kind, or form found in SE projects that followthe processes described in modern SE textbooks.While such approaches might be used within anSE project, there is no basis found in the principlesof SE laid out in textbooks that would suggest SEprojects typically adopt or should practice F/OSSD

    methods. Subsequently, what is known about SEprocesses, a development organizations processcapability, and how to improve its developmentprocesses may not be equally applicable to F/OSSDprocesses, without some explicit rationale or empir-ical justification. Thus, it is appropriate to reviewsome of what is known so far about F/OSSD.

    2. RESULTS FROM RECENT STUDIES OFF/OSSD

    There are studies that offer some insight or find-ings on F/OSSD practices where each, in turn,reflects on different kinds of processes that arenot well understood at this time. These are sys-tematic empirical studies of F/OSSD projects usingsmall/large research samples and analytical meth-odsdrawn fromdifferent academic disciplines. Bothkinds of studies stand in contrast to the popu-lar examination of F/OSSD practices offered byF/OSS advocates (e.g. DiBona et al. 1999, Pavelicek2000, Raymond 2001). These popular treatmentstend to be grounded in personal experiences of

    the authors, rather than through careful system-atic study, though such experiences are valuablebecause they are often a source of insight or ques-tions for further inquiry.

    A number of Web-based repositories of researcharticles that report on studies on F/OSSD projectshave begun to appear. Among them are those at MIT(opensource.mit.edu) with over 200 articles con-tributed, and at University College Cork in Ireland(opensource.ucc.ie), which features links or cita-tions to multiple special issue journals focusing on

    F/OSSD (e.g. Information Systems Journal, 11(4) and12(1), 20012002, IEE Proceedings Software, 149(1),2002, Research Policy, 32(7), 2003, and IEEE Software,21(1), 2004), and to proceedings from internationalworkshops of OSS research (e.g. 1st through 5thWorkshops on Open Source Software Engineering,held in conjunction with the International Confer-ences on Software Engineering, 20012005). Ratherthan attempt to survey the complete universe ofstudies in these collections, since the majority ofthese studies do not address software processes, thechoice instead is to examine a set of studies2 thatraise interesting issues or challenging problems forsoftware process research and practice.

    One important qualifier to recognize is that thestudies below examined carefully selected F/OSSD

    projects, or a sample of projects, so the resultspresented should not be assumed to apply to allF/OSSD projects, or to projects that have not beenstudied. Furthermore, it is important to recognizethat F/OSSD is no silver bullet that resolvesthe software crisis. Instead it is fair to recognizethat most of the nearly 100000 F/OSSD projectsassociated with Web portals like SourceForce.orghave very small teams of two or less developers(Madey et al. 2004), and most projects are inactiveor have yet to release any operational software.However, there are now at least a few thousand

    F/OSSD projects that are viable and ongoing,so that there is a sufficient universe of diverseF/OSSD projects to investigate, understand, aswell as to model and simulate their softwareprocesses. Consequently, consider the researchfindings reported or studies cited below as startingpoints for further investigation, rather than asdefining characteristics of most or all F/OSSDprojects or processes.

    2.1. Comparing F/OSSD and SE Processes

    The first category of related studies seek to iden-tify and compare software development processesfound in F/OSSD projects with those describedor prescribed for SE projects, rather than just theresulting software products (Paulson et al. 2004).Mockus et al. (2002), in one of the most cited

    2 The articles included here address some software developmentprocess, such as the OSS design process, in the body of theirarticle (as found using search engines), or address topics thatheretofore have not appeared in prior software process studies.

    Copyright 2006 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2006; 11: 95105

    97

  • 7/27/2019 SPIP-FOSS-Intro-Dec2005.pdf

    4/11

    Guest Editorial Editorial

    studies of F/OSSD, briefly describe the processesaccounting for the development of the Apache WebServer and the Mozilla Web Browser. However,such an account does not provide sufficient contentto directly compare them to traditional SE pro-cesses. In contrast, Reis and Fortes (2002) provideone of the first in-depth examinations of the over-all process accounting for the development of theMozilla Web Browser.They identify different devel-oper roles, tools being used, artifacts created, andactivities performed, which potentially providesadequate information for modeling and comparingthe process.

    Scacchi (2002) provides a narrative descriptionof the software requirements process found in asample of F/OSSD projects and compares it to

    the requirements engineering process portrayedin modern SE textbooks. The F/OSSD projectsexamined span applications in application domainsincluding Internet infrastructure, networked com-puter games, astrophysics, and academic softwaredesign research. In a related study (Scacchi 2004),he identifies differences in software processes forrequirements and design, configuration manage-ment, evolution, project management, and soft-ware technology transfer from those in SE textsas found in the comparative study of multipleF/OSSD projects of a common type and networked

    computer games. Further, in two additional stud-ies, he examines data and models accounting forsoftware evolution (Lehman 2002) compared tothose emerging for F/OSSD (Scacchi 2005a), andalso emerging sociotechnical processes found inF/OSSD projects that intermingle social (e.g. team,group, and individual) and technical developmentprocesses (Scacchi 2005b, Truex et al. 1999). All ofthese studies describe processes found in differentF/OSSD projects using narrative descriptions ormodels. Furthermore, recent work describes howthese processes have been modeled and simulatedin a variety of notational, computational, and ethno-graphic schemes (Scacchi et al. 2005c).

    Finally, other recent efforts to model and simu-late F/OSSD processes of different kinds has begunto appear. Antoniades et al. (2004) and Smith et al.(2004) both provide simulation models of processesaccounting for the overall development or evolutionof multiple F/OSSD projects. Both efforts rely onmodels expressed as continuous functions througheither algebraic formulae or systems of equations.

    Such an approach to process simulation and mod-eling appears well matched to Systems Dynamics-based process simulation tools. In contrast, Jensenand Scacchi (2004, 2005) model and reenact pro-cesses found in a small sample of OSSD projectsusing language-based process models and a pro-cess reenactment simulator following techniquesdeveloped for analyzing traditional SE processes(Noll and Scacchi 2001, Scacchi 1999). The abilityto reenact F/OSSD processes provides an approachfor how to independently examine and validatewhether the captured process reflects the observedpractice, as well as makes the modeled processesavailable for reuse, tailoring, improvement, or prac-tice in other F/OSSD projects.

    2.2. Motivating, Joining, Participating, andContributing to F/OSSD Projects

    One of the most common questions about F/OSSDprojects is why software developers will join andparticipate in such efforts, often without pay forsustained periods of time. Accordingly, we mightthen ask whether or how the participation ofdevelopers affects what gets done in a F/OSSDproject in terms of which processes are engaged, aswell as understanding how processes for recruitingand integrating new developers into F/OSSDprojects operate. A number of surveys of F/OSSdevelopers (Ghosh and Prakash 2000, Hars and Ou2002, Hann et al. 2002, Lakhani et al. 2002, Hertelet al. 2003) have begun to pose such questions, andthe findings reveal the following.

    First, F/OSS developers generally find the great-est benefit from participation is the opportunity tolearn and to share what they know about softwaresystem functionality, design, methods, tools, andpractices associated with specific projects or com-munity leaders (Lakhani et al. 2002). F/OSSD is a

    venue for learning for individuals, project groups,and organizations, and learning organizations areones which can continuously improve or adapt theirprocesses and practices (Nakakoji et al. 2002, Hunt-ley 2003, Ye and Kishida 2003). However, thoughmuch of the development work in F/OSSD projectsis unpaid or volunteer, individual F/OSS develop-ers often benefit with higher average wages andbetter employment opportunities (at present), com-pared to their peers who lack F/OSSD experienceor skill (Hann et al. 2002, Lerner and Tirole 2002).

    Copyright 2006 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2006; 11: 95105

    98

  • 7/27/2019 SPIP-FOSS-Intro-Dec2005.pdf

    5/11

    Guest Editorial Editorial

    Second, F/OSS developers appear to really enjoytheir F/OSSD work (Hertel et al. 2003),andto berec-ognized as trustworthy and reputable contributors(Stewart and Gosain 2001). F/OSS developers alsoself-select thetechnicalroles they will take on as partof their participation in a project (Ye and Kishida2003, Gacek and Arief 2004), rather than be assignedtoaroleinatraditionallymanagedSEproject,wherethe assigned role may not be to their liking.

    Third, many F/OSS developers participate in andcontribute to multiple F/OSSD projects. In onestudy, 5% of developers surveyed reported par-ticipating in 10 or more F/OSSD projects (Hars andOu 2002). However, a small group of core devel-opers who control the architecture and directionof development typically develop the vast major-ity of F/OSS released by a project. Subsequently,most participantstypically contribute to just a singlemodule, though a small minority of modules mayinclude patches or modifications contributed byhundredsof contributors(Ghosh and Prakash 2000).

    Consequently, how and why software developerswill join, participate in, and contribute to anF/OSSD project seems to represent a new kindof process affecting how F/OSS is developedand maintained (von Krogh et al. 2003, Scacchi2005b). Subsequently, modeling and simulatingwhat this process is, how it operates, and how it

    affects software development is an open researchchallenge.

    2.3. Alliance Formation, Social Networking,Community Development, and SoftwareDevelopment

    How does the gathering of individual F/OSS devel-opers give rise to a more persistent project team orself-sustaining community? Through choices thatdevelopers make for their participation and con-tribution to an F/OSSD project, they find that

    there are like-minded individuals who also chooseto participate and contribute to a project. Thesesoftware developers find and connect with eachother through F/OSSD Web sites and online dis-course (e.g. threaded e-mail discussions) (Mongeet al. 1998), and they find they share many tech-nical competencies, values, and beliefs in common(Crowston and Scozzi 2002, Espinosa et al. 2002,Elliott and Scacchi 2004). This manifests itself in theemergence of an occupational network of F/OSSdevelopers (Elliott and Scacchi 2003).

    Becoming a central node in a social networkof software developers that interconnects multipleF/OSS projects is also a way to accumulate socialcapital and recognition from peers. However, italso enables the merger of independent F/OSSsystems into larger composite ones that gainthe critical mass of core developers to growmore substantially and attract ever larger user-developer communities (Madey et al. 2004, Scacchi2005b). Linchpin developers (Madey et al. 2004)participate in or span multiple F/OSSD projects. Inso doing, they create alliances between otherwiseindependent F/OSSD projects (Hars and Ou 2002).Figure 1 depicts an example of a social network of24 F/OSS developers within 5 F/OSS projects thatare interconnectedthrough two linchpin developers(Madey et al. 2004). Such interconnection enablessmall F/OSS projects to come together as a largersocial network with the critical mass (Marwell andOliver 1993) needed for their independent systemsto be merged and collectively experience moregrowth in size,functionality, and user base.F/OSSDWeb sites also serve as hubs that centralize attentionon what is happening with the development ofthe focal F/OSS system, its status, participantsand contributors, discourse on pending/futureneeds, etc.

    Thus interesting problems arise when investigat-

    ing how best to capture or represent the processesof alliance formation and interproject social net-working, and how such processes can be shown tofacilitate or constrain F/OSSD activities, tool usage,and preference for which development artifacts aremost valued by project participants.

    Developing F/OSS systems is a communityand project team building process that must beinstitutionalized within a community (Sharma et al.2002, Smith and Kollock 1999, Preece 2000, Yeet al. 2004) for its software informalisms (artifacts)and tools to flourish. Downloading, installing,

    and using F/OSS systems acquired from otherF/OSS Web sites is also part of a communitybuilding process (Kim 2000). Adoption and useof F/OSSD project Web sites is a community-wide practice for how to publicize and shareF/OSS project assets. These Web sites can bebuilt using F/OSSD Web site content managementsystems (e.g. PhP-Nuke) to host project contentsthat can be served using F/OSS Web servers(Apache), database systems (MySQL) or applicationservers (JBoss),and increasingly accessed via F/OSS

    Copyright 2006 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2006; 11: 95105

    99

  • 7/27/2019 SPIP-FOSS-Intro-Dec2005.pdf

    6/11

    Guest Editorial Editorial

    Figure 1. A social network that links 24 developers in five projects through two key developers into a larger F/OSSproject community (Madey et al. 2004)

    Web browsers (Mozilla and Firefox). Furthermore,ongoing F/OSSD projects may employ dozens ofF/OSS development tools, whether as standalonesystems like the software version control system

    CVS, as integrated development environments likeNetBeans or Eclipse, or as subsystem components oftheir own F/OSS application in development. Theseprojects similarly employ asynchronous systemsfor project communications that are persistent,searchable, traceable,public, and globally accessible(Yamauchi et al. 2000).

    F/OSS systems, hyperlinked artifacts and tools,and project Web sites serve as venues for socializ-ing, building relationships and trust, sharing andlearning with others. Community building, allianceforming, and participatory contributing are essen-

    tial and recurring activities that enable F/OSSDprojects to persist without central corporate author-ity. Linking people, systems, and projects togetherthrough shared artifacts and sustained online dis-course enables a sustained sociotechnical commu-nity, information infrastructure (Jensen and Scacchi2005), and a network of alliances (Monge et al. 1998)to emerge.

    For this reason, problems arise when investi-gating how best to capture and represent theF/OSSD processes that facilitate and constrain the

    codevelopment and coevolution of F/OSS projectcommunities and the software systems they pro-duce. The point is not to separate the developmentand evolution processes, or the software system

    from its community, since each is codependent onthe other, and the success of one depends on thesuccess of the other. Thus, they must be captured,understood, modeled, and simulated/reenacted asintegrating and intertwining processes, products,and community.

    2.4. Software Evolution in a MultiprojectSoftware Ecosystem

    As noted above, many F/OSSD projects havebecome interdependent through the networking

    of software developers, development artifacts,common tools, shared Web sites, and computer-mediated communications. What emerges from thisis a kind of multiproject software ecosystem (High-smith 2002), whereby ongoing development andevolution of one F/OSS system gives rise to prop-agated effects, changes, or vulnerabilities in one ormore of the projects linked to it (Jensen and Scacchi2005). These interdependencies are most apparentwhen F/OSSD projects share source code modulesor components. In such situations, the volume of

    Copyright 2006 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2006; 11: 95105

    100

  • 7/27/2019 SPIP-FOSS-Intro-Dec2005.pdf

    7/11

    Guest Editorial Editorial

    source code of an individual F/OSSD project mayappear to grow at a superlinear or exponential rate(Scacchi 2005a, Schach et al. 2002, Smith et al. 2004).Such an outcome, which economists and politicalscientists refer to as a network externality (Ostromet al. 1990), may be due to the import or integra-tion of shared components, or the replication andtailoring of device, platform, or internationalizationspecific code modules. Such system growth pat-terns might challenge the well-established laws ofsoftware evolution (Lehman 1980, 2002). Thus, soft-ware evolution in a multiproject F/OSS ecosystemis a process of coevolution of interrelated and inter-dependent F/OSSD projects, people, artifacts, tools,code, and project-specific processes.

    Software evolution in a multiproject F/OSSecosystem also suggests attending to social or tech-nological mechanisms that provide some form ofnatural selection. In biological ecosystems, naturalselection provides an account of why some speciesflourish and adapt in response to environmentalpressures, such as shortage of food sources or therise of newpredators, while other species that do notadapt progressively disappear or become extinct.In F/OSS ecosystems, a diversity of software sys-tem variants often appear as distinct projects. Forexample, there are a number of F/OSS operatingsystems with projects based on variants of the Unix

    operating system Linux, FreeBSD, OpenBSD, Dar-win, GNU Hurd, etc.and each of these may havemultiple subvariants (or forked distributions) likeDebian GNU/Linux, SUSE Linux, Red Hat Linux,and hundreds of others. Web browsers, softwarebuild/make tools, database management systems,file management utilities, content management sys-tems, and other types of software systems canbe found by the dozens, perhaps reflecting theirdevelopment in different F/OSS ecosystem niches.Similarly, one can readily find at F/OSS project por-tals like SourceForge.net, Freshmeat.net or Savan-

    nah.gnu.org, multiple projects developing the sametype of software system, but with variations in soft-ware architecture, choice of functional components,choice of programming language, and project con-tributors. However, in some software domains, adominant software system and project has emergedto effectively displace alternative variants by alarge majority, like the Apache Web server, thoughsuch dominance has not completely eliminated thecontending alternative F/OSS project efforts. Assuch, accounting for such evolutionary adaptation

    in response to emerging technological opportuni-ties (new tools) or limited access to more establishedF/OSS projects or core developers is thus a chal-lenge for those seeking to understand the processesof software evolution across a software ecosystem(Lehman 2002, Nakakoji et al. 2002, Smith et al. 2004,Ye et al. 2004).

    Last, it seems reasonable to observe that theworldof F/OSSD is not the only place where multi-project software ecosystems emerge, as softwaresharing or reuse within traditional software devel-opment enterprises is common (Highsmith 2002,Jensen and Scacchi 2005). However, the processof the coevolution of software ecosystems foundin either traditional or F/OSSD projects in mostlyunknown. Thus, software coevolution within anF/OSS ecosystem represents an opportunity forresearch that investigates such a software evolutionprocess through studies supported by techniquesfor modeling and simulating coevolving processes.

    Overall, the sample of F/OSSD research studiesand findings presented above reveals a number ofinteresting challenges for research in understand-ing F/OSSD processes. However, these studies areall grounded in an empirical basis where differenttypes of processes are being examined in differenttypes of F/OSSD projects of varying sample sizeand data collection methodology. So the fundamen-

    tal problem at hand is how to organize, reframe,and make clear what the challenges are in research-ing, improving, and practicing F/OSSD processes.The articles in this special issue help provide newinsights and findings for better understanding theproblem and challenges.

    3. ARTICLES SELECTED FOR THE SPECIALISSUE

    Five articles were selected as a result of the submis-sion and review process from a pool of 21 submitted

    articles for inclusion in this Special Issue. In our firstarticle, Evaluation of Free/Open Source SoftwareProducts through Project Analysis, David Cruz,Thomas Wieland, and Alexander Ziegler introducea systematic approach for supporting a decision toincorporate F/OSS products into a larger context,such as a software or enterprise-wide system. Theprocess of evaluating and integrating commerciallyavailable off-the-shelf software (often referred to asCOTS software) has been written and described atlength in academic and industrial literature. Often,

    Copyright 2006 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2006; 11: 95105

    101

  • 7/27/2019 SPIP-FOSS-Intro-Dec2005.pdf

    8/11

    Guest Editorial Editorial

    such evaluations are conducted to avoid unnec-essary risks, including the technical (Hissam andPlakosh 1999) and mission needs of the system towhich the evaluated software is to be incorporated(Corney et al. 2003). Often, many of the same con-siderations apply to F/OSS products. However, asthis article points out, there are additional and rel-evant aspects of an F/OSS project that producesthe F/OSS product that should be taken into con-sideration. The authors nicely characterize theseconsiderations into functional, technical, organiza-tional, legal, economical and political aspects andthereby provide a broader perspective on F/OSSproducts when performing such evaluations.

    In Information Systems Success in Free and OpenSource Software Development: Theory and Mea-sures, Kevin Crowston, Hala Annabi and JamesHowison address a key gap in FLOSS researchby seeking to define what success means in aFLOSS context. They derived a range of potentialmeasures from the Information Systems (IS) litera-ture, including system and information quality, usersatisfaction, user experience, individual and orga-nizational impacts, and then added a number ofadditional measures specific to the dynamics of theFLOSS development process. The list of measureswas then refined, operationalized, and validatedthrough empirical studies based in the SlashDot

    and SourceForge communities. The article makes awelcome contribution by providing a solid instru-ment for the future evaluation of FLOSS processes,and one that will mature and increase in its utilitywith further use.

    David Nichols and Michael Twidale report ontheir study of Usability Processes in Open SourceSoftware. They describe mechanisms, techniques,and technology used in F/OSS projects like Mozillaand GNOME. Both of these projects develop sys-tems that include substantial user interface compo-nents and functionality, and so they are primary

    candidates to consider how F/OSS developmentprocesses and practices embrace or ignore usabil-ity concerns. They use examples drawn from bugreporting and discussion systems to highlight boththe current practice, and how it might be revisedto realize higher quality F/OSS developmentoutcomes and easier to use application systems.This in turn maygive rise to recognizing how F/OSSprojects need to both address their ease of develop-ment (or developability) and the usability of theresulting software systems. This is particularly true,

    as Nichols and Twidale observe, when developersand users are geographically dispersed, have lim-ited resources to affect current processes, and maylack easily accessible sources of expertise about thefunctionality of the systems being developed, aswell as how to make such functionality easy to use.

    Douglas Schmidt and colleagues at VanderbiltUniversity and University of Maryland at Col-lege Park investigate Techniques and Processes forImproving the Quality and Performance of OpenSource Software. Their research complements thework of Crowston et al. in this issue, but whereasthat article sought to define success, Schmidt et al.tackle the more specific question of software qual-ity. They describe some of the challenges associatedwith FLOSS, and explore the ways in which qual-ity assurance (QA) processes that are specificallydesigned for FLOSS processes can help addressthese challenges. They support their work withempirical examinations of FLOSS projects usingthese QA processes, and conclude with extremelypractical findings of direct benefit to FLOSS practi-tioners.

    Katherine Stewart and Sanjay Gosain exam-ine The Moderating Role of Development Stagein Affecting Free/Open Source Software ProjectPerformance. This is an important contributiontowards understanding how social factors like team

    trust and ideology interact with the developmentprocess of a project and impact objective and sub-jective outcomes like task completion, number ofdevelopers mobilized, and perceived effectiveness.Using data from 67 F/OSS communities, they showthat the dynamics of performance change as aproject moves through various development stages.Their results suggest that objective measures ofproject performance tend to improve over time andwith increases in development stage, while subjec-tive assessments depend to a greater extent on theproject administrators experience. For example, the

    importance of trust in teams varies on the basis ofthe development stage of the project and the per-formance criteria. Overall they have presented asophisticated view of the interaction between thesocial and technical factors in a F/OSSD projectthroughout its development process.

    4. DISCUSSION

    F/OSSD projects represent and offer new publiclyavailable data sources of a size, diversity, and

    Copyright 2006 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2006; 11: 95105

    102

  • 7/27/2019 SPIP-FOSS-Intro-Dec2005.pdf

    9/11

    Guest Editorial Editorial

    complexity not previously available for research,on a global basis. Software process research andapplication has traditionally relied on an empiricalbasis in real-world processes for analysis, valida-tion, or improvement. However, such data hasoften been scarce, costly to acquire, and is oftennot available for sharing or independent reanalysisfor reasons including confidentiality or nondisclo-sure agreements. In contrast, F/OSSD projects andproject repositories contain process data and prod-uct artifacts that can be collected, analyzed, shared,and reanalyzed in a free and open source manner.The articles in this Special Issue draw upon pub-licly available data and artifacts in their analyses.F/OSSD therefore poses the opportunity to favor-ably alter the costs and constraints of accessing,analyzing, and sharing software process and prod-uct data, metrics, and data collection instruments.F/OSSDis thus poised to alter the calculus of empir-ical SE, information systems, and perhaps evencomputer science, while software process researchis an arena that can take advantage of such a histor-ically new opportunity.

    Finally, one important dimension that has not yetbeen addressed in this article is whether and howthe software process research community mightadopt F/OSSD practices themselves. For exam-ple, one traditional barrier to engaging students

    in software process studies is the paucity of freeor low-cost modeling and simulation tools. Shar-ing ones software process models and simulationswith colleagues is difficult at present, if they mustbuy new and unfamiliar tools. The ability to reuse,reanalyze, or extend a colleagues models or simula-tions is similarly limited. The community needs andshould directly benefit from F/OSS process models,tools, and process data/model repositories that canbe easily acquired or shared, studied, modified, andredistributed to the mutual benefit of all. Similarly,it can also be noted that it further serves the collec-

    tive interest of the community to consider how todevelop a globally shared and interoperable infor-mation infrastructure for data sharing, modeling,and simulating software processes3. This is true,whether these processes are found in SE or F/OSSDprojects. As a consequence, these are all opportu-nities for the software process research community

    3 Efforts likethe FLOSSmole repository(www.flossmole.org) andthe SourceForge.net Research Data repository (www.nd.edu/oss/Data/data.html) are two emerging examples in this area.

    to realize and pursue. After all, we are the oneswho will benefit from efforts to develop such free(as in freedom) and open source resources, as wellas further our collective learning and communitybuilding efforts.

    5. CONCLUSIONS

    Free and OSS development is emerging as analternative approach for developing large softwaresystems. New types and new kinds of software pro-cessesareemerging withinF/OSSD projects,as wellas new characteristics for development project suc-cess, when compared to those found in traditionalindustrial software projects and those portrayedin software engineering textbooks. As a result,

    F/OSSD offers new types and new kinds of pro-cesses to research, understand, improve, and prac-tice. Similarly, understanding how F/OSSD pro-cesses are similar to or different from SE processesis an area ripe for further research and comparativestudy. Many new research opportunities exist inthe empirical examination, modeling, simulation,improvement, and practice of F/OSSD processes.

    Through a survey of empirical studies of F/OSSDprojects and other analyses presented in this arti-cle, it should be clear there is an exciting varietyand diversity of opportunities for new research

    aimed at understanding and improving the practiceof F/OSSD. Thus, you are encouraged to considerhow your efforts to research or apply software pro-cess concepts, techniques, or tools can be advancedthrough studies that examine processes found inF/OSSD projects, and that practice free or opensource sharing, reuse, and extension ofsoftware pro-cess data, artifacts, models, and public repositories.

    ACKNOWLEDGEMENTS

    The research described in this report is supportedby grants from the US National Science Founda-tion #0083075, #0205679, #0205724, and #0350754;from Science Foundation Ireland #02/IN.1/I108;and from the EU to the CALIBRE project. Noendorsement implied.

    REFERENCES

    Antoniades IP, Samoladas I, Stamelos I, Angelis L,Bleris GL. 2004. Dynamic Simulation models of the open

    Copyright 2006 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2006; 11: 95105

    103

  • 7/27/2019 SPIP-FOSS-Intro-Dec2005.pdf

    10/11

    Guest Editorial Editorial

    source development process. In Free/Open Source SoftwareDevelopment, Koch S (ed.). Idea Group Publishing:Hershey, PA, 174202.

    Carney D, Morris E, Place P. 2003. Identifying

    Commercial off-the-shelf COTS Usage Risk Evaluation.SEI Technical Report CMU/SEI-2003-TR-023, Carnegie-Mellon University, Pittsburgh, PA.

    Crowston K, Scozzi B. 2002. Open source softwareprojects as virtual organizations: competency rallying forsoftware development. IEE Proceedings Software 149(1):317.

    DiBona C, Ockman S, Stone M. 1999. Open Sources: Voicesfrom the Open Source Revolution. OReillyPress: Sebastopol,CA.

    Elliott M, Scacchi W. 2003. Free software developers

    as an occupational community: Resolving conflictsand fostering collaboration. In Proceedings of the ACMInternational Conference on Supporting Group Work, SanibelIsland, FL, November 2003, 2130.

    Elliott M, Scacchi W. 2004. Free software development:Cooperation and conflict in a virtual organizationalculture. In Free/Open Source Software Development, Koch S(ed.). Idea Group Publishing: Hershey, PA, 152172.

    Espinosa JA, Kraut RE, Slaughter SA, Lerch JF, Herb-sleb JD, Mockus A. 2002. Shared mental models, famil-iarity, and coordination: A multi-method study of

    distributed software teams. In International ConferenceInformation Systems, Barcelona, Spain, December, 2002425433.

    Feller J, Fitgerald B, Hissam S, Lakhani K. 2005.Perspectives on Free and Open Source Software. MIT Press:Cambridge, MA.

    Gacek C, Arief B. 2004. The many meanings of opensource. IEEE Software 21(1): 3440.

    Gay J (ed.). 2002. Free Software, Free Society: Essaysby Richard M. Stallman. Free Software Foundation:Cambridge, MA.

    Ghosh R, Prakash VV. 2000. The orbiten freesoftware survey. First Monday 5(7): Also seehttp://www.infonomics.nl/FLOSS/ and http://www.firstmonday.org/issues/issue5 7/ghosh/index.html forfurther information.

    Hann I-H, Roberts J, Slaughter S, Fielding R. 2002.Economic incentives for participating in open sourcesoftware projects. In Proceedings of the Twenty-ThirdInternational Conference on Information Systems, Barcelona,Spain, December 2002 365372.

    Hars A, Ou S. 2002. Working for free? Motivations forparticipating in open source projects. International Journalof Electronic Commerce 6(3): 2539.

    Hertel G, Neidner S, Hermann S. 2003. Motivation ofsoftware developers in open source projects: an internet-

    based survey of contributors to the Linux kernel. ResearchPolicy 32(7): 11591177.

    Highsmith J. 2002. Agile Software Development Ecosystems.Addison-Wesley: Boston, MA.

    Hissam S, Plakosh D. 1999. COTS in the RealWorld: A Case Study in Risk Discovery and Repair,CMU/SEI-99-TN-003, Software Engineering Insti-tute, Carnegie Mellon University: Pittsburgh, PA,http://www.sei.cmu.edu/publications/documents/99.reports/99tn003/99tn003abstract.html.

    Huntley CL. 2003.Organizational learningin open-source

    software projects: An analysis of debugging data. IEEETransactions on Engineering Management 50(4): 485493.

    Jensen C, Scacchi W. 2004. Collaboration, leadership, andconflict negotiation in the NetBeans.org community. InProceedings of the 4th Workshop on Open Source SoftwareEngineering, Edinburgh, UK, May 2004.

    Jensen C, Scacchi W. 2005. Process modeling acrossthe web information infrastructure. Software Pro-cess Improvement and Practice 10(3): 255272.

    Kim AJ. 2000. Community Building on the Web: SecretStrategies for Successful Online Communities. Peachpit

    Press: Berkeley, CA.

    Lakhani KR, Wolf B, Bates J, DiBona C. 2002. TheBoston Consulting Group Hacker Survey, July.http://www.bcg.com/opensource/BCGHackerSurvey-OSCON24July02v073.pdf.

    Lehman MM. 1980. Programs, life cycles, and laws ofsoftware evolution. Proceedings of the IEEE 68: 10601078.

    Lehman MM. 2002. Software evolution. In Encyclopediaof Software Engineering, 2nd edn, Marciniak J (ed.). JohnWiley and Sons: New York, 15071513; Also see 2002.Software evolution and software evolution processes

    Annals of Software Engineering 12: 275 309.

    Lerner J, Tirole J. 2002. Some simple economics of opensource. Journal of Industrial Economics 50(2): 197234.

    Madey G, Freeh V, Tynan R. 2004. Modeling the F/OSScommunity: A quantative investigation. In Free/OpenSource Software Development, Koch S (ed.). Idea GroupPublishing: Hershey, PA, 203221.

    Marwell G, Oliver P. 1993. The Critical Mass in CollectiveAction: A Micro-Social Theory. Cambridge UniversityPress: NY.

    Copyright 2006 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2006; 11: 95105

    104

  • 7/27/2019 SPIP-FOSS-Intro-Dec2005.pdf

    11/11

    Guest Editorial Editorial

    Mockus A, Fielding R, Herbsleb JD. 2002. Two casestudies of open source software development: Apacheand Mozilla. ACM Transactions on Software Engineeringand Methodology 11(3): 309346.

    Monge PR, Fulk J, Kalman ME, Flanagin AJ, Parnassa C,Rumsey S. 1998. Production of collective action inalliance-based interorganizational communication andinformation systems. Organization Science 9(3): 411433.

    Nakakoji K, Yamamoto Y, Nishinaka Y, Kishida K, Ye Y.2002. Evolution patterns of open-source software systemsand communities. In Proceedings of the 2002 InternationalWorkshop Principles of Software Evolution, Orlando, Florida,7685.

    Noll J, Scacchi W. 2001. Specifying process-orientedhypertext for organizational computing. Journal ofNetwork and Computer Applications 24(1): 3961.

    Ostrom E, Calvert R, Eggertsson T (eds). 1990. Governingthe Commons: The Evolution of Institutions for CollectiveAction. Cambridge University Press: Cambridge,England.

    Paulson JW, Succi G, Eberlein A. 2004.An empirical studyof open-source and closed-sourcesoftware products.IEEETransactions On Software Engineering 30(4): 246256.

    Pavelicek R. 2000. Embracing Insanity: Open Source SoftwareDevelopment. SAMS Publishing: Indianapolis, IN.

    Preece J. 2000. Online Communities: Designing Usability,Supporting Sociability. John Wiley and Sons: Chichester,

    UK.

    Raymond ES. 2001. The Cathedral & The Bazaar: Musingson Linux and Open Source by an Accidental Revolutionary .OReilly Media: Sebastopol, CA.

    Reis CR, Fortes RPM. 2002. An overview of the softwareengineering process and tools in the Mozilla project.In Proceedings of the Workshop on Open Source SoftwareDevelopment, Newcastle, UK, February 2002.

    Scacchi W. 1999. Experience with software processsimulation and modeling. Journal of Systems and Software46(2/3): 183 192.

    Scacchi W. 2002. Understanding the requirementsfor developing open source software systems. IEEProceedingsSoftware 149(1): 2439.

    Scacchi W. 2004.Free/open source software developmentpractices in the computergame community. IEEE Software21(1): 5967.

    Scacchi W. 2005a. Understanding free/open sourcesoftware evolution. In Software Evolution and Feedback,Madhavji NH, Lehman MM,Ramil JF, Perry D (eds). JohnWiley and Sons: New York, to appear.

    Scacchi W. 2005b. Socio-technical interaction networksin free/open source software development processes.In Software Process Modeling, Acuna ST, Juristo N (eds).Springer Science, Business Media Inc.: New York,127.

    Scacchi W, Jensen C, Noll J, Elliott M. 2005c. Multi-modal modeling, analysis and validation of open sourcesoftware requirements processes. In Proceedings of theFirst International ConferenceOpen Source Software, Genova,Italy, July 18 2005c.

    Schach SR, Jin B, Wright DR, Heller GZ, Offutt AJ.2002. Maintainability of the Linux Kernel. IEEProceedingsSoftware 149(1): 1823.

    Sharma S, Sugumaran V, Rajagopalan B. 2002. Aframework for creating Hybrid open-source softwarecommunities. Information Systems Journal 12(1): 7 25.

    Smith M, Kollock P (eds). 1999.Communities in Cyberspace.Routledge: London, UK.

    Smith N, Capiluppi A, Ramil JF. 2004. Qualitativeanalysis and simulation of open source softwareevolution. In Proceedings of the 5th Software ProcessSimulation and Modeling Workshop (ProSim04), Edinburgh,Scotland, UK, May 2004.

    Stewart KJ, Gosain S. 2001. An exploratory study ofideology and trustin open sourcedevelopment groups. InProceedings of the 22nd International Conference InformationSystems (ICIS-2001), New Orleans, LA.

    Truex D, Baskerville R, Klein H. 1999. Growing systemsin an Emergent Organization. Communications of the ACM42(8): 117123.

    von Krogh G, Spaeth S, Lakhani K. 2003. Community,joining, and specialization in open source softwareinnovation: a case study. Research Policy 32(7):12171241.

    Yamauchi Y, Yokozawa M, Shinohara T, Ishida T. 2000.Collaboration with lean media: How open-sourcesoftware succeeds. Proceedings of the Computer SupportedCooperative Work Conference (CSCW00). ACM Press:Philadelphia, PA, December 329338.

    Ye Y, Kishida K. 2003. Towards an understanding ofthe motivation of open source software developers.Proceedings of the 25th International Conference On SoftwareEngineering. IEEE Computer Society: Portland, OR, May419429.

    Ye Y, Nakakoji K, Yamamoto Y, Kishida K. 2004. Theco-evolution of systems and communities in freeand open source software development. In Free/OpenSource Software Development, Koch S (ed.). Idea GroupPublishing: Hershey, PA, 5982.

    Copyright 2006 John Wiley & Sons, Ltd. Softw. Process Improve. Pract., 2006; 11: 95105

    105