On Wed, Jul 3, 2024 at 1:02 AM Al Kossow <aek(a)bitsavers.org> wrote:
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 <sjenkin(a)canb.auug.org.au> 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
ᐧ