[python-committers] An alternative governance model

Barry Warsaw barry at python.org
Tue Jul 17 22:02:46 EDT 2018

I’d like to propose an alternative model, and with it a succession plan, that IMHO hasn’t gotten enough discussion.  It’s fairly radical in that it proposes to not actually change that much!

TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors that helps the BDFL in various capacities, with additional responsibilities.  I also have someone specific in mind for the NBDFL, but you’ll have to read on for the big reveal.

Why keep a singular BDFL?  I think it’s clear that no one can completely replace Guido, and neither should we try, nor do we need to.  The discussion to date has explored refactoring many of the roles that the BDFL has, and that’s all excellent, especially to reduce the burden and burnout factor of the NBDFL.  But I think having a singular BDFL making the tough decisions, with the support and help of the community, is in the best interests of Python over the long term.

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.  How will folks, especially on the periphery, know that Alice Jones or Bob Smith are members of the council and can speak authoritatively on decisions for the language?  “Bob Smith, on Behalf of the GUIDO” is IMHO less obviously and unquestionably authoritative than “Alice Jones, BDFL”.

This also comes into play for shutting down discussions early.  With a committee, it’s possible that you’ll have some disagreement among the members as to whether a discussion is fruitful or not, whether it rehashes settled questions, or whether the change fits into the overall direction for Python’s evolution.  Alice Jones may say “No, that’s not gonna happen” only to be overruled or undermined by Bob Smith’s “That’s a good idea”.

Taken together, these fall under the umbrella of having one voice for the decision making process.  It may be possible for consensus within the council to come across as a single voice, but I think it will generally be harder.  A council also opens the door for more back-channel lobbying of a sympathetic member.  Yes, such lobbying is possible with a BDFL, but at least there should be less contention.

I also think a council will be much more risk adverse than a singular BDFL, and that’s not necessarily a good thing.  While moratoriums and a more conservative approach to change may be appropriate at times, I would prefer those to be deliberate decisions for a specific purpose, rather than the unintended outcome of groupthink or lack of consensus.  A singular BDFL with support from the community will have more authority to make decisions which probably will never be universally accepted, and much less prone to vapor lock due to lack of consensus or internal bickering.

I hope Guido won’t mind me relating a comment of his that has really resonated with me over the last few days, and for which I think a singular BDFL will be much more adept at communicating and shepherding.  The question for any new leader is:

What is your vision for Python?

This question keeps coming to mind as I think about how the evolution of the language will be governed over the next few years or decades.  Yes, Python is a mature language, but it’s far from stagnant.  Guido always had a very clear vision of what Python should be, where it should go, and how new proposed features (or other changes to the Python ecosystem) fit into that vision, even if he didn’t or couldn’t always clearly articulate them.  The NBDFL will necessarily have a different vision than Guido, and I think even he would agree that that’s okay!  A strong vision is better than no vision.  Python must continue to grow and evolve if it is to stay relevant in a rapidly change technology environment.  As an almost 30 year old language, Python is already facing challenges; how will that vision address those challenges, even if to explicitly choose the status quo?

Will a council be able to articular, express, communicate, adapt, and follow through on that vision?  Will a council be able to evaluate a proposed change as it supports or detracts from that vision?  Will a council be able to break out of a primarily maintenance position, to actually move the language and its primary implementation forward?  I’m not so sure.

For these reasons I propose that we retain a singular BDFL.

The formation of a formal Council is still a good idea!  I just think that it shouldn’t be the ultimate arbiter of decisions for Python.  So what would the Council do?

- It would serve as a check on the BDFL.  If Bob Smith were one day employed by Evil Corp. and started making decisions that were directly detrimental to Python, the council should be able to effectively impeach.  There should be checks and balances on this power, the BDFL shouldn’t continuously fear a coup, and impeachment will hopefully never be invoked, but the council can serve as the voice of the community for when the BDFL is abusing their power.

- The council would select the next BDFL if and when that time comes.  No one will serve forever, so a clear succession plan should be in place.  To avoid the tyranny of the majority, the council would serve similarly to a board of directors.  They’d search for candidates, match them against well defined criteria, conduct interviews, serve as the voice of the community, and eventually select the N+1BDFL.

- The council would serve as trusted advisors to the NBDFL.  The BDFL won’t be out there all alone!  The council will provide advice when requested, and back up the BDFL when needed.  The council helps legitimize the BDFL and their decisions.

We can debate how the initial council is selected, its make up, number of members, term limits, etc.  I think much of the current discussion about a BDFL-like council would satisfy the requirements for a Council of Advisors.  It’s just that the roles and responsibilities would differ.  The COA wouldn’t make the decisions, but it would help the BDFL make the best decisions possible, and have their back against any detractors.

I definitely have my own thoughts on an initial make-up of said council, but I’ll reserve that for later.

If you’ve read this far - thank you!  Now for the big reveal.  I think the Next BDFL should be… (drum roll)…

Brett Cannon

I’ve long said — somewhat in jest, since I never expected Guido to actually ever retire! — that Brett would be my choice for the next BDFL.  I think he’s the perfect candidate, and he’s already demonstrated qualities that I think make him a fantastic leader.  He’s smart, compassionate, passionate, respectful, young, tall, and has the right mix of technical excellence and social skills.  He believes deeply in diversity and community.  As he’s shown with the decisions to move first to Mercurial, then to git/GitLab, he isn't afraid to make difficult decisions that he knows not everyone will agree with (and I say that having advocated the losing choice more than once :). He’s not afraid to say what’s on his mind.  I think he can clearly articulate a Vision.  He shares many of these same qualities with Guido, while being a different person with different sensibilities.  And that is not only fine, but IMHO a *good* thing.  We can trust his stewardship, and he already has legitimacy as a senior decision maker in the Python ecosystem.  He has a wide technical knowledge of Python and its C implementation, and yet he knows what he doesn’t know.  He has good relationships with most core devs, and is a well-known voice within the wider community.  He’ll be able to delegate where appropriate, and make definitive pronouncements where needed.

Before you ask, yes I did check with Brett before making this proposal and he didn’t shoot it down.  He may have specific requirements for accepting the position, but I’ll let him articulate those.  I’m confident they would come across as completely reasonable. :)

To summarize:

* We retain a singular BDFL to lead Python
* A Council is selected to serve as advisors to the BDFL, a selection committee for succession, and a check against the BDFL.

That’s it in a nutshell.  Thanks for listening.


-------------- 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/20180717/3fc4bf6d/attachment.sig>

More information about the python-committers mailing list