Missouri University of Science and Technology Scholars' Mine Business and Information Technology Faculty Research & Creative Works Business and Information Technology 01 Jan 2010 Artifacts, Actors, and Interactions in the Cross-Project Coordination Practices of Open-Source Communities Cecil Eng Huang Chua Missouri University of Science and Technology, [email protected] Adrian Yong Kwang Yeow Follow this and additional works at: https://scholarsmine.mst.edu/bio_inftec_facwork Part of the Business Commons Recommended Citation Chua, C. E., & Yeow, A. Y. (2010). Artifacts, Actors, and Interactions in the Cross-Project Coordination Practices of Open-Source Communities. Journal of the Association of Information Systems, 11(12), pp. 838-867. Association for Information Systems (AIS). This Article - Journal is brought to you for free and open access by Scholars' Mine. It has been accepted for inclusion in Business and Information Technology Faculty Research & Creative Works by an authorized administrator of Scholars' Mine. This work is protected by U. S. Copyright Law. Unauthorized use including reproduction for redistribution requires the permission of the copyright holder. For more information, please contact [email protected]. Special Issue Artifacts, Actors, and Interactions in the Cross- Project Coordination Practices of Open-Source Communities Cecil Eng Huang Chua University of Auckland [email protected] Adrian Yong Kwang Yeow Nanyang Technological University [email protected] Abstract While there has been some research on coordination in FLOSS, such research has focused on coordination within a project or within a group. The area of cross-project coordination, where shared goals are tenuous or non-existent, has been under-researched. This paper explores the question of how multiple projects working on a single piece of existing software in the FLOSS environment can coordinate. Using the Ordering Systems lens, we examine this question via a cross-case analysis of four projects performed on the open source game Jagged Alliance 2 (JA2) in the forum Bear’s Pit. Our main findings are that: (1) Ongoing cross-project ordering systems are influenced by the materiality of development artifacts. (2) The emergent trajectory of cross-project ordering systems is influenced by affordances that emerge from the interaction between the goals and desires of the project team building the development artifact, and the materiality of the development artifact. (3) When two parties need to coordinate in the ordering system, all or almost all coordination effort can be borne by a single party. Furthermore, over time, emergent FLOSS projects bear more coordination effort than stable, Journalofthe Association for Information mature projects. Keywords: Cross-project coordination, materiality, ordering systems, open-source * Michael Wade and Kevin Crowston were the accepting senior editors. This article was submitted on 27th September 2009 and went through two revisions. Volume 11, Special Issue, pp.838-867, December 2010 Volume 11 . Issue 12 Artifacts, Actors and Interactions in the Cross-Project Coordination Practices of Open-Source Communities 1. Introduction Free/Libre Open Source Software (FLOSS) projects represent a new form of organizing where structures are flattened and distributed, and boundaries are fluid and permeable (Kellogg et al., 2006, Ljungberg, 2000). Work in FLOSS projects is distributed, highly modularized, and largely self- organized (Crowston et al., 2007). In many cases, open source software is developed by a small group. The group maintains the “core” of the open source development artifact (i.e., the actual software produced by the open source group), while others create separate projects that develop and submit new features or bug fixes (Fitzgerald, 2006, Scacchi, 2004). New features and bug fixes are typically provided as patches, which modify the development artifact (Crowston, 2008). Thus, in an open source environment, it is common to observe multiple, concurrent projects dependent on other projects for success (Adler et al., 1995, Sydow et al., 2004). In many cases, cross-project coordination is inherent in FLOSS work. For example, the Ubuntu version of Linux is based on the Debian project. Developers of Ubuntu must coordinate with developers of Debian to ensure Ubuntu works. In some instances, open source software development is inherently about coordination. Tikiwiki, for example, relies on a host of other open source projects including the Zend Framework, Smarty, and jQuery for its architecture. Coordination across projects is thus a critical ingredient in the success of much FLOSS software. Furthermore, this type of work in FLOSS projects parallels that of other IT development projects such as the maintenance of enterprise software where multiple projects rely on shared resources and tools (Grabher, 2004, Whitely, 2006). Although each separate project has its distinct project team with its own goals, teams must coordinate their work across projects because they work on the same development artifact. Despite the need to understand cross-project coordination, most coordination research in FLOSS and software development, in general, focuses on coordination within a project or group (Crowston et al., 2007, Faraj and Sproull, 2000, Herbsleb et al., 2000). The few studies in the management literature on cross-project coordination are mainly descriptive (Cusumano and Selby, 1995, Sabbagh, 1996). Recently, research has examined cross-project coordination's impact on overall project performance (Hoegl et al., 2004, Kratzer et al., 2008, Li et al., 2008). However, it is not clear from the literature how one manages dependencies across projects, i.e., how cross-project coordination is conducted. This resonates with the urgent call among FLOSS researchers to “grapple with the details of work practices” of such projects to provide a better understanding of this form of distributed work (Crowston and Wade, 2009). We distinguish cross-project coordination from general coordination by defining it as “the contextualized interactions that manage tasks, activities, and interdependencies across multiple projects to realize and achieve individual project goals.” In contrast, within-project coordination refers to the contextualized interactions that manage tasks, activities,` and interdependencies within a project to realize and achieve shared project goals (Faraj and Xiao, 2006). The existence of multiple goals across projects creates notable differences. For example, a single, shared goal implies that work occurs in a definable sequence, ending when the goal is achieved. With multiple goals, practices are emergent as the achievement of a goal by one project may be temporally unrelated to the achievement of another goal by a second project. The objective of this research is to explore the nature of cross-project coordination in FLOSS communities to highlight additional coordination problems and practices. Given that this particular domain is under-investigated, we conducted an inductive theory-building case study on the cross- project coordination dynamics of an open source computer game known as “Jagged Alliance 2” (“JA2”). Although open source game communities have not been studied in depth in most FLOSS research, a growing number of FLOSS projects focus on the gaming domain (Scacchi, 2004). JA2, like Mozilla, is a release of former proprietary software from an established (now defunct) commercial company and represents part of the ongoing evolution of open source software development (Fitzgerald, 2006, Ljungberg, 2000). The case site is particularly ideal because a large number of 839 Journal of the Association for Information Systems Vol. 11 Special Issue pp.838-867 December 2010 Chua and Yeow/Artifacts, Actors, and Interactions projects (more than 40) occur simultaneously on the site, all connected to the JA2 development artifact. Using a combination of exploratory cross-case analysis and online ethnography, we studied three representative cross-project cases within the JA2 site. We traced their cross-project coordination interactions from inception to March 2010. Our longitudinal observations of cross-project coordination provide a basis to develop theory about relationships among the material artifact, interactions, and coordination practices. Our main findings center on how different types of material artifacts – project artifacts, tool artifacts, development artifacts – and within-project practices shape and define coordination practices. A project artifact is created as a product of a project. A tool artifact is employed by a project to create a project artifact. For example, e-mail and language compilers (tool artifacts) are employed to develop a computer game (project artifact). A development artifact is simultaneously a tool and project artifact around which work in the community centers. For example, the Debian operating system is a development artifact in both the Ubuntu and Debian communities. The Debian community builds Debian, while simultaneously leveraging it to build other project artifacts (e.g., user interfaces). The Ubuntu community leverages Debian to build Ubuntu. Finally, a focal project is the project on which an analysis is centered. For example, in an Ubuntu case study, Ubuntu would be the focal project, which coordinates with another project, Debian. Our study produces three insights: (1) Ongoing cross-project ordering systems are influenced by the materiality of development artifacts; (2) the