Eric Raymond Replies to Chuck Connell
By Eric S. Raymond
Chuck Connell aims some mighty rhetorical blows at a set of propositions that he believes are premises or consequences of the open-source development model. Mr. Connell's analysis has grave flaws. He confuses my observations about the structure of the open-source community in the large with claims about the organization of individual projects in the small. This confusion leads him up several garden paths and down a number of blind alleys.
In his article Open Source Projects Manage Themselves? Dream On, Chuck Connell aims some mighty rhetorical blows at a set of propositions that he believes are premises or consequences of the open-source development model. He specifically quotes, and attempts to refute, my work in The Cathedral and the Bazaar and subsequent papers.
Unfortunately, Mr. Connell's analysis has grave flaws. He confuses my observations about the structure of the open-source community in the large with claims about the organization of individual projects in the small. This confusion leads him up several garden paths and down a number of blind alleys.
The confusion begins immediately with Mr. Connell's title, "Open Source Projects Manage Themselves? Dream on." Of course they don't, and nobody who has ever participated in one would dream of claiming that they do. Live projects have leader/managers. In fact, most live projects have a single leader who is the final arbiter of the design. The centrality of this "benevolent dictator" role is widely understood in the community. It is so important that the community has evolved an elaborate set of customs to legitimize and regulate it; customs I have described in Homesteading the Noosphere.
Mr. Connell writes as if self-organization and strong central control in individual projects are incompatible, but he is crucially wrong in this. Individual projects self-organize because the participants choose to be there -- they select themselves, and they choose to follow the project's benevolent dictator (or else they leave).
Above the individual project level, the community is also self-organizing. While there are projects with great prestige (such as the Linux kernel, or Perl, or Apache) which convey on their leaders wide influence, there is no manager or management hierarchy that plans for the open-source community as a whole. Instead, coordination between projects happens through a horizontal trust network of relationships between individuals – a network which genuinely does look like Mr. Connell's "bazaar" diagram (his Figure #3).
Befuddled by his belief that I think leadership is unnecessary, Mr. Connell then proceeds to misread my critique of conventional management techniques. It's true that I have described some of the traditional management tasks as almost irrelevant in the Internet-centric open-source environment -- notably resource marshalling, especially in its turf-war aspect. But elsewhere I refer explicitly to goal-setting and project definition as the concerns of "project leaders and tribal elders". It is not leadership that the open-source community has rejected -- it is conventional management hierarchies and the pointy-haired boss.
In our world, the five functions of management that I described in CatB can only be exercised by a project lead who has credibility as a programmer and system architect. The only people who can speak for and lead the community as a whole are those who have demonstrated special competence and been elected by their peers to do so, and even they have no power to compel and must evolve a management style not dependent on being able to give orders.
Mr. Connell makes another basic error in attacking the open-source debugging process. He writes as though the most important and limiting factor in debugging is in choosing non-conflicting fixes once the problems are understood. This is wrong, as all open-source developers understand and my paper points out via a quote from Linus. In fact, the hard part is understanding the nature and etiology of each bug -- and this is precisely the part that parallelizes well. Once that hard part is done, reconciling fixes is pretty easy.
By the time Mr. Connell equates our bazaar with a cathedral, his misreadings of my work and mistakes in interpreting community practice have piled up so high that he is completely out of contact with the reality open-source programmers live in every day. Thus his later claims in the article (for example about the scalability of the model) are fatally ill-founded.
It is too bad that Mr. Connell didn't acquire a better understanding of open-source development before writing this critique, because he is articulate and not stupid. His observation that individual project organization resembles a Brooksian surgical team is independent of the serious mistakes elsewhere in the article and worth followup; by coincidence, I wrote the same thing in the (not yet published) revision of CatB I'm preparing for the book's second edition.
My advice to Mr. Connell is this: spend some time in the trenches. Join a project. Observe the process in action. This paper was badly wrongheaded -- but a year from now, you might have something important to contribute to the subject.
Biography: Eric S. Raymond is a full-time open source developer and the author of many papers about open source. He can be reached at www.catb.org/~esr/.
September 2000 -- Published by IBM/Lotus Developers Network.
January 2007 -- Rehosted on my own server, after IBM dropped older articles from their site.