Open Source Software Development
The discussion of Open Source Software (OSS) development is included in this chapter it has several similarities with other (agile) software development methods, even though it also has its own peculiarities. The combination of the invention of the bulletin board system and the old custom of software developers to share code freely among colleagues was intensified and made possible in global scale with the expansion of the Internet in the ‘90s. This development process inspired a novel software development paradigm of OSS offering an innovative way to produce applications. This has aroused growing interest along with ample research efforts and discussions concerning the possibilities and meaning of the OSS paradigm for the whole software producing industry. This interest has increased notably after several success stories; among these are the Apache server, the Perl programming language, the SendMail mail handler, and the Linux operating system. Microsoft has even pronounced the latter as their toughest competitor in the server operating systems market.
The OSS paradigm suggests the source code to be freely available for modifications and redistribution without any charges. The OSS paradigm can also be discussed from a philosophical perspective. Feller and Fitzgerald (2000) present the following motivations and drivers for OSS development:
- Technological; the need for robust code, faster development cycles, higher standards of quality, reliability and stability, and more open standards and platforms
- Economical; the corporate need for shared cost and shared risk
- Socio-political; scratching a developer’s “personal itch”, peer reputation, desire for “meaningful” work, and community oriented idealism.
Most known OSS development projects are focused on development tools or other platforms that are used by professionals who have often participated in the development effort themselves, thus having the role of the customer and that of the developer at the same time. OSS is not a compilation of well defined and published software development practices constituting a written eloquent method. Instead, it is better described in terms of different licenses for software distribution and as a collaborative way of widely dispersed individuals to produce software with small and frequent increments. The Open Source Initiative keeps track of and grants licenses for software that complies with the OSS definitions. Several researchers, e.g. (Gallivan 2001; Crowston and Scozzi 2002), suggest that an OSS project represents in fact a virtual organization.
Even though Cockburn notes that OSS development differs from the agile development mode in philosophical, economical, and team structural aspects, OSS does in many ways follow the same lines of thought and practices as other agile methods. For example, the OSS development process starts with early and frequent releases, and it lacks many of the traditional mechanisms used for coordinating software development with plans, system level designs, schedules and defined processes. Typically, an OSS project consists of the following visible phases:
- Problem discovery
- Finding volunteers
- Solution identification
- Code development and testing
- Code change review
- Code commit and documentation
- Release management
Even though it is possible to depict the OSS software development methods with the above iteration stages, the interest lies in how this process is managed, as can be seen in how the OSS development method is characterized by Mockus et al. with the following statements:
- The systems are built by potentially large numbers of volunteers
- Work is not assigned; people themselves choose the task they are interested in
- There exists no explicit system level design
- There is no project plan, schedule or list of deliverables
- The system is augmented with small increments
- Programs are tested frequently
According to Feller and Fitzgerald, , the OSS development process is organized as a massive parallel development and debugging effort. This includes loosely-centralized, cooperative and free of charge contributions from individual developers. However, there are also signs that this “free” development idea is changing. The OSS development process does not include any predefined formal documentation norms or customs. However, the process involves customs and taboos that are learned and perceived by experience.
Roles and responsibilities
The OSS development process seems to be quite free and wild. However, it must have some structure, or else it would never have been able to achieve such remarkable results as it has in the past years. Also old and established companies have started to show interest in OSS, among these notably IBM, Apple, Oracle, Corel, Netscape, Intel and Ericsson. In these efforts, especially in larger OSS projects, the named companies have taken the role of the coordinator and that of the mediator, thus acting as project management.
Another new phenomenon is the emergence of the “auction” or repository sites like Freshmeat and SourceForge, which have established development websites with a large repository of Open Source code and applications available on the Internet. These sites commonly provide free services to Open Source developers, including project hosting, version control, bug and issue tracking, project management, backups and archives, along with communication and collaboration resources. As no face-to-face meetings are used in the OSS context, the importance of the Internet is obvious. The development process inevitably needs well functioning versioning software that strictly tracks and allows the submission and prompt testing of new source code. The role of these tools cannot be underestimated, as the developed software must be orchestrated and run continuously, day and night, and the developers themselves have highly varying skill levels and backgrounds.
A typical OSS development effort structure, according to Gallivan, is composed of several levels of volunteers:
- Project leaders who have the overall responsibility for the project and who usually have written the initial code
- Volunteer developers who create and submit code for the project. These can be further specified as:
- Senior members or core developers with broader overall authority
- Peripheral developers producing and submitting code changes
- Occasional contributors
- Maintainers and credited developers
- Other individuals who, in the course of using the software, perform testing, identify bugs and deliver software problem reports
- Posters who participate frequently in newsgroups and discussions, but do no coding.
Sharma et al. state that OSS development projects are usually divided by the main architects or designers into smaller and more easily manageable tasks, which are further handled by individuals or groups. Volunteer developers are divided in individuals or small groups. They select freely the tasks they wish to accomplish. Thus the rational modular division of the overall project is essential to enable a successful outcome of the development process. Furthermore, these sub-tasks must be interesting so as to attract developers.
To start or to acquire an ownership of an OSS project can be done in several ways: to found a new one, to have it handed over by the former owner, or to voluntarily take over an ongoing dying project. Often the actual to-be users themselves define the product (project) and they also do the coding. The process is continuous, as software development is evolving endlessly. Even though hundreds of volunteers may be participating in the OSS development projects, usually there is only a small group of developers performing the main part of the work.
Sharma and the others describe some of the central organizational aspects in the OSS approach, e.g. the division of labor, co-ordination mechanism, distribution of decision-making, organizational boundaries, and informal structure of the project. Mockus and the others characterize the OSS development as follows:
- OSS systems are built by potentially large numbers of volunteers
- Work is not assigned; people undertake the work they choose to undertake
- There is no explicit system-level design, or even detailed design
- There is no project plan, schedule, or list of deliverables.
To work successfully, the geographically dispersed individuals as well as small groups of developers must have well functioning and open communication channels between each other, especially as the developers do not usually meet face-to-face.