[python-committers] An alternative governance model

Barry Warsaw barry at python.org
Wed Jul 18 14:39:31 EDT 2018

On Jul 18, 2018, at 10:13, Eric Snow <ericsnowcurrently at gmail.com> wrote:

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

I’m not concerned about that, and not just because I’m secretly wishing for a filibuster until I get to join Guido on the Isle of Former Pythonistas Who Know Prefer To Sip Margaritas In Peace and Quiet and No Internet.

Grooming suitable future leaders is critical to the relevance of Python for the next 30 years.  I’m confident that when the time comes, there will be obvious choices, just as there has been for Release Managers.  And if there really isn’t then future archeologists will point to this thread and say “maybe now we can experiment with a Supreme Council”.

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

I’d like to add: how do we ensure that we will have many suitable candidates if and when the time comes to choose the N+1BDFL?

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

To me, that’s the “vision” question, but I think the BDFL doesn’t just reflect the communities wishes, because “the community” will never agree 100% on anything.  Which, FTR, I think is okay.  The BDFL uses their intuition, compassion, and experience to move Python forward according to their vision for what the language should be, deeply informed by —but not subservient to— the opinions of all its users and developers, because that’s essentially impossible.

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

Indeed.  I’d say that we should be proactive so that we never get into that position, by beginning to groom future NBDFLs now.

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

That’s a good point, except that there is usually a window of practical recoverability.  For example, once Python 3.8 is released, PEP 572 will be very very difficult to undo.

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

Thanks Eric, these are good points to consider.

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

I’d put my money on Uncle Timmy coining that term, but maybe you’re on to something here.  Okay, let’s call our leader “Dinsdale”.  As in, who will be the Next Dinsdale?

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

FWIW, I would not expect PEP 2 to name a Next Dinsdale, er BDFL, er…

I have been thinking that PEP 3 would serve as the Historical Record of Past And Future Leaders.

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

Well put!  I’d also caution against excessive pessimism.  :)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180718/fe556049/attachment.sig>

More information about the python-committers mailing list