We aOpen-source projects are often little more than complete failures. Of course, that is not really very fair. Many open-source projects are started by individuals who have had good intentions, got to a certain stage in the development of their software, and for some reason stopped development. It does not make them bad developers; it just often renders their code practically worthless. Half-finished code is often just not worth using.
It seems like the best open-source work is done when there is strong leadership, either by an individual or a group. Take, for example, what is probably the biggest open-source project in the world, Linux. How many people have contributed to the Linux operating system? Hundreds? Thousands? But can anyone just add something to the Linux operating system and get that distributed to all Linux users? Of course not. The originator of Linux, Linus Torvalds, oversees every change to the core of Linux, the kernel. And you can bet that there are people at Redhat, Mandrake, Debian, etc. that watch over what makes it into their own distributions of Linux. Or take the ever-more-successful Mono project. It is supported to a certain degree by Novell and its originator and director is Miguel de Icaza. The success of Mono is in large part due to the strong leadership of de Icaza. Are there exceptions, where open-source projects are successful without serious oversight? Sure. But are they more likely to be of varying quality? Are they more likely to stop evolving? You bet they are.
The principle here is obvious (though I will state it anyway). We need leadership and organization in our important collaborative projects. We need what every good lexicon or dictionary has, an editor(s). Can a project succeed without leadership? Yes. Will it? That is not as likely.
Leadership is needed not only to contribute to the project, but to lay down rules for the project and for conflict resolution when it occurs. It is possible for contributors to look at the same data and use the same tools and still gather data that is inconsistent because they might have differing views on what they are trying to accomplish with the project. In such cases leadership could step in to resolve this so as to keep everyone on the right track.
In some cases conflict resolution will be necessary. With some types of projects conflicts are actually valuable. A collaborative effort in textual criticism, for example, would surely lead to disagreements on how certain pieces of data is to be interpreted. In such cases “conflict” can be a good thing. It is healthy in some disciplines to have conflict because it shows the areas where more research and debate is needed. But this is not often the case. A project that revolves around, for example, morphological tagging of the Septuagint will 99% of the time need to not have conflict, because there will rarely be any real question about how a word is to be tagged. In such cases the project needs to have leadership that will resolve any potential disagreements.