This paper explores the notion of leadership in open source software development projects. This paper departs from the discussion of leadership in Learner and Tiroles working paper "The Simple Economics of Open Source". My paper argues that leaders in open source projects only have indirect means of influence on what co-developers should develop. It is shown that leaders are beggars for help and contributions from co-developers, when the project starts up. But leaders become choosers, if a project becomes successful and attracts the attention of productive co-developers. The paper discusses the source of power of the open source project leaders as well.
Contents
Introduction
The Good
The Critique
Conclusion
Further Research
Introduction
This is a paper inspired by the working paper "The Simple Economics of Open Source" by Josh Learner and Jean Tirole [ 1 ]. Learner and Tirole discuss the economics of open sources and use the economics of career concerns to explain why people engage in developing open source software (OSS). Learner and Tirole conclude that "The literature on ‘career concerns’ provides a lens through which the structure of open source projects, the role of contributors, and the movement’s ongoing evolution can be viewed" [2 ].
Learner and Tirole analyse the leadership of OSS development projects and explain how leadership functions. They conclude that a successful OSS project must provide a vision [3 ] and divide the project into smaller subprojects or "modules". At first the leader must establish a critical amount of code that persuade other programmers to join the project.
The leadership discussion in Learner and Tirole arguably takes up relatively little space of their paper (four pages) and is not their main ambition. Learner and Tirole do, however, initiate an interesting discussion. My paper is a contribution to the debate.
This paper starts by examining some of the excellent arguments in Learner and Tirole's working paper. Next, I critically examine Learner and Tirole's understanding of leadership. In the course of this discussion, alternate understandings of some of Learner and Tirole's points are presented. The main points of this paper is then summarised in the conclusion, and suggestions for further research are presented.
The Good
Learner and Tirole's working paper provides the reader with an interesting background to the history of open source software and a presentation of three open software development projects - Apache, Perl and Sendmail. These three illustrative cases provide materials from which Learner and Tirole generalise and draw their conclusions.
Other papers treating open source software development often use non-conventional economic theory [4 ] or theories from psychology [5 ] and anthropology [6 ] to explain why open source software is developed.
Learner and Tirole apply economic theory from the literature of career concerns and reach a plausible conclusion as to why people engage in open source software development.
The Critique
Learner and Tirole state four points which the leader of an OSS project ‘must’ do in order to create and maintain a successful open source software development project:
- Provide a vision;
- Divide the project into smaller and well-defined tasks (modules);
- Attract programmers; and,
- Keep the project together.
Learner and Tirole use the term "leader" to describe the person acting as the central point of development. More often than not the "leader" is the person who started the project by creating the first working version. The term "leader" seems a poor choice, since in the open source community most people are working for free. No leader in an open source project has the equivalent power of a leader in a private or public company. These real leaders possess the power to discharge people or in other ways affect the employee’s situation. In the OSS community the leader of an open source software development project is referred to as the maintainer. This paper will, however, adopt Learner and Tirole's concept of a leader in an effort not to confuse matters.
I will now examine four important points.
Provide a vision
How does a leader provide a vision in an OSS project? According to Learner and Tirole two things are important 1) A vision seems to stem from the leader assembling critical mass of code to which the community can react [ 7 ]. 2) Vision stems from the project offering plenty of exciting programming experiences and not being "dead end" [8 ].
First, this point seems to fit my experience from reading newsgroups and discussing with people in the community. No open source software project has ever (to my knowledge) been started by someone asking for contributions without having provided a working demonstration of their idea. The common response in newsgroups, when people ask for help without a working demo, is something in the line of: "Interesting idea, let’s see some working code". It shall be noted that it is the leader himself which has to produce the sample code which demonstrates the wanted functionality.
Second, this point is implying that the leader have a blueprint of the project and only shows the minimal working demo, thus saving interesting tasks for others to complete. This argument is exemplified with Linus Torvalds' [9 ] initial posting on the newsgroup: comp.os.minix where Linus Torvalds called for fellow programmers to join his effort [10 ]. This particular example is not well chosen. The situation today is radically different from the situation in 1991 where most of the PC users wanting Unix had to use Minix. Minix was a very small Unix-like operating system developed by Andy Tannenbaum of the Free University of Amsterdam. Minix was developed as an educational tool for use in his operating systems design classes. Minix was, however the only Unix-like operating system available for the PC computer platform which may be the reason behind its success. The Minix community numbered approximately forty thousand, and included many very talented software developers [11 ]. Nikolai Bezroukov has demonstrated that the success of the Linux development might be, at least in part, due to the successful hijacking of parts of the Minix community.
Most OSS projects are rather chaotic in their development path showing several changes in basic design. The Apache project started as a number of patches [12 ], which were later restructured and organised. The Apache program was later completely rewritten reflecting the experience gained from the past. I do not believe that any leader had anticipated one or more complete rewrites in the early stages of the project. The Linux kernel demonstrated the same history [13 ], where the kernel went through a major rewrite to accommodate portability to other platforms. Again the rewrite could not have been anticipated but were initiated by a change in the program environment. It seems that these rewrites were not trivial and might easily reflect what Learner and Tirole define as challenging and interesting programming experiences. These rewrites were, however, not a consequence of good planning or leadership, but came out of necessity. There is no evidence indicating that leaders hide or delegate interesting programming experiences to attract co-developers, nor do Learner and Tirole provide any.
An Alternative Way to Provide a Vision
Departing from the understanding of Learner and Tirole, I shall present an alternative way to understand how vision is provided and by what.
To illustrate this, the phases of an OSS project must be defined. An OSS project consists of three phases: 1) The leader writes the initial code, which serves as a plausible promise to potential co-developers; 2) general development phase and attraction of co-developers; and, 3) decline in development intensity as the project matures or other projects hijack the co-developers.
The development of the Fetchmail program [ 14 ] illustrates the three phases. In short Fetchmail is descending from a program named "Popclient" by Chris Harris, a program which can retrieve e-mail over a PPP connection from a POP server. When Eric S. Raymond (ESR) took over the project in June 1996, there had been little or no development in a period of time, and users as well as co-developers were dropping off the project. ESR began by adding some features which had been absent and were needed. Having a working program along with a number of bug-fixed and added features, Fetchmail began to accumulate users again. Along with the user base came a number of co-developers [15 ] which began to submit ideas, bug reports, and even patches.
This new and increased activity in the project showed a plausible promise, and interested users and potential co-developers began to use the program and participate in the development.
Having shoved a plausible promise, the project entered the development phase. A continued stream of new versions and patches demonstrating bug-fixes and new features kept users and co-developers persuaded of the continued evolution of the project. In this phase many new features were added, and at some point it became clear that the basic design of the program had to be rewritten to allow for ease of extension to use new mail protocols and new features. In October 1997 the Fetchmail program was declared out of development and in maintenance.
This marks the third and final phase of the development process, decline in development intensity. In the case of Fetchmail the project enter this phase gracefully by announcing itself to be out of development. Since this announcement the development intensity had been low, and only maintenance is being performed. Maintenance denotes that all or most of the features needed are considered to be present, and just the occasional odd bug has to be fixed.
The decline in development intensity does not imply that the software in question is going to be replaced by another, newer software, nor does it mean that the user base is declining. It means that the software has reached a level of maturity, which meets most needs. One could say that the effort of continued development does not match the added satisfaction from new features.
The Software Provides the Vision
In the first phase the project leader provides a working example of the program. This working example, when tried and tested by potential co-developers, provides a vision which encourages potential co-developers to participate in the development effort. It is the vision of what the co-developer wants from the software that triggers the programming effort. I believe that the vision provided by the project leader has little impact on the vision generated by the co-developer. The leader may provide a vision expressed through two different media. First, a vision is provided by the working example of the software. Second, a vision may be provided by a written statement, which explicitly states the hopes and expectations for the software to be developed. Linus Torvalds had a clear vision in one of the initial statements:
"I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I'd like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things). [….] " [16 ]
Well, this is a call for arms, come join the development of my (Linus Torvalds) new operating system. This post caught the attention of users and potential co-developers for it is not every day a new operating system is born. But without an example with some working code, the above statement would have been nothing but hot air. The code showed potential co-developers that the operating system was interesting and had perspective. In short, the code provided a vision.
The limited communications bandwidth between the project leader and the co-developers makes it impossible for the leader to influence the vision of co-developers through other media than the code. The co-developer may spend 5-10 minutes reading a statement or a mail but countless hours working on the code. What to develop and how to contribute to the development stems from a vision formed by the co-developers when interacting with the code.
Divide the Project into Smaller and Well-Defined Tasks (modules)
"The leader must [….], (b) make sure that the overall project is divided into much smaller and well defined tasks ("modules"), which individuals can tackle independently from others" [17 ].
The project leader is the source of creating and defining smaller tasks (modules). The project leader is thus actively defining the tasks and delegating the work of others, Learner and Tirole note:
"Most leaders are programmers who developed the initial code for the project (or made another important contribution early in the project’s development)."
By being the initiator and/or producing the first code one becomes the leader of an OSS development project. Following this logic, the leader will assume responsibility for the defined tasks and modules and become the leader of these sub-projects. Even if no working code is produced to demonstrate the idea it seems plausible that the project leader - by defining the problems and modules - has made sufficient contribution to become the defacto leader of a task or module. Being the leader of a project and additional modules with different code must increase the workload of the leader.
I doubt that the aim of defining modules and smaller tasks was to increase the workload of the leader. Rather, must the intention of delegating the work have been to reduce the workload.
It is evident that many open source projects get divided into modules, but the above logic implies that it should not be the task of the project leader to define these modules if he is interested in reducing his own workload.
The leader has no guarantee that any co-developer will follow any suggestions and start coding modules, if the project leader says so. It should be remembered that open source software development is done mostly for free, and that one of the prime motivating factors is the fun of programming. Receiving an assignment may miss all the elements that makes programming fun such as defining and solving the problem at hand and the creative fun of making something new on your own.
Also, co-developers might have a different vision that does not entail any of the modules specified by the project leader, then why start coding these little interesting modules? The co-developer might indeed be more inclined to develop some module, which he himself finds useful, thus "enjoying" the fun of programming.
The Leader has No Say?
So, the project leader has no say at all? The leader supports modularization and extensibility thus making it possible for co-developers to create modules, without the support of the project leader. This way co-developers may add any feature or functionality he might need, and which supports his vision of the program. The Apache project illustrated this point:
"In the Apache project, we were fortunate in that early on we developed an internal API [18 ]to allow us to distinguish between the core server functionality [….] and most other higher-level functionality like logging, a module for CGI, server side includes, security configuration, etc. Having a really powerful API has also allowed us to hand off other big pieces of functionality, such as mod_perl [….] to separate groups of dedicated developers. This freed the core development group from having to worry about building a ‘monster’ [….]." Brian Behlendorf [19 ], Apache core developer.
This quote demonstrates the function of the leader in an open source project regarding modules. The leader must facilitate and encourage modules as a way contributing to the project without major changes to the core program. The Apache project shows a polished example, where a documented API is developed and enables co-developers to add functionality to the project without burdening the project leader.
The leaders of the GNOME [20 ] open source project agree with the principles expressed by the Brian Behlendorf of the Apache Project and have written an introduction to potential co-developers who wish to contribute. An excerpt:
"Cleanliness. Clean code is easy to read; this lets people read it with minimum effort so that they can understand it easily.Consistency. Consistent code makes it easy for people to understand how a program works; when reading consistent code, one subconsciously forms a number of assumptions and expectations about how the code works, so it is easier and safer to make modifications to it.
Extensibility. General-purpose code is easier to reuse and modify than very specific code with lots of hardcoded assumptions. When someone wants to add a new feature to a program, it will obviously be easier to do so if the code was designed to be extensible from the beginning. Code that was not written this way may lead people into having to implement ugly hacks to add features.
Correctness. Finally, code that is designed to be correct lets people spend less time worrying about bugs and more time enhancing the features of a program. Users also appreciate correct code, since nobody likes software that crashes."[21 ]
This quote illustrates a clear understanding of the need for writing programs in such a way that they may be extended beyond the original purpose. It is the responsibility of every co-developer to fulfil the above requirements but the leader must assume a special responsibility since the leader lay the foundation for others to build upon.
Defining modules and tasks in an open source software development project is not the task of the leader. The leader should encourage the creation of modules and added functionality by providing a program coded in such a way that potential co-developers easily can make contributions and modules. If a project grows large and there is a vast interest in creating modules, the leader should consider creating an API (like the Apache project) and documenting this, thus making it very easy for co-developers to make modules with special functionality.
Attract Programmers
According to Learner and Tirole, co-developers are attracted to a project by inspiring programming problems. The leader should not solve all problems by himself but make sure that challenging programming tasks remain for co-developers to solve. The leadership qualities of the project leader are important for it has been observed that co-developers may be reluctant to join if the project leader is untested.
In this view it is the leader and the action of the leader which attracts co-developers. The leader communicates the vision of the project to potential co-developers, and by defining interesting modules and tasks the leader attracts co-developers.
In many OSS development projects participants are separated by geography [22 ] and communication is based on the Web [23 ]. A particular feature of Web-based communication is interactivity. It can be difficult for the project leader to spread the message to potential co-developers. There are Web sites like www.sourceforge.com which have made a name for themselves by hosting OSS development projects. At sourceforge alone there are more than 3,000 projects. The sheer number of projects makes it difficult to communicate the merits of a project to potential co-developers.
Projects gain users and co-developers from those searching to solve a problem. Through the use of search engines, many may be directed to the Web site of the project. If the initial test of the program makes a plausible promise of solving the problem in a satisfactory manner, the project may gain a user or co-developer. The information of a project may also be communicated by word of mouth (which includes discussions in newsgroups) or by reviews in magazines or Web sites. The project leader has little influence on these discussions or reviews.
The project leader can increase the probability of people finding the project by submitting project descriptions to relevant search engines, or by hosting the project at a Web site which promotes itself as a host for OSS projects. A project then must wait for users and co-developers to find it.
Keep the Project Together
Keeping the project together is in essence an attempt to prevent the project from forking. When a project forks, it is split up in two or more fractions often trying to accomplish the same goal. The history of Unix shows many of these forks in projects resulting in competing projects. BSD Unix is essentially a fork in the original AT&T Unix project.
The license of open source projects makes it possible for the departing fraction to use the project code base; however, the name of the project belongs to the creator (often the project leader). Projects commonly fork when personalities clash, or co-developers have differing views on the direction of the project. Also technical problems and their solution have been the source of forking. Readers of Kerneltraffic [ 24 ]will notice that most issues of kerneltraffic have one or more disputes between co-developers.
Learner and Tirole point to two factors which help keeping the project from forking; 1) trust in the leadership, and 2) natural forces. The natural forces against forking are loss of economics of from the split and the creation of smaller projects and a stigma of existing conflicts.
Trust in the leader is one factor which prevents forking; reading issues of Kerneltraffic demonstrates that a project leader armed with good technical arguments can often settle a flamewar and get the particular area of the project back on track. I am not convinced that a technical discussion about different solutions to a problem has anything to do with good leadership.
It is quite possible that the emphasis on leadership should be abandoned, until the term and associated properties have been more carefully defined in the open source context. Until then Learner and Tiroles’ trust in leadership should be reformulated, as the trust in the project leaders’ ability to choose the correct solution to a problem and create an piece of software which is extensible. As Learner and Tirole note, the leader has to communicate the criteria or arguments supporting a choice. In the case of the Linux kernel development, the leader (Linus Torvalds) sometimes can be so critical that others feel it necessary to enter the discussion as mediators. An example, Alan Cox and Donald Becker (Linux developers) were discussing some of Donald's PCI work, and at one point, Linus Torvalds interrupted with some criticism:
"Don't make a monster. Make something that is simple, and expand on it as needed. I do not like the way you usually sit on the code until you are happy, and then release it in one big bunch without any input from others. I prefer the incremental approach." Linus Torvalds in Kerneltraffic. [25 ]
There is evidence in Kerneltraffic to suggest that project leaders do not show good leadership. The leaders choose the patches and argue why some patches get rejected. The co-developers must respect the choice of patch and the technical solution, which it implies. This respect stems from the project leader’s ability to demonstrate technical insight and make the right choices, which over time will be evident. The co-developers should rest assured that the project leader chooses the correct patch from the number of submitted patches. It seems that leadership in open source projects is something different from the intangible notion of good leadership associated with a respected executive in a private company.
Let's return to the natural forces against forking, which should be the loss of economics of scale from the split and the creation of smaller projects. This implies that software development exhibits increasing or at least constant returns to scale.
According to F.P. Brooks the contrary is closer to the truth. Software development projects exhibit de-creasing productivity to manpower. Brooks remarked:
"Adding manpower to a late software project only makes it later." [26 ]
A recent study [27 ] of the GNOME project demonstrated a correlation between the number of co-developers and lines of code (LOC) produced. The study also showed that some co-developers were several orders of magnitude more productive than others, which is also documented by Brooks. This leads to the conclusion that more co-developers are good, but does not confirm constant nor increasing returns to scale. Another conclusion would be that the right (read: productive) co-developers are much more productive, and the task of managing a small number of autonomous proficient co-developers must be easier than a herd of "we try to contribute" co-developers. However, beggars can’t be choosers, and every project and workplace has it share of each.
Conclusion
The difference between Learner and Tirole and my perspective is subtle and maybe difficult to convey, but it is important. Whereas Learner and Tirole suggest that the leader of a project is the driving force in providing a vision, this paper argues that the primary provider of vision is the working example of a program. A co-developer can examine and use source code and become inspired to develop a new vision. This vision may result in the co-developer adding features to the program or modifying the program to work in a different context.
It has been shown that the leader, by delivering the initial code, provides an initial vision to which users will react. Users often will develop their own vision based on their needs and personal view on the program. When users become interested in the project and begin to partake by reporting bugs and asking for new features and patches, the user becomes a co-developer. The vision of the co-developer is important and will have direct bearing on the patches submitted by that very co-developer. The leader, however, has little impact on the co-developers vision. It is the code that provides the vision.
It seems fair to abandon the use of the term "leader" in open source development projects and instead use "maintainer" to describe the key person in a given project. "Maintainer" is used in the open source community to refer to that very person. The term "hacker" has suffered a similar fate by having two distinct different meanings in the open source community and the public. A "hacker" in the open source community is a highly regarded person whose skills in the realm of computing are undisputed. The public (and the press) believe that at hacker is person whose intentions are unlawful, but skillful. Let us not make this mistake again by using the term "leader" instead of the better and more meaningful term "maintainer".
This paper has shown that it is difficult to use the terms leader and leadership in relation to open source software development projects. The properties associated with good leadership are difficult to apply and find in open source software development projects.
I feel that a "maintainer" in the first phase of an OSS development project resembles the beggar, who begs for contributions but has to show his tricks to get the attention of people passing by. If the tricks are good, people stop and some are willing to contribute. If the tricks are really good, he may choose his audience, depending on size of their contributions. The beggar has then become the chooser.
Further Research
It seems that leadership in open source software development deserves further research. Leadership may very well exist in some form in open source development projects but may be disguised in different qualities. A person, who is perceived as a good project maintainer (leader) is likely to display different qualities than a leader in the corporate world. A study applying leadership theory in an open source context would indeed be revealing to the applicability of leadership in this special non-profit context.
I find it interesting that some OSS programmes reach a
mature state where only maintenance is performed. The general notion from
commercial software is that software never reach a mature state but continues
evolution with an endless stream of new and "improved" versions. An empirical
study would be needed to establish if this is a common trend and what type
of software that carries this trend. Also some theoretical understanding
of open source software development might be gained from such a study.
About the Author
Kasper Edwards is a Ph.D. student at Department of Technology
and Social Sciences at the Technical University of Denmark. The title of
his project is "Technological Innovation in Software Industry" which is focusing
on the Open Source Software development process. Kasper Edwards has a background
as a M.Sc. (ENG) and has worked for several years as an independent computer
consultant. He is an experienced user and administrator of both Linux and
the different flavours of Win9x and NT/2000. As a hobby he maintains a PC
gaming network in a youth club powered by Linux servers. As part of the project
and hobby Kasper Edwards is engaged in the SSLUG (Skåne Sjælland Linux User
Group, a 5000+ member user group) and participates in both technical and
political discussions.
E-mail: ke@its.dtu.dk
Acknowledgments
I would like to thank Prof. Jørgen Lindgaard Pedersen of the Technical University of Denmark for helpful comments and suggestions on earlier drafts of this paper. I assume full responsibility for any remaining vulnerabilities.
Notes
1. Josh Learner and Jean Tirole, 2000. "The Simple Economics of Open Source", Working Paper 7600. Cambridge, Mass.: National Bureau of Economic Research, and http://papers.nber.org/papers/w7600
4. Eric S. Raymond, 1999. "Homesteading the Noosphere", In: The Cathedral and The Bazaar. Sebastopol, Calif.: O�Reilly and Associates.
5. "The Linux Study", at http://www.psychologie.uni-kiel.de/linux-study/index.html
6. Eric S. Raymond, 1999. "The Cathedral and Bazaar", In: The Cathedral and The Bazaar. Sebastopol, Calif.: O�Reilly and Associates.
9. Linus Torvalds is the original author of the Linux kernel, and still the central person in Linux development.
10. Frank Damgaard, 1999. "Linux History � 1", accessed 16 May 2000, at http://www.sslug.dk/artikler/linux_history_1.html
11. Nikolai Bezroukov, "Hijacking of Minux community and the beginning of Linux development (1991-1992)", accessed 25 May 2000, at http://www.softpanorama.org/People/Torvalds/Linus_Torvalds_biography.shtml
12. A patch is a fix to a program, a piece of code that is to replace some code that is faulty.
13. Linus Torvalds, 1999. "The Linux Edge", In: Chris DiBona, Sam Ockman & Mark Stone (editors). Open Sources: Voices from the Open Source Revolution. Sebastopol, Calif.: O�Reilly.
14. The development of Fetchmail is extensively described in the paper "The Cathedral and the Bazaar" by Eric S. Raymond, see http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar.html
15. There is a tradition in the Linux community to define users and co-developers as the same. In this paper users are just that � users. Co-developers are users that cross the line and begin to take interest and responsibility for the program they are using by providing some sort of feedback to the project-leader.
16. Frank Damgaard, 1999. "Linux History � 1", accessed 16 May 2000, at http://www.sslug.dk/artikler/linux_history_1.html
17. Learner and Tirole, p. 21.
18. API, Application Programming Interface � A set of functions that allow use of festures in a program. An exaple: The Win32 API is the set of functions a programmer must apply when creating applications for the Windows family operating systems.
19. Brian Behlendorf, 1999. "Open Source as a Business Strategy", In: Chris DiBona, Sam Ockman & Mark Stone (editors). Open Sources: Voices from the Open Source Revolution. Sebastopol, Calif.: O�Reilly.
20. GNOME is the GNU Network Object Model Environment. The GNOME project intends to build a complete, easy-to-use desktop environment for the user, and a powerful application framework for the software developer. See http://www.gnome.org
21. Federico M. Quintero, Miguel de Icaza, and Morten Welinder, 1999. "GNOME Programming Guidelines", accessed 26 April 2000, at http://developer.gnome.org/doc/guides/programming-guidelines/book1.html
22. The Linux study reviled that the 141 developers asked were scattered over more that 11 nations; accessed 14 June 2000, at http://www.psychologie.uni-kiel.de/linux-study/nations.gif
23. These are e-mail, Web pages, newsgroups, chat, and others.
24. The Web site of kernel traffic can be found at http://kt.linuxcare.com/kernel-traffic/
25. http://kt.linuxcare.com/kernel-traffic/kt19991101_41.epl#6
26. F.P. Brooks, 1995. The Mythical Man-Month. Reading, Mass.: Addison Wesley Longman, pp. 21-26.
27. S. Koch and G. Schnieder, G. 2000. "Results from Software Engineering Research into open Source Development Projects Using Public Data", Diskussionspapiere zum Tätigkeitsfeld Informationsverarbeitung und Informationswirtschaft, Hans R. Hansen und Wolfgang H. Janko (Hrsg.), Nr. 22, Wirtschaftsuniversität Wien.
Editorial history
Paper received 26 July 2000; accepted 27 September 2000.
Copyright © 2000, First Monday
When Beggars Become Choosers by Kasper Edwards
First Monday, volume 5, number 10 (October 2000),
URL: http://firstmonday.org/issues/issue5_10/edwards/index.html