The Apache HTTP Server Project is a collaborative software development effort aimed at creating a robust, commercial-grade, feature-rich, freely available source code implementation of an HTTP (Web) server. The project is jointly managed by a group of volunteers located around the world, using the Internet and the Web to communicate, plan and develop the server and its related documentation. This project is part of the Apache Software Foundation. In addition, hundreds of users have contributed ideas, code and documentation to the project. This file is intended to briefly describe the history of the Apache HTTP server and recognize the many contributors.
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 at the University of Illinois, Urbana-Champaign. However, development of that httpd had stalled after Rob left NCSA in mid-1994, and many webmasters had developed their own extensions and bug fixes that needed a common distribution. A small group of these webmasters, contacted via private email, met for the purpose of coordinating their changes (in the form of “patches”). Brian Behlendorf and Cliff Skolnick put together a mailing list, shared information space, and logins for lead developers on a machine in California’s Bay Area, with bandwidth donated by HotWired. In late February, eight major contributors formed the basis of the original Apache Group:
- Brian Behlendorf
- Roy T. Fielding
- Rob Hartill
- David Robinson
- Cliff Skolnick
- Randy Terbush
- Robert S. Thau
- Andrew Wilson
with additional contributions from
- Eric Hagberg
- Frank Peters
- Nicolas Pioch
Using NCSA httpd 1.3 as a base, we added all the published bug fixes and valuable improvements we could find, tested the result on our own servers, and made the first official public release (0.6.2) of the Apache server in April 1995. By coincidence, NCSA restarted its own development during the same period, and Brandon Long and Beth Frank of NCSA’s Server Development Team joined the list in March as honorary members so the two projects could share ideas and fixes.
The first Apache server was a huge success, but we all knew that the codebase needed a major overhaul and redesign. During May-June 1995, while Rob Hartill and the rest of the group focused on implementing new features for 0.7.x (such as pre-forked child processes) and supporting the growing Apache user community, Robert Thau designed a new server architecture (codenamed Shambhala) that included a modular structure and API for better extensibility. Group-based memory allocation and an adaptive prebifurcation process model. The group switched to this new server base in July and added the 0.7.x features, resulting in Apache 0.8.8 (and its siblings) in August.
After extensive beta testing, many ports to obscure platforms, a new set of documentation (by David Robinson) and the addition of many features in the form of our standard modules, Apache 1.0 was released on December 1, 1995.
Less than a year after the group was formed, the Apache server moved to NCSA’s httpd as the #1 server on the Internet and, according to the Netcraft survey, retains that position today.
In 1999, members of the Apache Group formed the Apache Software Foundation to provide organizational, legal, and financial support for the Apache HTTP Server. The foundation has placed the software on a solid foundation for future development, and greatly expanded the number of open source software projects, which fall under the umbrella of this Foundation.
If you only want to submit an occasional suggestion/correction, you can simply use the bug report form in < http://httpd.apache.org/bug_report.html >. You can also subscribe to the announcement mailing list (announce@httpd.apache.org) that we use to spread information about new releases, bug fixes, and upcoming events. There is a lot of information about the development process (much of it in dire need of updating) that is in < http://httpd.apache.org/dev/ >.
NOTE: The developer mailing list is NOT a user support forum; it is for people who are actively working on server code development. There is also a ‘docs’ subproject for those who are actively developing and translating documentation. If you have user/configuration questions, subscribe to the Users list or try the USENET newsgroups “news:comp.infosystems.www.servers.unix” or “news:comp.infosystems.www.servers.ms-windows” (as appropriate for the platform you use).
There is a core group of contributors, initially formed by the founders of the project, and augmented from time to time by other prominent contributors. There are ‘committers’, who are granted access to source control repositories to help maintain the project or documents, and the core group that now manages the project, which is called the Apache HTTP Project Management Committee (PMC, for short). In fact, each Apache Software Foundation project has its own PMC, to determine committers, project direction, and overall management. The terms “The Apache Group” or “Apache Core” are no longer used.
The project is a meritocracy: the more work you’ve done, the more you’ll be allowed to do. The original rules are set by the group’s founders, but they can be changed by a vote of active PMC members. There is a group of people who have logins to our server and access to the source code repositories. Everyone has read-only access to the repositories. Code changes are proposed on the mailing list and are usually voted on by active members: three +1 votes (‘yes’ votes) and no -1 votes (‘no’ votes or vetoes) are needed to confirm a code change during a release cycle; Documents are usually committed first and then changed as needed, with conflicts resolved by majority vote.
Our main method of communication is our mailing list. Approximately 40 messages a day flow over the list, and they usually have a very conversational tone. We discuss new features to add, bug fixes, user issues, developments in the web server community, release dates, etc. The actual development of the code takes place on the developers’ local machines, with the proposed changes communicated by a patch (output of a unified command “diff -u oldfile newfile”), and then applied to the source control repositories by one of the committers. Anyone on the mailing list can vote on a particular issue, but only those made by active members or people known to be experts in that part of the server count toward the requirements for engagement. Vetoes must be accompanied by a convincing technical justification.
New members of the Apache HTTP Project Management Committee are added when a frequent contributor is nominated by a member and unanimously approved by voting members. In most cases, this “new” member has been actively contributing to the group’s work for more than six months, so it’s usually an easy decision.
The project guidelines continually evolve under the supervision of the PMC, as the group’s membership changes and our development/coordination tools improve.
Apache Software exists to provide robust, commercial-grade reference implementations of many types of software. It must remain a platform upon which people and institutions can build reliable systems, both for experimental and critical purposes. We believe that online publishing tools should be in everyone’s hands, and that software companies should make money by providing value-added services, such as specialized modules and support, among other things. We realize that it is often seen as an economic advantage for a company to “own” a market; In the software industry, that means strictly controlling a particular conduit in such a way that everyone else must pay for its use. This is typically done by “owning” the protocols through which companies conduct business, at the expense of all those other companies. As long as the protocols of the World Wide Web remain “non-owned” by a single company, the Web will remain a level playing field for businesses large and small. Therefore, the “ownership” of protocols should be avoided. To this end, the existence of robust reference implementations of various protocols and application programming interfaces, freely available to all businesses and individuals, is a tremendously good thing.
In addition, the Apache Software Foundation is an organic entity; those who benefit from this software by using it, often contribute to it by providing feature improvements, bug fixes, and support for others on public lists and newsgroups. The effort made by any particular individual is usually quite light, but the resulting product becomes very strong. These kinds of communities can only happen with software available for free: when someone has paid for the software, they are usually unwilling to correct their mistakes for free. One can argue, then, that Apache’s strength comes from the fact that it is free, and if it were made “non-free” it would suffer tremendously, even if that money were spent on an actual development team.
We want to see
Apache software used very widely – by large companies, small businesses, research institutions, schools, individuals, in the intranet environment, everywhere – although this may mean that companies that could afford commercial software, and would pay for it without batting an eyelid, could get a “free ride” by using Apache. We are even happy when some commercial software companies completely abandon their own HTTP server development plans and use Apache as a base, with proper attributions as described in the LICENSE. That is, the Apache HTTP Sever only comes from the Apache Software Foundation, but many vendors ship their own product “based on the Apache {Project}”. There is no Apache {Product} “{Vendor}”, this is an abuse of the Apache Software Foundation marks.
