USENIX Association Proceedings of the FREENIX Track: 2004 USENIX Annual Technical Conference Boston, MA, USA June 27–July 2, 2004 © 2004 by The USENIX Association All Rights Reserved For more information about the USENIX Association: Phone: 1 510 528 8649 FAX: 1 510 548 5738 Email: [email protected] WWW: http://www.usenix.org Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein. Managing Volunteer Activity in Free Software Projects Martin Michlmayr Department of Computer Science and Software Engineering University of Melbourne Victoria, 3010, Australia Centre for Technology Management University of Cambridge Mill Lane Cambridge, CB2 1RX, UK [email protected] Abstract high amount of parallelization in the debugging process. Due to the open nature of the source code in free soft- During the last few years, thousands of volunteers ware projects, anyone can review the code, find defects have created a large body of free software. Even though and contribute bug fixes. Raymond suggested that this this accomplishment shows that the free software devel- ‘bazaar’ model, in which a large number of volunteers opment model works, there are some drawbacks asso- review the code and contribute feedback and patches, ciated with this model. Due to the volunteer nature of is the reason for the success and high quality of many most free software projects, it is impossible to fully rely free software projects. This suggestion meshes well with on participants. Volunteers may become busy and ne- findings in software engineering which show that peer glect their duties. This may lead to a steady decrease review significantly contributes to quality [9]. of quality as work is not being carried out. The prob- Free software development is typically characterized lem of inactive volunteers is intensified by the fact that by two factors. First, free software projects are carried most free software projects are distributed, which makes out by volunteers. Second, the volunteers of a project it hard to quickly identify volunteers who neglect their are distributed. However, not all projects exhibit these duties. This paper shows Debian’s approach to inac- two characteristics. Due to the success of free soft- tive volunteers. Insights presented here can be applied ware, an increasing number of companies get involved to other free software projects in order to implement ef- in free software projects. Some companies allow their fective quality assurance strategies. paid developers to get involved in distributed free soft- ware projects. Also, some software is being developed 1 Introduction in a traditional fashion by paid programmers working in The success of free software in the last few years, in- the same building and is then released as free software. cluding projects such as Linux and Apache, has clearly This example shows that it is important to make a clear demonstrated that the free software development model distinction between the way software is developed and is a viable alternative to proprietary software develop- the license under which it is distributed. A piece of soft- ment. Free software is a matter of liberty, rather than ware can be developed in a traditional way and then be price, since it offers the user more freedom than propri- licensed as free software. However, this paper covers etary software, such as the freedom to run, copy, dis- a certain aspect of software developed according to the tribute, study, change and improve the software. One free software development model, that is, projects which reason for the success of the free software development are distributed and largely carried out by volunteers. model, which is tightly connected to the Unix philos- This free software development model has generated ophy [19], is related to the open nature of free soft- a large amount of very popular and successful software ware: a large number of developers inspect the code in the last few years. Due to the recent popularity of and get involved in a project. Eric S. Raymond studied free software, there is an increasing number of aca- the free software development model in detail and pub- demic studies and papers which concentrate on success- lished his observations in a widely acclaimed paper [18]. ful projects, such as Apache [16], GNOME [14] and During his case study, Raymond found that there is a Linux [20]. However, there are also a large number of unsuccessful free software projects which have not specific to Debian, many lessons can be learned from yet attracted the attention of researchers. SourceForge Debian’s experience of dealing with inactive volunteers. hosts over 70,000 projects, but a large number of them It is my hope that members of other projects will gain a are not actively developed. Since free software projects better understanding of the problem through this paper do not have budgets, there is usually not a specific point and map Debian’s strategies to their respective projects. when unsuccessful projects get wrapped up. It is there- fore hard to identify projects which have been failures. 2 Background Nevertheless, it is clear that some free software projects As discussed in the previous section, volunteers who are fail or have severe quality problems. not performing their duties can have a significant impact The distributed and volunteer nature of free software on the quality of a project. Therefore, it is important to projects make them unique in software development, take this problem into consideration in a project’s qual- and is related to certain advantages, such as the high ity assurance effort. In this section, I will discuss and amount of peer review mentioned previously. However, summarize the problem, and describe why it is such a there are several drawbacks and challenges associated big problem especially for Debian. with the free software development model as well. Due to the volunteer nature of free software projects it is im- 2.1 Inactive Volunteers possible to fully rely on participants [15]. Also, coor- The motivation of volunteers in a free software project is dination and management can be very complex in dis- different than that of paid developers involved in the de- tributed projects with volunteer participants. For exam- velopment of a commercial application. Raymond has ple, it is impossible to put all participants of a distributed observed that developers get involved in free software free software project in a room, give out tasks, and only projects to “scratch an itch” [18]. This explains why cer- leave the room when everyone agrees to perform the tain tasks are not carried out in free software projects. tasks they have been given. For example, most free software projects do not have Free software projects have to deal with these chal- a written specification, simply because writing one is a lenges and find solid solutions. The success of free soft- tedious job most volunteers are not interested in. Simi- ware shows that many challenges have been overcome, larly, users of free software are not in a position to de- and the development model is continuously refined as mand new features from the developers of a project. If more experience is gained. One major challenge, which they require functionality nobody else is interested in is becoming an increasing problem, is volunteers who developing, they can get involved themselves and con- suddenly stop carrying out their duties without inform- tribute to the project, or pay someone to implement the ing others. In many free software projects, volunteers missing features. have specific responsibilities. While a large number There are two schools of thought about the responsi- of participants make infrequent contributions, there are bilities of a volunteer. One school maintains that a vol- some volunteers who play crucial roles in a project, and unteer is free to do whatever they wish at any time and who therefore have to be constantly involved. For exam- does not have any obligation at all. The other school ple, the Linux kernel has a number of trusted lieutenants of thought claims that once a volunteer has agreed to through whom code submissions of specific parts of the perform a specific function they have a responsibility kernel are carried out [17]. They are central to the devel- to fulfill it and to tell others when they cannot perform opment, since other volunteers cannot contribute if the their duties anymore. From a quality assurance perspec- trusted lieutenants do not carry out their work. Simi- tive, it does not really matter what a particular volunteer larly, if the main developer of a very small project be- thinks – certain measures have to be taken in any case. comes inactive, the whole project may come to a halt. However, it is clear that it is easier to work with volun- If such volunteers become inactive, especially without teers who have a certain diligence in their responsibili- informing others so a backup can be arranged, projects ties. Ideally, a volunteer will realize when they can no face important problems. There are therefore two prob- longer perform their function, for example because they lems: a project can stop completely if a core developer are too busy or have lost interest, and will arrange for a becomes inactive, or the quality of a project may suffer. replacement or backup. Unfortunately, experience from It is therefore very important to observe and investi- Debian and other projects shows that this is often not the gate the problem of inactive volunteers from a quality case. assurance perspective and to discuss possible solutions. The problem of inactive volunteers is tightly con- In the following, I will approach this problem from the nected to the nature of the free software development perspective of the Debian Project, and discuss mecha- model.