Ken's Musings about the Stately Dance of Apache Development

Last updated: Monday, 28 March 2005 14:08 -0500

The Apache Web server has been around for several years now. Just whose purposes is its development serving now?

Paradigm: Shift Happens

In the November 1997-January 1998 timeframe, two significant changes happened in the way development of the Apache Web server occurred. The first was the move from a 'review-then-commit' (RTC) model to a 'commit-then-review' (CTR) one; the second was to move of the project status into the repository.

Quick or Good?

Prior to the change from RTC to CTR, any alteration to the source code needed to be proposed to the development mailing list, and garner at least three positive "looks good to me" votes from qualified developers, before it could be committed and made part of the server. The change to CTR meant that changes could be made by anyone with access, at any time. Big or controversial changes still needed to go through the review-first process, however.

This change allowed highly-motivated developers to operate in a sort of 'rapid prototype' mode, so changes that had been languishing for lack of sufficient interest were able to be committed and the coders could move on.

Of course, the downside was that changes got committed with less peer review, and might either be broken or have side-effects on other developers' work or other parts of the server.

Double-Clique

As for the commitment of the project status record to the repository itself.. well, that too had advantages and disadvantanges. Previously the status was maintained by a volunteer (usually Jim Jagielski), who collated the list of outstanding change proposals, who had voted for what, and open problems or issues, and mailed it to the list at semi-regular intervals. Once the file was in CVS, the mailing could be (and is) done automatically at regular intervals, and developers could express their opinions directly by recording their votes in the status file.

Negative Synergy

One of the downsides I personally perceived as a result of these changes was that the developers on the mailing list narrowed their focus. They could commit whatever they were working on, as long as no-one else didn't object retroactively, and so their work didn't get proposed or even make it into the status file -- it went straight into the code. In addition, with the freedom to update both the source and the status at will, changes proposed by from newcomers sometimes didn't get recorded in the status file, and were occasionally ignored altogether, because the developers were paying more attention to scratching their own itches than to reviewing other people's work.

Fortunately, the situation didn't get as bad as it could have, and several of the developers now responsibly record and respond to proposals from people new to the mailing list.

Community Evolution

A third facet of change that can be seen on the Apache jewel is the composition of the developer community. Over time, it seems to have shifted somewhat from exclusively hackers and bit-twiddlers who ran Web sites to people with formal software engineering background who are employed by companies that use or redistribute software based on the Apache package. One of the side-effects of this, I think, is an increased awareness of, and attention paid to, Apache's market share. It used to be cool, but now many people consider it important as well.

Does all this mean that the forces driving the development of the Apache Web server have changed over time? I think so. Are the directions in which development is now heading right for the software's users? What do you think?


coar