The Agile Manifesto and Open Source Software

The Agile Manifesto and Open Source Software

Barbara Russo (Free University of Bozen-Balzano, Italy), Marco Scotto (Free University of Bozen-Balzano, Italy), Alberto Sillitti (Free University of Bozen-Balzano, Italy) and Giancarlo Succi (Free University of Bozen-Balzano, Italy)
Copyright: © 2010 |Pages: 7
DOI: 10.4018/978-1-59904-681-5.ch002
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

The four main statements shared by all AMs are listed in the so-called Agile Manifesto: 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a plan In this section, we review these statements to determine the extent to which they apply to OSS.
Chapter Preview
Top

2.1 Introduction

The four main statements shared by all AMs are listed in the so-called Agile Manifesto1:

  • 1.

    Individuals and interactions over processes and tools

  • 2.

    Working software over comprehensive documentation

  • 3.

    Customer collaboration over contract negotiation

  • 4.

    Responding to change over following a plan

In this section, we review these statements to determine the extent to which they apply to OSS.

2.1.1 Individuals Over Processes and Tools

The development process in OS communities definitely puts more emphasis on individual and interaction rather than on processes and tools. The interactions in OS communities, though, tend to be mainly based on emails; the pride and the individuality of the developer, though, become predominant, while in AMs there is a strong push toward establishing team spirit among developers.

2.1.2 Working Software Over Comprehensive Documentation

Both AMs and OSD view the working code as the major supplier of documentation. In OS communities the most common forms of user documentation are screenshots and users forums (Twidale & Nichols, 2005), which both come from the direct use of the systems, and the most common source of technical documentation are class hierarchies directly extracted from the code, bug-tracking databases, outputs from diffs between versions, etc.

2.1.3 Customer Collaboration Over Contract Negotiation

In OSS, customers and developers often coincide. This was especially true in the early era of OSS, when it was clearly said, for instance, that Unix was a system developed by developers and for developers. In such cases, the systems are clearly customer driven. There are now situations where the customers are clearly separated from developers. New systems such as Subversion, ArgoUML, etc., have a clear customer base, separated from the developers. Still, looking at how the releases occur, the functionalities are added, and the problems are solved it appears that the system is developed with a clear focus on customer collaboration. Moreover, in Europe it is becoming more popular the request that systems developed with public funds are releases with OSS licenses of various kinds.

2.1.4 Responding to Change Over Following a Plan

Following the discussion above on “Customer collaboration over contract negotiation”, the evolution of an OS project typically is customer driven. It appears that OS systems do not have a “Big Design Upfront”; they are pulled rather than pushed and their evolution depends on real needs from the customers. However, most of such analysis is based on situations where customers and developers coincide. It would be interested to see how this situation would evolve in the newer scenarios where there are customers separated from developers. Altogether, it is evident that OS adopts most of the values fostered by supporters of AMs. Such evidence calls for subsequent analysis to determine the extent and the depth of such adoption. Moreover, AMs and OSD classes of software development methods, which include a wide number of specific methods. Therefore, it is important to consider specific instances of them to determine how the interactions between AMs and OSD really occurs in practice, beyond considerations that, left alone, ends up being quite useless.

Complete Chapter List

Search this Book:
Reset