The focus of this paper is to review what is known about free and open source software development (FOSSD) work practices, development processes, project and community dynamics, and other socio-technical relationships. It focuses on exploring how FOSS is developed and evolved based on an extensive review of a set of empirical studies of FOSSD projects that articulate different levels of analysis. These characterize what has been analyzed in FOSSD studies across levels that examine (i) why individuals participate; (ii) resources and capabilities supporting development activities; (iii) how cooperation, coordination, and control are realized in projects; (iv) alliance formation and inter-project social networking; (v) FOSS as a multi-project software ecosystem, and (vi) FOSS as a social movement. Next, there is a discussion of limitations and constraints in the FOSSD studies so far. Last, attention shifts to identifying emerging opportunities for future FOSSD studies that can give rise to the development of new software engineering tools or techniques, as well as to new empirical studies of software development.

Libre (free, open source) software is one of the paradigmatic cases where heavy use of telematic tools and userdriven software development are key points. This paper proposes a methodology for measuring and analyzing remotely big libre software projects using publicly-available data from their version control repositories. By means of a tool called CVSAnalY that has been implemented following this methodology, measurements and analyses can be made in an automatic and non-intrusive way, providing real-time and historical data about the project and its contributors.

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

This chapter examines the evolution of open source software and how their evolutionary patterns compare to prior studies of software evolution of proprietary (or closed source) software. Free or open source software (F/OSS) development focuses attention to systems like the GNU/Linux operating system, Apache Web server, and Mozilla Web browser,

This paper examines and analyzes results from empirical studies that begin to outline some of the that situate how F/OSS systems are developed in different communities. In particular, examples drawn from different F/OSS project communities reveal how processes and practices for the development and propagation of F/OSS technology are intertwined and mutually situated to the benefit of those motivated to use and contribute to it. 12 The future of research in the development and use of STINs as a conceptual lens for observing and analyzing F/OSSD processes and practices seems likely to focus attention to the following topics. First, the focus of software process research is evolving to include attention to sociotechnical processes of people, resources, organizational forms, and institutional rules that embed and surround an F/OSS system, as well as how they interact and interface with one another. Such a focus draws attention to the web of socio-technical relations that interlink people in particular settings to a situated configuration of globally available Web-based artifacts and locally available resources (skills, time, effort, computing) that must collectively be mobilized or brought into alignment in order for a useful F/OSS system to be continuously (re)designed to meet evolving user needs. Second, participation in F/OSS system design, assertion of system requirements, or design decision-making is determined by effort, willingness, and prior public experience in similar situations, rather than by assignment by management or some other administrative authority. Similarly, the openness of the source code/content of a F/OSS system encourages and enables many forms of transparency, access, and ability to customize/localize a system's design to best address user/develope...

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.

Executable source code and non-executable source code: analysis and relationships The concept of source code, understood as the source components used to obtain a binary, ready to execute version of a program, comprises currently more than source code written in a programming language. Specially when we move apart from systemsprogramming and enter the realm of end-user applications, we find source files with documentation, interface specifications, internationalization and localization modules, multimedia files, etc. All of them are source code in the sense that the developer works directly with them, and the application is built automatically using them as input. This paper discusses the relationship between ’classical’ source code (usually written in a programming language) and these other files by analyzing a publiclyavailable software versioning repository. Aspects that have been studied include the nature of the software repository, the different mixtures of source code found in several software projects stored in it, the specialization of developers to the different tasks, etc. 1.

The concept of source code, understood as the source components used to obtain a binary, ready to execute version of a program, comprises currently more than source code written in a programming language. Specially when we move apart from systems-programming and enter the realm of end-user applications, we find source files with documentation, interface specifications, internationalization and localization modules, multimedia files, etc. All of them are source code in the sense that the developer works directly with them, and the application is built automatically using them as input.

Abstract. Open Source Software (OSS) communities have not yet taken full advantage of reuse mechanisms. Typically many OSS projects which share the same application domain and topic, duplicate effort and code, without fully leveraging the vast amounts of available code. This study proposes the empirical evaluation of source code folders of OSS projects in order to determine their actual internal reuse and their potential as shareable, fine-grained and externally reusable software components by future projects. This paper empirically analyses four OSS systems, identifies which components (in the form of folders) are currently being reused internally and studies their coupling characteristics. Stable components (i.e., those which act as service providers rather than service consumers) are shown to be more likely to be reusable. As a means of supporting replication of these successful instances of OSS reuse, source folders with similar patterns are extracted from the studied systems, and identified as externally reusable components. The intended users are members of the OSS development community. Based on the empirical study of the OSS systems and observations made during the study, four practical courses of action are recommended in order to enhance the reusability of current folders that have not been identified as potentially reusable, both from an internal and external standpoint. 1