[Numpy-discussion] NumPy Governance

[Joe Harrington]

I had intended to stay quiet in this discussion since I am not a core
developer and also no longer even lead the doc project.  However, I've
watched two organizations go very wrong very fast recently.  Both were
similar in structure to this one.  I've done some study as a result and
there are some lessons to learn.

The committee-of-doers-and-executive format is very effective when it
works.  It's worked well for numpy and many other OSS projects.
Benevolence and commitment of the leader are made likely by choosing
someone who is already doing a lot and whom everyone knows.  Yet it can
still go wrong.  By studying the failures, as well as the successes, we
can build in some safeguards.

So, I'll tell the story of Pack 608.  (It's the next four paragraphs if
you want to skip it.)  This is a Cub Scout Pack, which for those who
don't already know is a group of 20-100 boys, ages 6-10, who participate
in a variety of indoor and outdoor activities that are designed to build
good character (whether they do is a different discussion).

Our group has about 80 boys.  It is run by parents who volunteer their
time, and it is led by a Pack Committee, with a Chair and a Chartered
Organization Representative.  The latter is an overlord who can overrule
anything but by design usually observes from the sidelines and only
steps in when things go wrong.  He represents the organization (usually
a church or community service organization) that owns the pack.  There
is also a Cubmaster, who is the face of the organization to the boys.
He reports to the Committee but is a really big dog there, often as big
as the Chair.  Sometimes bigger.  Running a group of 80 boys doing a
dozen activities a year is a huge job, way too big for any individual
with a job, so finding and developing parent volunteers is hard.

In our group, one married couple, extremely committed, got involved and
began doing a huge number of tasks.  Whenever anyone slacked off, they
took over that job.  They did those jobs extremely well.  As our top
leadership moved on (their boys turned 11 and became Boy Scouts),
eventually we looked around and the clear choice for the Chair and
Cubmaster were these two.  We were not exited about installing a married
couple in two of three key posts, but we had few options.  We didn't
want to do it, but nobody else stepped up.

It was the biggest mistake we ever made.  Even though everything this
couple did was, in their eyes, in the best interest of the boys and the
group, their style was so overbearing and their opinions so inflexible
that there were serious verbal conflicts and other leaders began to
quit.  Some non-leaders complained, the Chartered Org. Rep. called a
meeting, and these two were forced to step down.  But, by this time,
they were doing so many tasks that between them and the other departed
leaders, we had lost EIGHT critical leadership roles (for those who know
Scouts, these were Committee Chair, Cubmaster, Outdoors Chair, Events
Chair, Advancement Chair, Fundraising Chair, and two Den Leaders).  The
pack nearly folded, but we managed to pull in a few parents (including
me) who were neither eager to get close to this group nor really ready
to spend a lot of time on it.  We aren't yet up to where we used to be a
year ago, but we're surviving.  It's been brutal on our personal and
work time, however.  It would have been much easier had we stepped up
before the fiasco.

While such near-collapses are infrequent in small organizations, they
happen often enough that many readers have probably experienced one.
They can happen out of poor choice of leaders, feelings of
possessiveness, differences of vision among stakeholders, and a host of
other causes.  The point here is to build into any organization plan not
just the structure that will let it succeed, but also the safeguards
that will reduce the chances of failure by catching and correcting
organizational health problems early.

With OSS, we have an ultimate safeguard, which is that anyone can fork
the source and start a new org.  But, as we've seen in this project,
forks are *very* damaging and can take years to recover from, so it
makes sense to think about safeguards in this organization, too.

There are organizations of organizations that provide advice on this
topic.  Among the key suggestions:

- Have uninvolved oversight.  In Pack 608's case this was the Chartered
  Org. Rep.  For us it could be an external board with some community
  reps.  This oversight itself can be abused, so it must be limited to
  removing problem leaders and calling an election, or even just to
  calling an election.  It should probably NOT extend to changing
  decisions on the code, other than forcing a vote of reconsideration.

- Rotate key posts.  When people do a job forever, they can become
  possessive of it.  Not everyone does, but it's common.  The job
  becomes tailored to the person, others don't know how it's done, key
  practices go undocumented, and if that person leaves or is temporarily
  unavailable at a key time or if a change needs to be made and that
  person disagrees, there's trouble.  Feeling part ownership is good.
  Feeling full possession is not.  The lack of central ownership is a
  big piece of why we can trust OSS in a way we can't trust commercial
  software.  So, rotate key jobs.

- Ensure that critical authorities (keys, passwords, certificates, title
  to important property like a web domain, signatory authority on a bank
  account) are never held by just one or even two people.  Make sure the
  oversight entity has ultimate access.

- Have multiple sources of key resources, like labor and money, so that
  the threat of taking them away is not debilitating.  This means not
  letting one person hold too many jobs, too.

- Have a well defined voting procedure and rules of order.  You don't
  have to use them all the time when consensus is clear.  They can be
  slow and cumbersome.  But, when there is conflict, they ensure
  fairness.

- Have a no-confidence vote procedure that removes a problem Chair.  The
  rules for this need to be carefully thought out.

- Have the consent group, and not the outgoing Chair, choose the next
  Chair.  There are many reasons a Chair moves on, including lack of
  time, becoming tired of the job, and differences of opinion with the
  consent group.  Especially in the latter case, you don't want the
  former Chair to influence the future.

- Have open meetings with posted minutes.  Keep no secrets (except
  passwords, etc.).

As Ondrej pointed out, identifying the potential leaders isn't hard, in
our case, but I think those in the consent group should include more
than just coders.  There has been a lot of work on the docs, for
example, though not as much recently.  Leaders of key client packages
should be involved.  Representatives of key user classes (astronomers,
neuroscientists, statisticians, numerical programming teachers, newbies,
etc.) would be important.  Perhaps it's ok to let most coding questions
go to the coders, but significant decisions that could change the
direction of the effort should be referred to the wider group of
stakeholders.  That could be the mailing list, but then voting becomes
vague.  I would suggest including some number of core coders and an
equal number of community representatives.  Or perhaps the community
reps become the oversight board, which also includes a small minority of
coding reps.

One method that works well for continuity is to elect a Vice-Chair who
shadows the Chair and is involved in decisions for a period, then
becomes Chair.  The Past Chair can be a formal position, too, whose role
it is to provide advice.  This also eases the transition out of the top
job.  The Past Chair should be a resource only, and have no special
authority.

There are lots of sample organizational bylaws available online that can
serve as a template.  If we join an existing organization, e.g., for
fundraising, they likely have requirements that our bylaws need to meet.

To sum it up, the BDFL system is great if you have a truly BD.  It's
most likely to find one in the founder of an effort.  Once they step
down, be wary of centralizing too much authority.  If one out of four
leaders is less than fully committed, competent, and benevolent, it's
trouble.  We should at least have oversight and procedures that can
remove a problem leader.  Numpy is at a difficult stage, where we like
the freedom of not having written rules and procedures, but we're at
risk if we don't.  Much larger and it's clear we need them, and vice
versa.  The time we'll wish we had them is when we have a leadership
crisis.  The chances of having one are small, but not vanishingly so.

--jh--