[TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?

["Theodore Ts'o" <tytso@mit.edu>]

On Wed, Jul 03, 2024 at 10:04:58AM -0400, Clem Cole wrote:
> On Wed, Jul 3, 2024 at 1:02 AM Al Kossow <aek@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.

This.  It's more about the scope of the project.  I had a work project
(a new form of SMR disks where you can dynamically convert regions of
disk platters from CMR to SMR non-destructively with respect to the
region of the disk not being converted) where I was herding cats from
multiple different product areas (departments): hardware platforms,
software infrastructure, software reliability engineers) reporting to
different VP's with different departmental OKR's for which they get
their performance reviews.

I also had to wrangle two different HDD manufacturer partners, and a
T.13 standards subcommittee, and my skills trying to hold together a
team where I had no management authority, nor a VP to glower
threateningly behind me, stood me in very good stead.  Fortunately
leadership stints that I had in the open source world, the IETF,
USENIX, and the Episcopal Diocese of Massachusetts meant that this
weasn't the first time to do this kind of cat herding.

Small might be beautiful, but this project reduced storage TCO costs
by vast amounts of money, so my company thought it was really pretty.  :-)

> 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.

In essentially all volunteer projects, a leader's only real power is
to say "no".  They can't force anyone to do anything that they want,
but instead have to rely on their skills of pursuation.  This is true
if you are an open source leader, or if you are an IETF Area Director.
In the case of a non-profit which has money, such as (for example)
Usenix or the Episcopal Diocese of Massachusetts, or the Linux
Foundation, you might have some ability to issue commands to the
staff.  But the vast majority of the work of these non-profits rely on
volunteers, and so again, you have to be able to pursuade those
volunteers community to follow you when you say, "let's go thataway".

The organizations which are lucky enough to have such servant leaders
will tend to prosper.  OTOH, open source projects which spend huge
amounts of time fighting over who has CVS commit access, leading to
factions of developers to fork off to form rival projects, will tend
to be less successful.  There are lots of people who will complain
about Linus Torvalds' supposed lack of social skills; but his ability
to hold the senior members of the development community together
without having the sorts of splits that we saw in FreeBSD, NetBSD,
OpenBSD, DragonflyBSD, etc., should be a hint that the story is a bit
more complicated than what is promulgated by the click-baity headlines
out there.

	      	       		   	     - Ted