The aim of this research is to identify the key elements in the success of business models for companies producing open source software. We have defined a new framework that can be used to evaluate existing and new business models in this area. Based on our analysis, we have identified two classes of business models for open source which in our opinion have the potential for success: Commodity Products for Horizontal Markets (CPHM), and Innovative Products for Niche Markets (IPNM).

A decentralized variant of continuous integration can be defined in terms of two fundamental rules: (1) Developers’ access to add contributions to the development version at any time, and (2) developers’ obligation to integrate their own contributions properly. Decentralized, continuous integration may adapt well to organizations where developers work relatively independently, as in many open source projects. The approach raises the issue of how these organizations can exercise central control, as attaining the benefits of continuous integration requires that contributions are useful and satisfy the project’s definition of successful integration. We have investigated the use of continuous integration in FreeBSD and Mozilla. Our account of quality assurance activities in the two open source projects distinguishes between Mintzberg’s three complementary forms of central control: Standardization and control of work output, work processes, and worker skills. Our study indicates that two major challenges face projects using decentralized, continuous integration: (1) To balance the access to add contributions against the need to stabilize and mature the software prior to a release, and (2) to consider the developers’ limited time and resources when interpreting their obligation to integrate their changes properly.

Lately we have seen a growing interest from both public and private organisations to adopt Open Source Software (OSS), not only for a few, specific applications but also on a more general level throughout the organisation. As a consequence, the organisations’ decisions on adoption of OSS are becoming increasingly more important and complex. We present three perspectives organisations can employ in their decisions: seeing OSS acquisition as a business case, as COTS acquisition, and as ar-chitectural change within a governance framework. We present case studies of decisions on OSS adoption, and categorise the decision criteria we have found. Our results indicate that for large-scale adoption of OSS, focus will be on architectural considerations: enterprise-wide architectures will at first be a barrier, but in the long term OSS’s support of open standards can be a major enabler for OSS adoption. In contrast, in smaller organisations and in small-scale adoption of OSS, the cheap price of OSS is a major enabler, as it provides a good opportunity for experiments and short-term economic benefits. For small organisations these experiments can lead to development of a common IT-architecture, and in larger organisations OSS can be adopted in niche-areas, without significantly violating an existing IT-architecture. Keywords: open source, COTS, IT architecture, governance

In this paper we focus on managerial and technical decisions for acquisi tion of OSS and discuss potential approaches to a widespread adoption of OSS. Moving from mainly techni cal issues in procurement to corporate IS governance presents OSS with new challenges beyond outlining a business case for a particular OSS application. We draw parallels to the business case for commercial software products (COTS). Compared with COTS, OSS products seem to have several advantages, but based on existing literature and a case study, we develop and discuss the hypothesis that a major barrier may be the “customer's” uncertainty and unfamiliarity with OSS vendor relationships. We find that corporate governance and architecture needs to be accounted for in both COTS and OSS. This paper should be seen as a first step researching the fit between procurement and delivery models for OSS.

For two Free/Open Source Software projects, Mozilla and FreeBSD, we describe the central elements in the software development processes: the technological infrastructure, the work organization, and the software process models. For each of these elements we discuss how the projects try to find an optimal balance between control (supposedly necessary for producing high-quality software) and anarchy (supposedly necessary for attracting and keeping voluntary developers). Several important considerations are identified: most importantly, control of access to bugtracking systems and source code repositories, quality control of both individual contributions and production releases, the importance of the development branch, and control of developers’ prioritization of work tasks and availability. The results show that the two projects, even though they produce very different kinds of software (a web-browser suite and an operating system), are similar in many respects. However, they also show how difficult the balance between anarchy and control may be and that it is likely to shift over time. 701 E. Chocolate Avenue, Suite 200, Hershey PA 17033-1240, USA Tel: 717/533-8845; Fax 717/533-8661; URL-http://www.idea-group.com ITB10126 IDEA GROUP PUBLISHING This chapter appears in the book, Free/Open Source Software Devel pm nt, edited by Stefan Koch. Co yright © 2004, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. 2 Holck and Jørgensen Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without written permission of Idea Group Inc. is prohibited. INTRODUCTION The statement “Do Not Check in on Red” can be found in red, capital letters on the website of Mozilla, a well-known F/OSS (Free/Open Source Software1) web browser. Mozilla, like many F/OSS and some commercial projects, employs the principle of continuous integration, where a number of developers individually and in parallel add source code to a central repository. The statement is a request for developers not to check in new changes to the repository if severe errors have been found in the present source code, a situation announced with unmistakable red boxes on the website. Taken literally, the statement would have the unfortunate consequence of also barring possible fixes to these errors, effectively blocking all further progress; rather, it should be interpreted as a strong request for developers to only check in changes necessary to fix the detected errors while the tree is red. In this way, the statement “Do Not Check in on Red” conveys a fundamental tension in the project: allowing a continuous flow of changes and improvements to the software on one hand, and assuring quality by minimizing the problems resulting from deficient contributions on the other. As discussed by O’Mahony (2003), it is generally assumed that F/OSS developers (“hackers”) don’t “embrace centralized modes of governance” and are “less likely to welcome formal organizing mechanisms,” instead believing “in the value of challenging work, technical autonomy, self-management, and freedom from a positional basis of power.” These assumptions indicate that F/OSS developers would prefer rather loosely controlled projects with a flat hierarchy, relying on individual autonomy, tacit norms, and self-organization rather than commands, control, and explicit rules. This is important for a F/OSS project facing the challenge of attracting and retaining voluntary, competent developers; even though some developers are paid for their work, typically this salary does not come from the project as such, but from companies or organizations volunteering for the project. It is, however, also generally assumed that software project success is dependent on diligent project management, “planning, organizing, directing, and controlling ... company resources ... to complete specific goals and objectives” (Kerzner, 1989, as cited in Jurison, 1999), and tight control of the software development process is a key element in Software Process Improvement (Paulk, Curtis, Chrissis, & Weber, 1993). The theme of this chapter will be the tension between these two, apparently conflicting demands on a F/OSS project: how are successful F/OSS projects able to find a reasonable balance between anarchy (supposedly necessary for attracting and keeping voluntary developers) and control (supposedly necessary for the effective production of high-quality software). In this context we will construe anarchism positively as “holding all forms of government authority to be unnecessary and undesirable and advocating a society based on voluntary cooperation and free association of individuals and groups” rather than “a state of lawlessness or political disorder due to the absence of governmental authority” (Anarchism, 2003). 24 more pages are available in the full version of this document, which may be purchased using the "Add to Cart" button on the product's webpage: www.igi-global.com/chapter/not-check-red/18718?camid=4v1 This title is available in InfoSci-Books, InfoSci-Software Technologies, Science, Engineering, and Information Technology, InfoSci-Select, InfoSci-Computer Science and Information Technology. Recommend this product to your librarian: www.igi-global.com/e-resources/libraryrecommendation/?id=1

For two Free/Open Source Software projects, Mozilla and FreeBSD, we describe the central elements in the soft­ware development processes: the technological infrastructure, the work organization, and the soft­ware process models. For each of these elements we discuss how the projects try to find an optimal balance between control (supposedly necessary for producing high-quality software) and anarchy (supposedly necessary for attracting and keeping voluntary developers). Several important consid­erations are identified: most importantly, control of access to bug-tracking systems and source code repositories, quality control of both individual contributions and production releases, the importance of the development branch, and control of developers’ prioritization of work tasks and availability. The results show that the two projects, even though they produce very different kinds of software (a web-browser suite and an oper­ating system), are similar in many respects. However, they also show how difficult the balance between anarchy and control may be and that it is likely to shift over time.

The paper presents an explorative study of Open Source Software (OSS) focusing on the managerial decisions for acquisition of OSS. Based on three case studies we argue that whereas small organizations often may chose adoption of OSS expecting significant cost savings, a major barrier for larger organizations’ adoption of OSS lies in the organizations’ consolidation of the enterprise architectures, in addition to that OSS will not be adopted before satisfactory delivery and procurement models for OSS are established.

The Open Source Software (OSS) concept abounds with paradoxicalissues which is one of the primary reasons why it is so interesting: For example, the basic premise that software source code—the ‘crown jewels’ for many proprietary software companies—should be provided freely to anyone who wishes to see it or modify it. Also, the tension between collectivism and individualism in the overall movement, the balance between modesty and supreme ego on the part of ‘code god’ project leaders, the balance between anarchy and control at the project level, the manner in which organisations make money from free software. These are all extremely interesting issues which will be the focus of this panel.

Open source software development challenges traditional views on software development; an apparently anarchistic bunch of hackers, working for free, produce widely used software. In this paper we investigate the role played by continuous integration with regard to coordinating the efforts of hundreds of developers in two open source projects, FreeBSD and Mozilla.

A decentralized variant of continuous integration can be defined in terms of two fundamental rules: (1) Developers’ access to add contributions to the development version at any time, and (2) developers’ obligation to integrate their own contributions properly. Decentralized, continuous integration may adapt well to organizations where developers work relatively independently, as in many open source projects. The approach raises the issue of how these organizations can exercise central control, as attaining the benefits of continuous integration requires that contributions are useful and satisfy the project’s definition of successful integration. We have investigated the use of continuous integration in FreeBSD and Mozilla. Our account of quality assurance activities in the two open source projects distinguishes between Mintzberg’s three complementary forms of central control: Standardization and control of work output, work processes, and worker skills. Our study indicates that two major challenges face projects using decentralized, continuous integration: (1) To balance the access to add contributions against the need to stabilize and mature the software prior to a release, and (2) to consider the developers’ limited time and resources when interpreting their obligation to integrate their changes properly.

The work organized by FreeBSD is maintenance-oriented: the operating system's 10th anniversary is up in 2003, and roots go back to the Berkeley Software Distribution of the late 70s. The project relies on voluntary contributions from 300 committers that have direct access to the source repository, and many external contributors. Each of the past few years, approximately 50 new committers have joined FreeBSD. The project's approach to integration - the testing and other activities required to assemble parts into larger parts - is highly incremental and decentralized: Incremental in the sense that all changes to the software are made as modifications to the project's development branch and are required to preserve it in a working state. And decentralized in the sense that committers are allowed to add changes without asking for approval. Delegation of commit authority distinguishes FreeBSD from projects where a small group or an individual is in control of the repository, for example Linux.

Aim of this research is to identify the key ele- ments that play a significant role in the success of business models for companies which produce software products based on open source using dual licensing. For that we have defined a new framework analysis that can be used to evaluate existing and new business models.

This empirical paper explores how entrants win substantial market accep- tance, based on a series of incremental software innovations supported by an open source software development process, and a unique web-based proprietary business model. We investigate the competitive processes a case company (MySQL AB) em- ployed to establish a sustainable foothold in the database software market - against the odds of a large installed customer base of competitors, and market incumbents' deep pockets and control of substantial complementary assets. Our findings suggest that a series of rapid incremental innovations, stack-based complement strategies, an open-source product testing approach, and a dual licensing strategy all contributed to winning through incremental innovation in increasingly commoditized database software markets. We distill seven important lessons that serve to guide managers in pursuing winning business models based on a series of incremental, and simultane- ously pursued innovations.