24A Case Study of Open Source Tools and Practices in a Commercial Setting Vijay K. Gurbani, Anita Garvert Lucent Technologies/Bell Labs Innovations 2000 Lucent Lane Naperville, IL 60566 USA +1 630 224 0216 {vkg,agarvert}@lucent.com James D. Herbsleb School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 USA +1 412 268 8933 [email protected] ABSTRACT Commercially, many in the industry are using products based on Open Source. What have been missing are studies on if the commercial industry benefits from developing software following the open source development model. We present a case study that examines this issue by applying the concepts of the open source software development methodology to creating industrial-strength software. We conclude with lessons learned and open research questions. Keywords Open Source, Software Development, Session Initiation Protocol, Architecture 1. Introduction Open source practices and tools have proven potential to overcome many of the well-known difficulties of geographically-distributed software development [9], and to allow widely distributed users of software to add features and functionality they want with a minimum of conflict and management overhead [11]. Some reports have appeared in the literature describing experiences with open source tools in an industry setting [6], and in fact there has been a workshop focused specifically on open source in an industry context [2]. It is not immediately obvious, however, that open source tools and practices are a good fit to a commercial setting. To be sure, open source software is used extensively in the industry, and the recent acceptance of Linux and the Apache project are excellent examples of this phenomenon. However, what needs further study is whether the industry as a whole can benefit from adopting the methodology of the open source software development. Is the open source development methodology conducive to the manner in which industry develops its software, or are there only certain industrial projects that are amenable to the open source development methodology? In this paper, we report a case study on using open source development in telecommunication software. The project was an Internet telephony server originally built by one of the authors (VKG), and later administered as an open source project inside Lucent Technologies in order to speed development and quickly add functionality desired by different project groups who wanted to make use of it in their product lines. We describe the effort’s experiences over a four-year period and present a number of lessons learned about how to make such projects succeed. The rest of this paper is structured as follows: in section 2, we compile a set of characteristics that while common to all open source projects, may be exhibited differently under a commercial setting. Section 3 describes the software project we used in the case study. In section 4, we describe the initial development of the software and its use inside the company, the open source style setup and the experience as various groups begin to use and contribute to the software. We conclude with lessons learned and a discussion of further research questions suggested by our work. 2. Open Source Project Characteristics While there is, of course no definitive set of characteristics that all open source project necessarily share beyond permitting legal and pragmatic access to source code, there are many practices which are common across a large sample of open source projects (e.g., [7]). Some examples This work was supported in part by a grant from CMU Cylab and an IBM Faculty Award to the third author. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Open Source Application Spaces: Fifth Workshop on Open Source Software Engineering (5-WOSSE) May 17, 2005, St Louis, MO, USA. Copyright 2005 ACM 1-59593-127-9 … $5.00.25of how these practices seem potentially incompatible with commercial development are the following: 2.1 Requirements Commercial projects typically devote considerable effort to gathering and analyzing requirements, in a process that often involves several disciplines including marketing, product management, and software engineering. Open source projects, on the other hand, rely for the most part on users who are also developers to build the features they need and to fix bugs. Other users generally have to rely on mailing lists and change requests [13] to communicate feature requests to developers, who then may or may not address them, depending on their interests and the perceived importance of the requests. In commercial environments, management, often operating through a change control board, makes decisions about changes based on business needs. 2.2 Work assignments In firms, developers are generally assigned by management to projects and development tasks. There is usually an effort to match tasks with developers’ skills, and often an attempt to match their interests if possible, but developers’ choices are generally rather limited. In open source, developers typically choose what they want to work on. Generally, they begin building something they themselves need as users of the software. Those who continue to contribute tend to begin taking on jobs because of their perceived importance to the overall project [14]. 2.3 Software architecture It has often been argued that open source projects require a more modular architecture than commercial projects, and there is now some evidence that this is the case [10]. In fact, the architecture of the Netscape browser became much more modular after it was released as open source [10]. More generally, it is widely recognized that the structure of the organization is a critical determinant of the structure of the code [3, 8]. It is not clear how well architectures designed for a commercial environment will support the sort of collaboration that open source practices must support. 2.4 Tool compatibility Most open source projects exist on their own, or coexist on hosting services other projects that