MMM vs. OSS

I have to say that I'm still not convinced that there is such a thing as Open Source project management. (OS) projects are as diverse as anything, and there can't be any specific approach to manage them all.
ESR is certainly right in some (rather trivial) points such as peer review and even parallel debugging. But that has nothing to do with project management. The special management approach has to vary widely, dependent of the nature of the project. How much architecture/design is involved, how well known is the problem domain, etc. Brooks' Mythical Man Month has certainly to be read in its historical context, but I can't find much value in the oh-so-popular Cathedral and Bazaar.

For example, according to Brooks, opening development up wide should result in basically an infinite time-to-completion for a project, since all effort gets sucked up in inter-developer training and communication.

I think this one is easily explained by the different organizational structures. When a commercial development team hires someone, there's an expectation on both sides now that they're "inside the wall" that someone must be supported and involved and given work to do. Else, why did you hire them? The lower chemical potential of open development means those doing the work are more-or-less free to ignore the training of new contributors, who must learn on their own. With no schedule, or a recognizance of the value of an educational budget, this is no problem.

Microsoft chimes in to remark that the reason OSS has worked is that anarchy is OK at producing copies of systems which are already fully architected. The "taillights are easy to follow" principle.

The advantage of "chasing taillights" is you don't have to do much work to achieve a shared vision among the contributors. It's that vision that is hardest to pass on. I understand taking advantage of this is one of the reasons behind GNOME's emulation of Microsoft products. But the effect applies just as well to designs just over the horizon. How often have you read a new project description and said "Yes, I see what they want to do"?

Others have remonstrated that OSS projects aren't really bazaars, but autocratic cathedrals run by the elect, and so are perfectly understandable.

It is true that one effective model is to have circles of contributors, where new contributors are "trained" by a circle of more experienced developers, who in turn defer to core members. But the term "autocratic cathedral" poorly captures the complexity of the situation. This model is only autocratic in that--for reasons of resource efficiency, lack of distinct vision and respect for their technical competence--everyone follows the decisions made by the core members. And one is free to move between these roles as time and interest permit. In other words, not autocratic at all.

Perhaps (to further mix metaphors) this is a surgical team, drawing their new members from recent graduates of a custom-tailored university degree program, crossed with the social freedom one has in starting/joining a minor shared-interest club in a large city. I don't think there's much interest to be found in calling that "traditional top-down design" and understood.

On a more philosophical note, stephan's point about historical context is a valuable one, and applies just as well to the The Cathedral and the Bazaar. We shouldn't expect to find directly applicable rules in seminal works of this sort. Initial theories often have limited scope or are found to be wrong on some (even many) details. But the central idea still has value, and is either incorporated in later theories, or develops into a sophisticated field in its own right, sharing only the name and central premise of the original. (Darwin is a good example here.) We should keep this in mind and not be surprised when bold claims don't apply to our situation.

As a great friend used to say, "I think we can complicate this a bit." :-)

I don't find anything in the Cathedral and Bazaar justifying the term theory. It's all either common sense or just plain wrong. To formulate it a bit more moderately, the whole OSS culture is certainly a very new and exciting (even for an observer) environment, which couldn't be addressed by Brooks. There definitely is a lot of stuff to be researched. But this is less obvious than ESR seems to suggest, and the effect is IMO not so much on the management level, but more of a philosophical nature (the nature of work, it's distinction from job, and general politico-economic issues, as touched by this excellent article by Eben Moglen (who plays, by the way, an importent role in the FSF).

I've always found The Mythical Man Month to be accurate. Most of the time an OSS (in the ESR sense) project doesn't fall in line, it is a misjugement of conditions.

Take the example of wide development. rillian points out the difference in structure between a software team and the world of developers. In a normal software team, the people joining have to be trained. The experienced folk have to find time to help them, train them, make them understand the objective, and then provide them with work to do. This is what slows the project down. The actual code contributed by the new members (at a later date) is the start of the help they promise.

In an OSS project, there is none of this. The new member is not on the radar screen until they have a quality bit of code to contribute. By then, they have learned the project, bought into the design goal, and are fully up to speed. If they weren't, the code they emailed wouldn't be worth consideration. So all of that ramp-up time is gone. The current project workers spend about 10 minutes evaluating the code, 5 more mailing a "thanks", and then get back to their own tasks.

Debugging is parallelizable. Bug fixing is not. In a software team, the new folks and the old folks all find bugs, and then patch the tree. It's no surprise that they sometimes trample each other. In an OSS project, when J. Random Hacker sends a bugfix patch, JRH cannot patch it directly. That bugfix hits a normal project maintainer, who surely has the knowledge to integrate it fully. This provides less conflict. In addition, there is no requirement that JRH's patch be included. The maintainers might like that bug (calling it a feature) or may completely reimplement the fix to fit better. In a software team environment, there are egos to watch here.

The "chasing taillights" bit is simple FUD. A lot of OSS/Free Software is definitely based on existing software. But a lot of new ideas are happening. Other Unices wouldn't be looking to OSS/Free Software for some of these developments if they were simply a reimplementation of the wheel. And since Micro$quash is well known for its innovation, I suspect we should take such comments with a grain (or hillside) of salt.

Brooks assumes that duplication of effort must be avoided. This assumption is not valid for OSS.

The culture and ideas that are now called OSS are not new, and are just as old, if not older, than the MMM. The hacker culture (as documented in Levy's "Hackers") originated as almost a direct response to IBM's cathedral style of development, where access to the machine was limited to just the select few. It was not mainstream, but free software was being successfully developed "way back" in the 70's and 80's.

The real innovation of the last 10 or so years is the use distributed development teams. OSS povides highly visible examples of successful (and not-so successful) distributed development, but I'm sure there are just as many, if not more, behind the closed doors of corporate development.

Of course, the very idea of distributed development is almost in direct opposition to the MMM. The increased overhead of communication is supposed outweigh the benefits of added developers, and the farther away the developers, the greater the overhead. It would be interesting to see some useful research into this, producing, perhaps, a metaphor a little more useful than Cathedrals & Bazaars.

I discussed exactly this issue with Eric before CatB was officially released. In fact, this very observation was what led Eric to write the paper in the first place.

As I recall, we decided that OSS was able to avoid the N-squared communication penalty for two main reasons: 1) debugging is parallelizable, and debugging is the main task of most of the co-developers on an OSS project, and 2) the vast majority of any necessary communication happen through the source code or other, related, means (patches, CVS comments, etc.).

In fact, my comment that the debugging task can be effectively parallelized to as many people as desired stems from consideration of Brooks' law, since I was having my own troubles seeing how Linus had avoided the communication penalty. Co-developers in an OSS project are guaranteed to be motivated enough to bootstrap themselves into the code, whether it is to add new functionality or to fix existing functionality that is not working correctly. Anyone who would require other members of the team to spend communication effort on them are automatically weeded out.

Debugging is a special case, since the amount of information needed to fix any given bug is probably less than that needed to comprehend and extend the entire system (assuming that all the most serious bugs, those which are functions of large scale interactions, were weeded out by the core developers already). The real tallent required in debugging, according to Eric, is more closely related to a specific understanding of, or insight into, the kind of bug being manifested, than to a deep or broad understanding of the code-base itself.

I should even be able to dig out the specific correspondence between Eric and me on this topic, if I can find the archival CD's from three or four years ago, but I think that the above covers the gist pretty well.

The real tallent required in debugging, according to Eric, is more closely related to a specific understanding of, or insight into, the kind of bug being manifested, than to a deep or broad understanding of the code-base itself

I can't really agree here, as this expresses a false distinction between the problem (what the code addresses) and the attempted solution (how the code adresses it). There are possibly classes of bugs that can be spotted purely by inspecting the code, i.e. by reading individual language specific statements. However, the more interesting bugs are design related, such as breaking invariants (DbC) or making a wrong commonality/variability analysis. To solve those, you do need quite a bit of understanding of the problem domain, and quite a bit of insight into the attempted solution provided by the given code.

Also, there is the broader picture. An interesting metaphor, which possibly lead to the analogy with a Cathedral, came from the observation that even though huge aristocratic buildings took multiple lifetimes to build, they often were consistent in style. This was possible because the architects were few, and they had the important ability to capture the spirit, goal, approach, style, whatever, and continue in the same direction. This requires a lot of communication and documentation, so the fewer architects are involved, the better.

Of course, the issue is not to prevent others from designing their own ideas into a given project. In fact, friction between designers leads to project forks. The importent difference to closed source projects is that OSS projects provide the ability to fork, which is good, as it empowers people. Eric seems to vehemently refuse that forks are part of the OSS culture.

Folks might want to grab a copy of the versions of my talk on this very subject from ftp.linux.org.uk:/pub/linux/alan. I am generally of the opinion that what we do doesn't really invalidate the basic ideas of MMM at all, and where there are apparently differences (eg adding people to late projects) you can see why there is such a difference.

Alan

I did an article for IBM's developerWorks Open Source Zone on Brooks' Turing Prize in which I interviewed

• Brian Behlendorf
• Nikolai Bezroukov
• Fred Brooks
• Ken Coar
• Marc Ewing
• Eric Raymond
• Richard Stallman
• Erik Troan
• Bob Young
• Jamie Zawinski