In our industry the market dominant players often have the worst products, but that's pretty clearly not true for the Apache Foundation.
The core Apache servers power the web: combining dominant market share with dominant performance and stunning software reliability - and because that combination is unusual, we have to ask why and how?
A big part of the why is historical: Apache got its start with the first NCSA servers and so inherited an installed base, a solid code base, and, most importantly, the loyalty of many of those involved in building out the original server ideas.
Part of this is a matter of perception: Apache dominates only the middle market, not its fringes. If you want the easiest possible route to customer sign-off and don't care about the costs of ownership - then Apache is not the answer. Similarly if you really only care about a specific subset of secure transaction management, can dictate all other software used in the system, and face hardware limitations requiring that you focus on server cycles - then Apache/Tomcat is not the answer.
But a majority share of the long term how has to be put down, I think, to an effective governance model for the foundation and its community.
Here's how the Apache foundation describes the key to their organizational success:
MeritocracyUnlike other software development efforts done under an open source license, the Apache Web Server was not initiated by a single developer (for example, like the Linux Kernel, or the Perl/ Python languages), but started as a diverse group of people that shared common interests and got to know each other by exchanging information, fixes and suggestions.
As the group started to develop their own version of the software, moving away from the NCSA version, more people were attracted and started to help out, first by sending little patches, or suggestions, or replying to email on the mail list, later by more important contributions.
When the group felt that the person had "earned" the merit to be part of the development community, they granted direct access to the code repository, thus increasing the group and increasing the ability of the group to develop the program, and to maintain and develop it more effectively.
We call this basic principle "meritocracy": literally, govern of merit.
What is interesting to note is that the process scaled very well without creating friction, because unlike in other situations where power is a scarce and conservative resource, in the apache group newcomers were seen as volunteers that wanted to help, rather than people that wanted to steal a position.
Being no conservative resource at stake (money, energy, time), the group was happy to have new people coming in and help, they were only filtering the people that they believed committed enough for the task and matched the human attitudes required to work well with others, especially in disagreement.
After explaining the structure of the ASF, we will see how the meritocracy relates to the various roles.
Notice that what distinguishes the Apache foundation from thousands of other organizations isn't the idea that people should become what they can do, but their consistent execution on this idea - basically most organizations talk about devolving authority to the leading edge, but then weight the actual execution the other way to gradually centralize control. Apache, like the U.S. Military (and any well run Unix shop) weights its execution the other way: to actually put people on the cutting edge in charge.
And that, I think, is the bottom line message from Apache's success: you may need a centralized organization for supply, co-ordination, and legal cover but in general organizations are more successful if tactical decision making is entrusted to those doing the actual work -leaving those nominally in charge at the organization's co-ordination and resource center to facilitate rather than get in the way.