An Open Source Software (OSS) project is unlikely to be successful unless there is an accompanied community that provides the platform for developers and users to collaborate. Members of such communities are volunteers whose motivation to participate and contribute is of essential importance to the success of OSS projects. In this paper, we aim to create an understanding of what motivates people to participate in OSS communities. We theorize that learning is one of the motivational forces. Our theory is grounded in the learning theory of Legitimate Peripheral Participation, and is supported by analyzing the social structure of OSS communities and the co-evolution between OSS systems and communities. We also discuss practical implications of our theory for creating and maintaining sustainable OSS communitie as well as for software engineering research and education..

Open-Source Software (OSS) development is regarded as a successful model of encouraging "natural product evolution". To understand how this "natural product evolution" happens, we have conducted a case study of four typical OSS projects. Unlike most previous studies on software evolution that focus on the evolution of the system per se, our study takes a broader perspective: It examines not only the evolution of OSS systems, but also the evolution of the associated OSS communities, as well as the relationship between the two types of evolution.

Open source software, or free software, has generated much interest and debate in the wake of a number of high-impact applications and systems produced under open source models for development and distribution. Despite the high degree of interest, little hard data exists to-date on the membership of collaborative open source communities and the evolutionary process of their repositories. This paper contributes a baseline quantitative study of one of the oldest continuous repositories for the Linux open source project (the UNC MetaLab Linux Archives), including demographic information on its broad community of developers. Our methodology is a close examination of collection statistics, including custom monitoring scripts on the server, as well as an analysis of the contents of user-generated metadata embedded within the Archives. User-generated metadata files in a format known as the Linux Software Map (LSM) are required when submitting open source software for inclusion in non-mirrored...

Abstract not found

Open Source Software development teams provide an interesting and convenient setting for studying distributed work. We begin by answering perhaps the most basic question: what is the social structure of these teams? Based on a social network analysis of interactions represented in 62,110 bug reports from 122 large and active projects, we find that some OSS teams are highly centralized, but contrary to expectation, others are not. Furthermore, we find that the level of centralization is negatively correlated with project size, suggesting that larger projects become more modular. The paper makes a further methodological contribution by identifying appropriate analysis approaches for interaction data. We conclude by sketching directions for future research.

Jun is a large open-source graphics and multimedia library. It is object-oriented and supports 3D geometry, topography and multimedia. This paper reviews the development of the Jun library from five perspectives: open-source, software evolution processes, development styles, technological support, and development data. We conclude the paper with lessons learned from the perspective of a for-profit company providing open-source object-oriented software to the community. 1.

Some free software projects have been extremely successful. This rise to prominence can be attributed to the high quality and suitability of the software. This quality and suitability is achieved through an elaborate peer-review process performed by a large community of users, who act as co-developers to identify and correct software defects and add features. Although this process is crucial to the success of free software projects, there is more to the free software development than the creation of a ‘bazaar’. In this paper we draw on existing free software projects to define a lifecycle model for free software. This paper then explores each phase of the lifecycle model and agrees that, while the bazaar phase attracts the most attention, it is the initial modular design that accommodates diverse interventions. Moreover, it is the period of transition from the initial group to the larger community based development that is crucial in determining whether a free software project will succeed or fail. 2

Multi-user UNIX-like operating systems such as Linux are often considered unsuitable for real-time data collection because of the potential for indeter-minate timing latencies resulting from preemptive scheduling. In this paper, Linux is shown to be fully adequate for precisely controlled programming with millisecond resolution or better. The Linux system calls that subserve such timing control are described and tested, and then utilized in a MIDI-based program for tapping and music performance experiments. The timing of this program, including data input and output, is shown to be accurate at the millisecond level. This demonstrates that Linux, with proper pro-gramming, is suitable for real-time experiment software. In addition, the detailed description and test of both the operating system facilities and the application program itself may serve as a model for publicly documenting programming methods and software performance on other operating sys-tems.

The open source software development community has long been critical of mainstream software engineering thinking: mainstream software engineering has largely ignored or even scoffed at this critique. A summary of some key elements of such a critique can be useful in at least two ways: as part of an attempt to understand the existing relationship between SE and OSS, and as a tool for improving practice in both areas. 1 OSS Development Is Just SE... Right? It is the perception of many members of the Software Engineering (SE) community that academic SE practice is the standard by which software development should be judged. In this view, high-quality scientific research on SE processes and tools drives high-quality software development practices that produce high-quality, low-cost software in almost any domain. It is interesting to note that many experienced and capable software developers in commercial enterprises scoff at the notion of best SE practice as normative. This view is even more emphatic in the free and open source software (OSS) community. Reactions in response to the perceived mismatch between “real world ” commercial and OSS development and SE “best practice ” have run a gamut, from the development of customized and lightweight software development methodologies such as Extreme Programming [1] to the simple business-as-usual plan of ignoring the SE community altogether. Vixie [14] captures this attitude well, noting that “It is clear from historical examples that software need not be engineered to be widely used and enjoyed.” In fact, the ignorance of SE prescribed practice in the OSS community appears to be almost total and some-

Abstract. Some free software and open source projects have been extremely successful in the past. The success of a project is often related to the number of developers it can attract: a larger community of developers (the `bazaar') identifies and corrects more software defects and adds more features via a peer-review process. In this paper two free software projects (Wine and Arla) are empirically explored in order to characterize their software lifecycle, development processes and communities. Both the projects show a phase where the number of active developers and the actual work performed on the system is constant, or does not grow: we argued that this phase corresponds to the one termed 'cathedral ' in the literature. One of the two projects (Wine) shows also a second phase: a sudden growing amount of developers corresponds to a similar growing output produced: we termed this as the `bazaar ' phase, and we also argued that this phase was not achieved for the other system. A further analysis revealed that the transition between `cathedral' and `bazaar ' was a phase by itself in Wine, achieved by creating a growing amount of new modules, which attracted new developers. 1Introduction Prominent free software (or open source software, OSS) projects such as Linux [32], Apache [27] and FreeBSD [18] have been extremely successful. Anecdotal evidence has been used in the past to characterize successful OSS projects: users/developers acting as "more eyeballs " in the correction of bugs, developers implementing new features independently, skillful project managers dealing with a mostly flat organization, and the resulting coordination costs [28]. Previous studies have provided empirical evidence on the process of successful OSS projects: the definition of various types of developers has been discussed for the Mozilla and the Apache projects, justifying different levels of effort [27], and claiming that the first type (core developers) contribute to the success of a system.