Managing an open source project is like herding a pack of alpha male tomcats with their own agendas that you can't fire.
i.e., the Cathedral (vs. the bazaar) with a small group of people, like original, UNIX and Plan9 projects works better.
Small is beautiful, particularly in a development team, but the principles of throwing one away and "it is done when it is done" have to be considered. FWIW: In the HW world, Seymour Cray said that the best HW development team has about 10-12 people and no more. Maybe there is someone who knows about real-world complex systems that can still be understood by a small number of designers.
Of course, the problem today is that the systems are a few orders of magnitude more complex. There is no way a single human can comprehend every transistor in a modern processor, as Seymour did in the CDC and later Cray machines. The same is true for operating systems environments - although I think the >>kernel< can be, particularly if it's something more like Per Brinch Hansen's idea of a 'nucleus,' which I think you can argue is what Plan9 was and Unix V0-6 were pretty close to being.
@steve jenkin FWIW: It also depends on how you measure "success." Both the original and derivatives of Linux and OS/360 can be considered "success" if you look at how they are used and their impact, particularly in a commercial setting. But in many ways, neither had (nor has had) an impact as the core UNIX ideas have on the industry/CS community at large. There was really little that was "new" in either OS/360 or Linux. Both were based on keeping SW developed for older systems working and offering new attributes (like not being AT&T copyright) and, eventually (later) some new features.
Compare the fact that were not really novel with Plan9. While moving from an application from UNIX to Plan9 was possible, the designers decidedly broke from the past - such as making a uniform namespace and using 9P as the "glue layer." It turns out 9P could do many of the things that original UNIX layers could, so moving from a UNIX system was not a huge lift, but (as I understand it - Rob, please correct me if I have misinterpreted), it was not a goal to allow UNIX programs to be rebuilt with make(1) [or mk(1)] with no changes.
That can not be said for OS/360 or Linux. In fact, if the programmer had followed Henry's 10 Programmers' Commandments, you could type: make and most programs coming from your vax or 68000 UNIX box - "just worked." Brooks and team considered it a requirement that older applications "just work" - which, in fact, was one of the reasons why, even though at the inception of the project, S/360 was designed to be IBM's first ASCII system [remember IBM and AT&T were the two primary sponsors of ASCII to ASA and IBM person chaired the committee]. EBCDIC was created so that those old codes could be supported and ended up being the path of least resistance when OS/360 was late.
My point is that the cats appear after the fact. It is challenging to direct them towards your goals, not theirs. Thus, the 'benevolent dictator' model seems to appear in "successful" FOSS projects. I would argue with ers that this is actually the same Cathredal with a master builder making the choices, BTW.
Clem