Increase in efficiency of free software projects through information management Robert Schuster Working group Software Engineering Freie Universität Berlin 2005-05-17 Abstract Free and Open Source Software is an enduring undertaking. How- ever this does not mean that this development model has no flaws. This paper will present a problem of the F/OSS development pro- cess that results from insufficient care for information management. I will outline the factors that lead to this problem and propose a light- weight process enhancement to cope with it. This enhancement will 1 introduce a role named “mediator” - a person whose task it is to make it easier for new developers to enter the project and support the knowledge transfer between developers. The role is then imple- mented in the project GNU Classpath and evaluated by it's develop- ers with the help of a survey. The key aspects of mediation are sum- marized and abstracted in form of a short manual which is targetted for use by any F/OSS project. Contents 1 Introduction 3 1.1 Disambiguation . 4 1.2 Categories and conditions of F/OSS projects . 5 1.2.1 Categories . 5 1.2.2 Environment and conditions . 8 1.2.3 Definition of success . 11 2 Introducing mediation 13 2.1 Which difficulties exist? . 13 2.2 The idea of mediation . 13 2.3 Selected tasks . 14 2.4 Project properties supporting the success of the mediation role . 15 2.5 Related works . 16 3 Implementing the mediator 18 3.1 Introduction to GNU Classpath . 18 3.2 Why GNU Classpath has been chosen for exemplifying me- diation . 18 3.3 Formulation of the invitation mail . 19 3.4 Conclusion . 21 3.5 Task and procedure of Classpath's mediator . 21 3.6 Further ideas . 23 3.7 Guidelines for the daily work . 24 3.8 Dealing with problematic situations . 24 3.9 Chosing the tools . 25 3.10 Implementation and problems . 27 3.11 Announcement . 29 2 4 The mediation manual 29 4.1 Announcement I . 30 4.1.1 Procedure . 30 4.1.2 Reactions . 31 4.2 Conclusion . 33 5 Analysis of the practical implementation 33 5.1 Results . 34 6 Conclusion and perspective 35 A Invitation mail for GNU Classpath 36 B Announcement mail of the mediation Wiki 38 C Mediation Manual 39 D Announcement template for mediation manual 46 E Survey 46 References 56 1 Introduction After more than 20 years of Free and Open Source Software (F/OSS) de- velopment it should have been proved that this model is enduring. I leave the question whether F/OSS will ever dominate the software market to someone else and focus on lowering their entry level and improving the maintainability of these ever-evolving software projects. As F/OSS projects get older it gets more difficult for newcomers to join it and they are less manageable for a single person. Part of this problem is that the development process is seldom documented consistently (e.g. archival of architectural decisions). This thesis will demonstrate “media- tion” as one solution to get these defficiency under control. Bigger F/OSS projects consist of a distributed team of developers which often crosses timezones and cultural borders. While this may be good for creativity and balance between interests this makes project management 3 more difficult. The problems manifest themself when making an appoint- ment or when a debate gets hot because of different cultural tempers. Usually F/OSS developers are motivated intrinsically which means they do programming for the fun of it. Again this is quite good for the actual result but it means that less amusing work like writing documenta- tion gets neglected. Furthermore being on his own means that a developer can completely chose his development environment and tools. Communication and knowledge transfer is dominated by mailing list and Internet Relay Chat (IRC) usage. These systems are not designed for information management and make it hard to use it for them as the project's library. The goal of this thesis is to define a light-weight process enhancement, which minds the factors stated above and heightens the efficiency of the project. The enhancement named “mediation” will introduce the role of a project member who explicitly cares about the project's information, writes important issues (e.g. outcome of a discussion) down and makes them available for future reference by new and long-established develop- ers. I will install “mediation” in the project GNU Classpath1 where the en- hancement will be tested and qualitative advantages (as well as disadvan- tages) recorded. Eventually the key ideas of the process enhancement will be abstracted and compiled as a set of guidelines for other projects as well. 1.1 Disambiguation For this thesis I use the term Free and Open Source software (F/OSS). However in general I prefer the shorter and older (1984) free software def- inition2 and not the newer term “open source” which was coined 1998 by the Open Source Intiative and describes itself as “a marketing program for free software”3. 1http://classpath.org 2http://www.gnu.org/philosophy/free-sw.html 3http://opensource.org/advocacy/faq.php - How is "open source" related to "free software"? 4 Finally the project which is presented as part of this thesis describes itself as a free software project and it would be hard to find the reason for it's existence by being “on solid pragmatic grounds” only, as the OSI says it. 1.2 Categories and conditions of F/OSS projects As a base work for the presentation of my process enhancement I will categorize F/OSS projects and describe their development and sometimes social conditions. In later sections I will make back references to the issues explained here. 1.2.1 Categories This section will give you an overview of categories of F/OSS projects which is simplified to fit in the context of this thesis. Using the following terms allows me to quickly describe the characteristics of a project at a later time. Single Person Projects Any F/OSS project that has only member who is responsible for the de- velopment of the software is a “single person project”. Undertaking of this kind tend to be short-lived because when the initial motivation of the founder goes away no developer is left to take over the maintainer- ship. While one may be tempted to think that this is a great loss for the F/OSS community which makes it less productive, maintaining a non- critical software for a while is a valuable experience for newcomers: The project founder learns the basics of administration like setting up a source code respository, maintaining mailing-lists and a project homepage. This knowledge can then be useful when participating in an established and bigger project. A single person project may evolve into some of the other project forms when more developers get interested and join it. Eventually there are a 5 few projects which become successful but stay maintained by a single per- son for a long time. Examples of this kind are the QEmu4 multiple CPU emulator and the cdrecord tools by Jörg Schilling5. Community-based project A large number of applications serve the need of the free and opensource community and have been created as some members of the community felt the need for such a program. Sometimes a group of developers gathers around a piece of source code that was once proprietary and got released by its copyright holder. Projects that belong to this category make up the backbone of the F/OSS community because of their large amount and the wealth of knowledge that is contained in them. A main characteristic of these projects is that there is not much commercial interest. That leads to very informal project management styles where every aspect relies purely on social interactions of its members. One can safely say that they are the most free and inde- pendent projects. Organised community project Since the early days of the F/OSS development people have organised themselves in larger communities where an individual project is part of the main goal of this community. These communities usually provide a common code guide, documentation rules and guidelines for project man- agement. The oldest communities have been formed around the BSD and the GNU project. In the recent times we can see the development of the Apache, Debian, KDE an Mozilla communities. While some of them have formed legal entities like the Free Software Foundation6, the Apache Software Foundation7 or the Mozilla Foundation8 others remain an informal group but are nevertheless known in the whole F/OSS community. 4http://www.qemu.org 5http://cdrecord.berlios.de 6http://www.fsf.org 7http://www.apache.org/foundation 8http://www.mozilla.org/foundation 6 An important fact about these groups is that they are mutually depen- dent (e.g. Apache web server running on OpenBSD, being compiled by the GCC) and often developers dedicated to one group work partly on other (e.g. porting GNU software to the BSD platform). Software projects belonging to such a group usually inherit their guidelines9 and are thus more organised then their completely unbound counterparts. As an exam- ple the GNU projects publishes and maintains their “GNU Coding Stan- dards”10. These guidelines not only manifest itself as documents but find their way into GNU applications, too: The Automake program is used to simplify the construction of software11. In the default operating mode it expects a certain set of files which is defined in the GNU coding standards (see Automake Manual12) and can only be overridden by a command line switch named “–foreign”.