IMO

One key distinguishing feature of the ASF is that it places community before code. It is important that the community be heathly and active, since the logical result of that is a codebase which is active and healthy, and can continue far longer than any single developer's interest level. One way which we handle this is by avoiding the whole concept of "main" developer or "key" developer or anything else which places one developer above his/her peers. It's a concept which we've used since before there even *was* an ASF, and it's one that works for us. This works well since, for the most part, what the ASF does is create code which implements a known protocol or standard; there is an existing "framework" which the code then casts into being. I think there is one particular codebase class where this method isn't the best solution, and that is in the creation of new open source languages. IMO, for a language to be successful and useful, it should be internally and externally logically consistent. Naming constructs for example, should be easy to guess. This is easy when there is a very small subset of people (one or two) who define the language (after all, standardization usually happens after a language is widely used). And by restricting the decision-makers, it logically follows that the linguistic feel is constant and consistent. An example is PHP, which is a language I love and one which is on my short list of prefered languages. But even so, you have to admit the there is little logical consistency in how functions are named, argument ordering, etc. Compare this with a language that has a more controlling singular force, like Ruby or Python, and you can see that, in some cases, some open source projects do better with a benevolent dictator. Of course, there are exceptions, and this doesn't imply that languages-by-committee are any less capable than languages-by-a-few. But it is interesting nonetheless.