This paper develops an inductive theory of the open source software innovation process by focussing on the creation of Freenet, a project aimed at developing a decentralized and anonymous peer-to-peer electronic file sharing network. We are particularly interested in the strategies and processes by which new people join the existing community of software developers, and how they initially contribute code. Analyzing data from multiple sources on the Freenet software development process, we generate the constructs of "joining script",

Research into free and open source software development projects has so far largely focused on how the major tasks of software development are organized and motivated. But a complete project requires the execution of “mundane but necessary” tasks as well. In this paper, we explore how the mundane but necessary task of field support is organized in the case of Apache web server software, and why some project participants are motivated to provide this service gratis to others. We find that the Apache field support system functions effectively. We also find that, when we partition the help system into its component tasks, 98 % of the effort expended by information providers in fact returns direct learning benefits to those providers. This finding considerably reduces the puzzle of why information providers are willing to perform this task “for free. ” Implications are discussed.

Open source software, developed by volunteers, appears counter to the conventional wisdom that private provision of public goods is socially more efficient. But complexity makes a difference. Under standard models, development contracts for specialized software may be difficult to write and ownership rights do not necessarily elicit socially optimal effort. I consider three mechanisms that improve the likelihood that firms can obtain the software they need: pre-packaged software, Application Program Interfaces (APIs) and Free/Open Source software (FOSS). I show that with complex software, some firms will choose to participate in FOSS over both “make or buy ” and this increases social welfare. In general, FOSS complements proprietary provision, rather than replacing it. Pre-packaged software can coexist in the marketplace with FOSS: pre-packaged software addresses common uses with limited feature sets, while firms with specialized, more complex needs use FOSS.

Theorists often speculate why open source and free software project contributors give their work away. Although contributors make their work publicly available, they do not forfeit their rights to it. Community managed software projects protect their work by using several legal and normative tactics, which should not be conflated with a disregard for or neglect of intellectual property rights. These tactics allow a project's intellectual property to be publicly and freely available and yet, governable. Exploration of this seemingly contradictory state may provide new insight into governance models for the management of digital intellectual property. Key Words: Software, Public Goods, Open Source, Intellectual Property, Common Pool Resources *Contact: Siobhn O'Mahony; Negotiations, Organization and Markets group, Harvard Business School, Baker Library West 186, Soldiers Field, Boston, MA 02163, USA; Tel: +1 617 495 0875; Fax: +1 617 496 7379; E-mail: somahony@hbs.edu This research was in part supported by the Stanford University's Center for Work, Technology and Organization, the Stanford Technology Ventures Program, and funds provided by the Alfred P. Sloan Foundation for the Social Science Research Council's Program on the Corporation as a Social Institution. Special thanks to the editors and reviewers for their helpful comments, to my informants for their time and interest and to Stephen Barley, Robert Sutton, Josh Lerner, Carliss Baldwin, George Baker, Victor Seidel, Fabrizio Ferraro, Mark Mortensen, Michael Schrage, Rachel Campagna and Jason Owen-Smith for their always thoughtful comments on the formation of these ideas and earlier versions of this paper. It's kind of cool to bring the power to where it belongs and what's really exciting about working with the hack...

This paper is an initial exploration of the determinants of open source license choice. It first enumerates the various considerations that should figure into the licensor's choice of contractual terms, in particular highlighting how the decision is shaped not just by the preferences of the licensor itself, but also by that of the community of developers. The paper then presents an empirical analysis of the determinants of license choice using the SourceForge database, a compilation of nearly 40,000 open source projects. Projects geared toward end-users tend to have restrictive licenses, while those oriented toward developers are less likely to do so. Projects that are designed to mn on commercial operating systems and those geared towards the Internet are less likely to have restrictive licenses. Finally, projects that are likely to be attractive to consumers--such as games-- are more likely to have restrictive licenses. A more tentative conclusion based on a much smaller sample is that projects that involve software developed in a corporate setting are likely to have more restrictive licenses. These findings are broadly consistent with theoretical predictions

This paper discusses the economic merits of direct or indirect governmental support for open source projects. Software markets differ from standard textbook markets in three important respects that may give rise to market failures: (i) large economies of scale, (ii) crucially important innovations, (iii) significant network effects and switching costs. We analyze the differences between proprietary software and open source software with respect to these market features and ask whether open source as an alternative to proprietary software can mitigate these problems. Then we discuss the implications of various forms of governmental support for open source.

This paper reviews our understanding of the growing open source movement. We highlight how many aspects of open source software appear initially puzzling to an economist. As we have acknowledge, our ability to answer confidently many of the issues raised here questions is likely to increase as the open source movement itself grows and evolves. At the same time, it is heartening to us how much of open source activities can be understood within existing economic frameworks, despite the presence of claims to the contrary. The labor and industrial organization literatures provide lenses through which the structure of open source projects, the role of contributors, and the movement's ongoing evolution can be viewed.

Information systems success is one of the most widely used dependent variables in information systems (IS) research, but research on free/libre and open source software (FLOSS) often fails to appropriately conceptualize this important concept. In this article, we reconsider what success means within a FLOSS context. We first review existing models of IS success and success variables used in FLOSS research and assess them for their usefulness, practicality and fit to the FLOSS context. Then, drawing on a theoretical model of group effectiveness in the FLOSS development process, as well as an on-line discussion with developers, we present additional concepts that are central to an appropriate understanding of success for FLOSS. In order to examine the practicality and validity of this conceptual scheme, the second half of our article presents an empirical study that demonstrates operationalizations of the chosen measures and assesses their internal validity. We use data from SourceForge to measure the project’s effectiveness in team building, the speed of the project at responding to bug reports and the project’s popularity. We conclude by discussing the implications of this study for our proposed extension of IS success in the context of FLOSS development and highlight future

Prior characterizations of open source projects have been based on the model of a community-founded project. More recently, a second model has emerged, where organizations spinout internally developed code to a public forum. Based on field work on open source projects, we compare the lifecycle differences between these two models. We identify problems unique to spinout projects, particularly in attracting and building an external community. We illustrate these issues with a feasibility analysis of a proposed open source project based on VistA, the primary healthcare information system of the U.S. Department of Veterans Affairs. This example illuminates the complexities of building a community after a code base has been developed and suggests that open source software can be used to transfer technology to the private sector. 1.

Open source communities have successfully developed a great deal of software although most computer users only use proprietary applications. The usability of open source software is often regarded as one reason for this limited distribution. In this paper we review the existing evidence of the usability of open source software and discuss how the characteristics of open source development influence usability. We describe how existing human-computer interaction techniques can be used to leverage distributed networked communities, of developers and users, to address issues of usability.