[python-committers] An alternative governance model

Eric Snow ericsnowcurrently at gmail.com
Wed Jul 18 13:13:46 EDT 2018


On Wed, Jul 18, 2018 at 2:43 AM Antoine Pitrou <antoine at python.org> wrote:
> Le 18/07/2018 à 04:02, Barry Warsaw a écrit :
> > A singular BDFL provides clear leadership.  With a council of elders, it will be more difficult to communicate both to the Python community, and to the larger, more peripheral user base, that any particular individual has the authority to make decisions.  Regardless of size, there would ultimately be some one person communicating any council decision.  There will inevitably be ambiguity as to the authority of said decision.
>
> Why do you think non-BDFL projects have a problem with """ambiguity as
> to the authority of said decision"""?  What is your basis for that
> assertion?
>
> I'm worried that you seem to be descending into magical thought,
> believing for some reason that nothing else than monarchy could ever
> work for a software project.

tl;dr  We worry too much :)

While I do not feel quite the same way on your point, Antoine, I'm
glad you brought this up.  A blanket policy of monarchy would be a
serious problem at the point that a BDFL goes "rogue".  However, a
blanket opposition to monarchy leads to its own problems.  Relative to
the BDFL's power, context is significant here.

There is apparently a lot of support (mine included) for Barry's
proposal.  However, we might be blinded, now and in general, to the
possibility of a rogue BDFL by the availability of good candidates
(that "clearly" would not go rogue) in the present and struggle to
imagine a time that there isn't such a candidate or that we were wrong
about them.  In fact, IIUC some reputable core devs do not feel like
there's any such candidate now (no disrespect, Brett), based on what
they expect a BDFL to be.  We need to respect that and consider that
viewpoint.  Regardless of when it happens (if ever), what will happen
in the future when we don't have anyone suitable?  One danger is that
we will install someone un-suitable because "we've always had a BDFL".
But what is that "danger"?  What impact could a rogue BDFL have?

Before diving in to that, consider that change has a directly
proportional relationship with disruption.  Disruption to any
organization has a pretty high cost, so the effect should be carefully
considered before deciding to make changes (which is what we're doing,
hopefully).  In our case, figuring out how to proceed
post-Guido-as-BDFL, we should make sure there's a good reason to
change our "governance model".  [Really quick: python-dev is rather
ad-hoc as an org, so calling it a "governance model" is a bit
misleading.]  We've been operating (successfully) for decades with a
BDFL.  As others have indicated, Python greatly owes its success to
having a BDFL.  Assuming we find a suitable replacement (I think we
can), why otherwise disrupt things?  "this is our chance to change so
we should" is an extremely weak argument on its own (and a dangerous
one), as is "monarchs are always bad".  There needs to be a stronger
reason (one that applies concretely to us).  Otherwise, at the least
"status quo wins a stalemate" here.  Arguably the best course of
action would be to change as little as possible.

All that said, I strongly affirm that we should not dismiss concerns
and differing opinions.  We need to consider them and be respectful.
We must resist the temptation to say "let's be real, that isn't
something we need to worry about".  That's why I'm glad you said what
you did, Antoine.  It made me think about a few aspects of the status
quo that may be worth addressing sooner rather than later.  Along
those lines, I consider the following questions to be significant.
I'll address them a little, but not conclusively.

1. what makes a good BDFL?
2. what do we do when we can't find a suitable candidate?
3. what negative impact can a BDFL have?
4. how do we mitigate that impact?  how do we deal with a "bad" BDFL?

In my mind the key question is #3 (see my comments below).

----------

1. what makes a good BDFL?

This is already being discussed in other threads, e.g. about the
"roles" of the BDFL.  I'll add that the BDFL is someone we trust to
lead Python into the future, even when it's hard and even when we
strongly disagree with them.  As a core team we rely on the BDFL to
help us make hard technical decisions.

However, I supposed I hadn't considered it before, but the BDFL has a
much more significant role.  The Python community is in many ways a
reflection of Guido and a result of his leadership (much more than
technical leadership).  Consequently, a new BDFL must be someone who
reflects where we want the community to be.

2. what do we do when we can't find a suitable candidate?

This is worth figuring out.  It isn't something we've discussed much.
I expect most folks feel like it will never be an issue.  I suppose
they're right.  At the point there isn't a suitable candidate, we have
larger problems to address. :)

3. what negative impact can a BDFL have?

I was primarily thinking about a "rogue" BDFL, rather that about
mistakes an otherwise good one might make.  The big question is what
does it mean for the BDFL to go "rogue".  It definitely isn't "making
a decision the people don't agree with" as Guido has done that plenty
of times (to our benefit). :)  In my mind, the main bad that the BDFL
can do is to hurt the community.  Their possible negative technical
impact is small and highly recoverable.

As the leader of Python, the BDFL is in a position to hurt the
project; by offending the Python community, by making Python less
appealing to new users, by alienating existing contributors, and by
discouraging new contributors.  While the BDFL has the final say in
changes to the language (through the PEP process), this isn't
something easily abused nor hard to repair.  Furthermore, the BDFL is
otherwise already quite limited in authority and power.  For instance,
relative to the code they have no special standing; they are one among
many committers.

4. how do we mitigate that impact?  how do we deal with a "bad" BDFL?

People make mistakes.  We should expect the BDFL to make them too.  We
should also expect them to care deeply about Python (as well as align
relatively closely with the community).  We can deal with their
mistakes. :)

However, if the BDFL turns out to be not as capable as we expected (no
judgement, Brett) or appears to be purposefully hurting Python then
we'd need to act.  On the one hand we'd need to deal with the BDFL
directly, likely replacing them or more broadly restructuring.  On the
other had we'd have to deal with the community consequences (the four
listed in point #3).  The latter is the one with deeper consequences.
TBH, the same is true of any structure we apply (e.g. council,
majority rule).

I suppose the most we could plan for would be quickly removing a rogue
BDFL (but without such a plan hanging over a good BDFL's head).  I'd
consider Barry's proposal of advisers to be in the right direction.
That said, as with #2 this is probably not something that will ever
come up.

(Other approaches to project governance might also help mitigate the
equivalent effect of a rogue BDFL on the community.  However, they
make the technical decision-making side of things worse.  There are
serious trade-offs when more people are involved in the
decision-making.  I consider sticking with a BDFL worth it.)

----------

> You're creating a huge problem here.  Whatever dictator you come up
> with, not everyone will be ok with that choice.  What are they supposed
> to do?  If one doesn't think X is legitimate as a dictator, how does one
> keep contributing to the project?  In other words, you are threatening
> to exclude people, perhaps seasoned contributors.

This is a real issue we need to solve.  I'm not sure what we can do
though.  Not everyone will be happy with any approach we take.  That's
frustrating because I highly doubt anyone here wants anyone else to
feel excluded.  I challenge all of us to make this a priority as we
consider an approach for replacing Guido.  (Hopefully my other
comments reflect this priority!)

> (*) (I'm leaving the "benevolent" part out, since clearly it was only
> tied to Guido's personality, not to any inherent statutory limitations)

The "benevolent" part is critical though.  Without it none of the rest
would work for us.  Perhaps I've misunderstood your point?  FWIW, the
word "dictator" has a lot of negative connotation that does not match
our usage in BDFL.  I don't mean to suggest that's the only concern
here, but would it help to use a different name than BDFL?  IIRC, it's
either a clever Monty Python reference or a tongue-in-cheek expression
from Barry 20 years ago that stuck.

> What if we don't subscribe to
> your views of Brett's qualities: do you expect us to publicly criticize
> Brett so as to justify our opposition?

Fair enough.  I don't mean to put Barry or Brett in an uncomfortable
position here, but at the point where we're discussing potential BDFL
candidates, we need to be just as open and honest about concerns as
about qualifications.  However, perhaps we're premature in discussing
candidates (before we've decided to stick with a BDFL).  While I too
would support Brett, I agree that tying Brett to the BDFL proposal
makes the discussion harder when there is opposition, which obviously
there is.  So we should probably focus just on the BDFL proposal
itself and then move on to the candidates once (if) that's settled.

> Your proposal is turning this discussion into some kind of Napoleonic
> plebiscite.  This is frankly unpleasant :-/

:(

We definitely need to be honest (and respectful) here so thanks for
expressing that.  I'm hopeful we can all work together to find a
solution that will benefit Python going forward.  Let's take this as
an opportunity to understand each other's viewpoints and get on the
same page.  Let's build on the basis that we have in common.

In summary, we're a relatively as-hoc, unorganized group without much
structure to bind us down.  This has worked because we've had an
effective BDFL.  Even if we get things wrong now by changing
minimally, there is no real blocker to fixing things later (except
*maybe* momentum).  However if we add a bunch of structure there's a
risk that we'll find it hard to undo.  Ultimately, we should be
careful about premature optimization.

-eric


More information about the python-committers mailing list