Introduction to the Apache Software Foundation
Avik Sengupta
In the beginning was the NCSA HTTPd . NCSA, of course, is the National Center for Supercomputing Applications at the University of Illinois at Urbana – Champaign , the same people who gave us the Mosaic web browser.
Rob McCool at the NCSA was largely responsible, and he had this to say:
I first got involved because Marc wanted to have a small, simple server that people could use with Mosaic. He felt the CERN server was too large and complex, and that something small and easy to understand would facilitate more widespread adoption.
Soon, as Rob left to get a real job, the project lost a lot of momentum. However, with the software deployed at many places, webmasters wanted continuing bugfixes and enhancements. Many started modifying the software themselves, and sharing their changes with others. Around early 1995, Brian Behlendorf started collecting patches to the last version of NCSA HTTPd. Soon, a group of eight people started exchanging patches on a mailing lists set up for that purpose. Thus was born the Apache Group, since, as legend has it, they were working on “a patchy server”.
Release 1 of the Apache httpd server happened on December 1, 1995. It was released at the cusp of the growth of the World Wide Web. Within a year, it was the most widely deployed web server in the world, surpassing its parent, the NCSA server.
The Apache Software Foundation was registered as a non-profit charity in June 1999. Foundation is composed of its members, who elect a Board of Directors every year to oversee the management.
The ASF provides infrastructure services to its projects, such as CVS source repository, mailing lists and web hosting services. It is also the entity that holds copyrights for all code that is produced at Apache.
All code released from Apache are under the ASL (Apache Software License). This is a BSD inspired license, that allows users the full freedom to create derivative works and license them as they wish, with the only proviso that an acknowledgement to the original code be maintained.
More important however, is the ..
The ASF is divided into projects. (some projects have subprojects, some even have sub sub projects, but we'll get there in a moment).
The community around a project consists of of its users and contributors. The success of a project within Apache is usually defined not just by the amount of code that a project can produce, but rather by the vibrancy of the community around it.
People contribute to a project in many ways. Some write new functionality, while some create bugfixes. Some write documentation, while others translate the documents to other languages. Many provide support on the mailing lists, answering queries and troubleshooting issues.
But probably the simplest, yet most important contributions are from the legions who test the software and report bugs. The quality of the released software owes much to these people. It is probably worth noting that the vibrancy of the community is directly proportional to the quality of software, since the larger the pool of people who test and report bugs for any open source software, the better the quality of the release.
Each project has a set of “committers”. Committers are people who have write access to the source code repository. They are therefore the people who are de-facto responsible for the technical direction of a project. A contributor to a project is elected a committer by the other committers once his skill and commitment to the project is apparent.
I think the communities around Apache projects are usually much more accessible compared to many other high profile open source project. Lets discuss some of the attributes that you'll see when you engage with us.
First, there is a very strong cultural bias towards meritocracy. Both implicity and explicitly, all Apache communities swear by meritocracy. And, as a community of geeks, merit is usually determined by the quality of the code you produce rather than the quantity of the talk that you create. Also important however is the contribution you make in building a community.
The other important feature is the openness. Most discussions happen in public mailing lists. So, for example, all architectural decisions happen on public mailing lists. Thats probably more important to be a real “open source” project than to chuck your source code on to a server for people to download.
So, if all that sounds inviting, and you want to participate, what do you do? First you figure out what interests you in all the projects at Apache. So lets discuss some of them briefly.
httpd is of course the first project at Apache, and in many ways the leader. Its deployed in over two thirds of all web sites today, and if anyone can claim to have played a vital role in the development of the internet, its the Apache “httpd” project.
Jakarta is a large umbrella project containing many Java based server side components. The biggest project under the Jakarta umbrella is the Tomcat servlet container, which serves as the official reference implementation of the servlet/jsp spec. Other projects include Struts, POI and many many others.
The Ant project would be familiar to any Java developer these days. Its the build tool of choice for almost any Java project these days. It started life as a Jakarta sub-project, and recently graduated to full project status.
The XML project includes the xerces xml parser and the xalan xls processor. Among its other project is FOP, the world's first xsl-fo processor.
Each of these Top Level Projects have their a Project Management Committe, which has legal oversight over the projects. However, its the committers of each project or subproject who are responsible the day to day affairs, including its technical direction.
[Talk about other projects time permitting]
So if some of the above interests you, and you wish to get involved, what do you do?
You start off by subscribing to the mailing lists for the projects. Most projects have a dev list for developers and an user list for users. Try to become familiar enough with the current code base to start understanding it. In most open source projects there is never enough architectural documentation, so this often involves asking "how does this work" type questions on the developer list.
At some point you see something you want added, or something that doesn't seem to work right. Discuss how you would implement that on the list. This serves two purposes: makes you familiar to the existing developers, and helps you in your understanding of the code.
You then implement you changes (and you have tested them, havent you?) and send them off to be incorporated in the official code base. The standard format of sending changes in most open source projects is CVS diffs ... so you need some familiarity with that. All projects have their own processes for sending diffs; some want you to mail them to the dev list, but most want you to attach it to the bug tracking system.
Rinse and repeat! At some point, when the existing developers are confident that you'll stick around and write good code, they will elect you as a committer.
Thank you, and hope to see you around!
Disclaimer:
All opinions expressed in this paper is purely my own, and is not endorsed by the Apache Software Foundation, its board or its officers.