• DOI:10.1145/299157.299167
• Corpus ID: 1272174

Shared leadership in the Apache project

@article{Fielding1999SharedLI,
  title={Shared leadership in the Apache project},
  author={Roy T. Fielding},
  journal={Commun. ACM},
  year={1999},
  volume={42},
  pages={42-43}
}

• R. Fielding
• Published 1 April 1999
• Computer Science
• Commun. ACM

documentation. In addition, hundreds of users have contributed ideas, code, and documentation to the project. According to the Netcraft survey of November 1998 [4], the Apache server and its derivatives are used by over 57% of publicly accessible Web sites, more than double its nearest competitor. Unlike most open-source projects, Apache has not been organized around a single person or primary contributor. When the project began in February 1995, the most popular server software on the Web was the public domain HTTP daemon developed by Rob McCool at the National Center for Supercomputing Applications (NCSA). However, development of NCSA httpd had stalled after Rob McCool left, and many Web masters had developed their own extensions and bug fixes that were in need of a common distribution. A small group of these Web masters gathered together via private email for the purpose of coordinating their changes (in the form of “patches”). Brian Behlendorf volunteered the use of his server as a shared information space, providing logins for the eight core developers and hosting a public mailing list for communication. That left two problems to be solved before the development could proceed: decision making and coordination. Apache has always been a multinational project, with core developers located in the U.S., Britain, Canada, Germany, and Italy. Collaboration within the group is hindered by variation in work schedules and the effect of cross-Atlantic network latency. Each Apache Group volunteer has (at least) one other “real” job, usually related to either Web services or protocol research. We collaborate on producing and supporting the Apache server out of enlightened self-interest: by pooling our efforts, the resulting product is much more functional and robust than anything we could have produced alone. However, this also means that none of us can devote large blocks of time to the project. In order for the project to succeed, our development process (the procedures by which we make decisions and coordinate our efforts) had to reflect this globally distributed and volunteer organizational environment. There was no Apache CEO, president, or manager to turn to for making decisions. Instead, we needed to determine group consensus, without using synchronous communication, and in a way that would interfere as little as possible with the project progress. What we devised was a system of voting via email that was based on minimal quorum consensus. Each independent developer could vote on any issue facing the project by sendT he Apache Project [1] is a collaborative software development effort aimed at