Agility and Libre Software Development

Libre Software as A Field of Study

Agility and Libre Software Development Alberto Sillitti and Giancarlo Succi

This paper is copyrighted under the CreativeCommons Attribution-NonCommercial-NoDerivs 2.5 license available at

Agile Methods and Libre Software Development are both popular approaches to software production. Even if they are very different, they present many commonalities such as basic principles and values. In particular, there are many analogies between Libre Software Development and Extreme Programming (focus on the code and embrace of changes to name a few ones). This paper presents such principles and basic values and identifies the commonalities. Keywords: Agile Methods, Extreme Programming, Libre Software.

1 Introduction Agile Methods (AMs) have grown very popular in the last few years [3] and so has Libre Software [1][8]. Even if these approaches to software development seem very different, they present many commonalities, as evidenced by Koch [11]. Both AMs and Libre Software push for a less formal and hierarchical organization of software development and a more human-centric development, with a major emphasis: in focusing on the ultimate goal of development – producing the running system with the correct amount of functionalities. This means that the final system has to include only the minimum number of features able to satisfy completely the actual customer. in eliminating activities related to some ‘formal’ specification documents that have no clear tie with the final outcome of the product. This approach is clearly linked with the Lean Management [16]. AMs acknowledge explicitly their ties with Lean Management [13], while Libre Software keeps them implicit. Moreover, AMs and Libre Software development look similar under several points of view, including: 1. Their roots are both fairly old, but now they have been revamped with a new interest, as it is explicitly acknowledged by Beck [4] for AMs (eXtreme Programming, XP, in particular) and evidenced by Fuggetta for Libre Software [10]. 2. They are both disruptive [6], in the sense that they alter established values in software production. 3. There are successes of both, whereas more traditional approaches have failed (the C3 project for AMs [4] and the Mozilla/Firefox browser for Libre Software [7][12]). 4. Proposers of AMs are also participating at Libre Software development (e.g. Beck with JUnit). This paper aims at providing an overview of the commonalities between Agile Methods (XP in particular) and Libre Software from the point of view of the basic principles and values these two communities share. © Novática

The paper is organized as follows: Section 2 identifies the general Agile Principles in Libre Software; Sections 3 focuses on specific XP values and principles and identifies them in Libre Software; finally, Section 4 draws the conclusions and proposes further investigation.

2 Agile Principles in Libre Software The basic principles shared by all AMs are listed in the so-called Agile Manifesto [2]. Table 1 identifies the principles of the AMs in Libre Software. Altogether, it is evident that Libre Software 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 Libre Software are 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 Libre Software really occurs in practice, beyond considerations that, left alone, ends up being quite useless.

3 XP Values and Principles in Libre Software Besides the commonalities between Libre Software and the AMs in general, it is interesting to analyze this relationship between Libre Software and one of the most popular AM: Extreme Programming. Alberto Sillitti, PhD, PEng, is Assistant Professor at the Free University of Bozen, Italy. He is involved in several European Union funded projects in the software engineering area related to agile methods and open source software. His research areas include software engineering, component-based software engineering, integration and measures of web services, agile methods, and open source. Giancarlo Succi, PhD, PEng, is Professor of Software Engineering and Director of the Center for Applied Software Engineering at the Free University of Bozen, Italy. His research areas include agile methods, open source development, empirical software engineering, software product lines, software reuse, and software engineering over the Internet. He is author of more than 100 papers published in international conferences and journals, and of one book.

UPGRADE Vol. VI, No. 3, June 2005

33

Libre Software as A Field of Study XP is centered in four major values (a comprehensive discussion is in the two editions of Beck’s book [4][5]): 1. Communication: developers need to exchange information and ideas on the project among each other, to the managers, and to the customer in an honest, trusted and easy way. Information must flow seamless and fast. 2. Simplicity: simple solutions have to be chosen wherever possible. This does not mean to be wrong or to take simplistic approaches. Beck often uses the aphorism "simple but not too simple". 3. Feedback: at all levels people should get very fast feedback on what they do. Customers, managers, and developers have to achieve a common understanding of the goal of the project, and also about the current status of the project, what customers really need first and what are their priorities, and what developers can do and in what time. This is clearly strongly connected with communications. There should be immediate feedback also from the work people are doing, that is, from the code being produced – this entails frequent tests, integrations, versions, and releases. 4. Courage: every stakeholder involved in the project should have the courage (and the right) to present her/ his position on the project. Everyone should have the courage to be open and to let everyone inspect and also modify his/her work. Changes should not be viewed with terror and developers should have the courage to find better solutions and to modify the code whenever needed and feasible. These values are present in various ways in Raymond’s description of Open Source (Raymond, 2000) and summarized in Table 2. Moreover, as noted in [9], hidden inside the first version of Beck’s book [4] there are 15 principles, divided into 5 fundamental principles and 10 other principles. The fundamental principles are: 1. Rapid Feedback: going back to the value of feedback, such feedback should occur as early as possible, to have the highest impact in the project and limiting to the highest extent the possible disruptions. 2. Assume Simplicity: As mentioned, simplicity is a major value. Therefore, simplicity should be assumed everywhere in development. 3. Incremental Change: change (mostly resulting from feedback) should not be done all at once. Rather, should be a permanent and incremental project, aimed at creating an evolving system. 4. Embracing Change: change should be handled with courage and not avoided. The system as a whole, and the code, should be organized to facilitate change to the largest possible extent. 5. Quality Work: quality should be the paramount concern. Lack of quality generates rework and waste that should be avoided to the large degree. Other principles of XP are: 1. Teach Learning: requirement elicitation is an overall learning process. Therefore, learning is of paramount im-

34


portance in the system. 2. Small Initial Investment: the upfront work should be kept as minimum as possible, as subsequent changes may destroy it. 3. Play to Win: all the development should be guided by the clear consciousness that what we do is effectively doable. 4. Concrete Experiments: the ideas should be validated not though lengthy and theoretical discussions but via concrete experimentations on the code base. 5. Open, honest Communication: the communication should be kept simple and easy. The customer should not hide his/her priorities nor the developers and the managers should hide the current status of the work. 6. Work with people’s instincts - not against them: the role of the managers is to get the best out of developers, so their natural inclinations should be exploited. A strong team spirit should be exploited. Moreover, in the interactions between managers, developers, and customers, the fears, anxieties, discomforts should not be ignored but properly handled. 7. Accepted Responsibility: all the people in the project should voluntary take their own responsibilities, customers, managers, and developers. Such responsibilities should then be assigned with complete trust. 8. Local Adaptation: the methodology should be wisely adapted to the needs of each development context. 9. Travel Light: in XP projects it is important to keep the lowest amount of documents possible, clearly without compromising the integrity of the project. 10. Honest Measurement: the project should be tracked with objective and understandable measures. The measures should be collected in a lean way not to alter the nature of XP. In this section we review the application in Open Source of the fundamental principles: rapid feedback, assume simplicity, incremental change, embracing change, quality work. We have already discussed the issue of feedback and simplicity from Beck’s point of view. Fowler [9] shares most of the Beck’s point of view and he stresses the continuous improvement of the source code making it the simplest as possible. Regarding the incremental changes, Raymond [14] acknowledges upfront it as one of its guiding principles since his early Unix experience: "I had been preaching the Unix gospel of small tools, rapid prototyping and evolutionary programming for years". As for embracing changes proposed by others, we have already mentioned Raymond’s opinion [14] on listening to customers even if they do not "pay you in money". He goes further and in rule number 12 he states the pivotal role of embracing the change: "Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong". Raymond [14] goes further than Beck [4] on this subject. Both agree that prototypes (‘spikes’ in Beck jargon) can be instrumental to achieve a better understanding of a

© Novática


Principles of the Ams

Identification in Libre Software

Individuals and interactions over processes and tools

The development process in Open Source communities definitely puts more emphasis on individual and interaction rather than on processes and tools.

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The interactions in Open Source communities, though, tend to me mainly based on emails; the pride and the individuality of the developer, though, become predominant, while in Agile Methods there is a strong push toward establishing team spirit among developers. Both Agile Methods and Open Source development view the working code as the major supplier of documentation. In Open Source communities the most common forms of user documentation are screenshots and users forums (Twidale and 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, bugtracking databases, and outputs from differences between versions. In Libre Software customers and developers often coincide. This was especially true in the early era of Libre Software, when it was clearly said, for instance, that Unix (and later Linux and the GNU tools) 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 Libre Software licenses of various kinds. Following the discussion above on “Customer collaboration over contract negotiation”, the evolution of an Open Source project typically is customer driven. It appears that Libre Software 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 interesting to see how this situation would evolve in the newer scenarios where there are customers separated from developers.

Table 1: Principles of the AMs in Libre Software.

complex application domain. Raymond [14] also claims that the system being developed can help identifying new ideas for new developments – rule 14: "Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected". Needless to say, when drafting rule 14 Raymond is not concerned in ensuring the customer that he will not waste customer’s resources. Regarding quality work, in Raymond [4] there is not an explicit reference to the paramount role of quality as it is in Beck [4]. However, throughout the essay there is a constant evidence of the pride that Open Source developers put in their code, a pride that comes only from deploying quality work. Now we turn our attention to the other principles: teach learning; small initial investment; play to win; concrete experiments; open, honest communication; work with people’s instincts - not against them; accepted responsibility; local adaptation; travel light; honest measurement. Raymond emphasizes the role of listening and learning © Novática

from other’s comments. However, there is not an explicit mention to teaching learning. There is also little concern of not having small initial investment and travel light. The reason is that Open Source projects are lead more by developers, less likely to spend ages in the "analysis paralysis" or in producing useless documentation and more concerned on delivering useful code. Rather, the attention of Raymond [14] is on evidencing that a little bit of upfront work is required "When you start building a community, what you need to be able to present is a plausible promise. Your program doesn’t have to work particularly well. It can be crude, buggy, incomplete, and poorly documented. What it must not fail to do is (a) run, and (b) convince potential co-developers that it can be evolved into something really neat in the foreseeable future". Playing to win and concrete experiments are an integral part of any self-motivated effort, so it does not require any further explanation. Discussing values, we have already evidences the role


35


XP value

Identification in Libre Software

Communication

The very same concept of Open Source is about sharing ideas via the source code, which becomes a propeller for communication. So, with no doubt communication is a major value in the work of Raymond [14].

Simplicity

Feedback

The role of communications is reinforced by Raymond throughout his essay [14]. He clearly states the paramount importance of listening to customers “But if you are writing for the world, you need to listen to your customers – this does not change just because they’re not paying you in money.” Then, it is evidenced that to lead an Open Source project good communication and people skills are very important: he carries as examples Linus Torvald and himself, allegedly, two people capable of motivating and communicating. Simplicity in the system is highly regarded in the Open Source community. In general, Raymond [14] mentions the “constructive laziness,” which helps in finding existing solutions that can be adapted to new situations. Beck's concept of simplicity [4] is clearly reflected in rule number 13 of Raymond [14]; it is an excerpt from Antoine de Saint’Exupéry: “Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away”. Working in a distributed community, Raymond [14] acknowledges the value of a fast feedback at all levels: • between distributed developers, potentially working on the same fix • between developers and customers – rule number 11 is a clear example: “The next best thing to having good ideas is to recognize good ideas from your users. Sometimes the latter is better”. Feedback is achieved especially running and testing the code, this is why early and frequent releases are instrumental – rule 7 says “Release early, release often. And listen to your customers”.

Courage

Needless to say most of the comments made about feedback could apply as well to communication. This is not awkward. Beck [4] acknowledges explicitly that the two concepts overlap. The value of courage is less present in the presentation of Raymond [14]. He hints at courage when he presents the initial difficulty in getting the work exposed to “thousands of eager co-developers pounding at every single new release”.

Table 2: XP values in Libre Software.

given by Raymond (2000) to an open, honest communication. Being developer-centric, Open Source also advocates working with people’s instincts - not against them and relies on accepted responsibility. The very first two rules of Raymond are "Every good work of software starts by scratching a developer’s personal itch", and "Good programmers know what to write. Great ones know what to rewrite (and reuse)". Also rule 4 appears quite applicable: "If you have the right attitude, interesting problems will find you". While there is no formal measurement in place in Raymond’s essay [14], there is an emphasis on releasing often, thus making clear the status of the project and the bugs still presents. This resembles honest measurement.

4 Conclusions Altogether, we note that there is a pretty high level of 36


overlap between the values adopted by AM (XP in particular) and those of Open Source development according to Raymond. Communication, feedback and simplicity are fully endorsed. Courage is also implicitly assumed to carry out an Open Source project. Going to the principles, there is still a good level of agreement in the fundamental principles, apart from quality that in Raymond’s work is assumed, rather than advocated. For the "other principles" of XP, the only differences come from the different point of view: Raymond deals with mostly volunteers, while Beck mostly with employees. Concepts such as traveling light, limited upfront design, etc., do not concern particularly Raymond that, on the other hand, is more interested that the open source developers do at least a little bit of design upfront. As to the practices, clearly the situation is quite different. Practices related to process, shared understanding and programmer welfare are somewhat similar in the two cases. © Novática

Libre Software as A Field of Study Practices related to fine-scale feedback are not so widely present in the description of Raymond. As a final note, we would like to evidence that both Beck’s and Raymond’s experience comes from an early use of very easy to employ, expressive, and powerful programming languages: Smalltalk and Lisp respectively. An analysis of the role of programming languages in AMs and in Libre Software development could be an interesting subject for a further study. References [1] P. Abrahamsson, O. Salo, and J. Ronkainen. Agile software development methods, VTT Publications, 2002. [accessed on June 15 2005]. [2] Agile Alliance, Agile Manifesto, 2001. [accessed on June 15 2005]. [3] L. Barnett. "Teams Begin Adopting Agile Processes". Forrester Research, November 2004. [4] K. Beck. Extreme Programming Explained: Embracing Change, Addison Wesley, 1999. [5] K. Beck. Extreme Programming Explained: Embracing Change, Second Edition, Addison Wesley, 2004. [6] C.M. Christensen. The Innovator’s Dilemma, Harper Business, 2003. [7] M.A. Cusumano, D.B. Yoffie. Competing on Internet Time: Lessons From Netscape & Its Battle with Microsoft, Free Press, 1998. [8] J. Feller, B. Fitzgerald. Understanding Open Source Software Development, Addison-Wesley, 2002. [9] M. Fowler. Principles of XP, 2003. [accessed on June 15 2005]. [10] A. Fuggetta. "Open Source Software – an Evaluation", Journal of Systems and Software, 66(1), 2003. [11] S. Koch. "Agile Principles and Open Source Software Development: A Theoretical and Empirical Discussion", 5th International Conference on eXtreme Programming and Agile Processes in Software Engineering (XP2004), Garmisch-Partenkirchen, Germany, 6 - 10 June, 2004. [12] S. Krishnamurthy. "The Launching of Mozilla Firefox - A Case Study in Community-Led Marketing", 2005. [accessed on June 15 2005]. [13] M. Poppendieck, T. Poppendieck. Lean Software Development: An Agile Toolkit for Software Development Managers, Addison Wesley, 2003. [14] E.S. Raymond. The Cathedral and the Bazar, Version 3.0, 2002. [accessed on June 15 2005]. Also published by O’Reilly in 2001. [15] M.B. Twidale, D.M. Nichols. "Exploring Usability Discussions in Open Source Development", 38th Hawaii International Conference on System Sciences, 2005. . [16] J.P. Womack, D.T. Jones. Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated, Free Press, 2003.

© Novática


37