The future of the governance of python

Since this announce, the community need to find a solution to this issue.

In august 2018, the python community, especially Barry Warsaw create the PEP-8000 to centralize core developers propositions about governance.

This PEP provides an overview of the selection process for a new model of Python language governance in the wake of Guido’s retirement. Once the governance model is selected, it will be codified in PEP 13.

Currently this PEP centralize 7propositions (PEPs):

Victor Stinner, the author of the PEP 8015, have also write a comparison of the 7 governance PEPs, I really advice you to take a look for an overview of these propositions and to have an overview of futur of Python in general.

Governance paradigm

Most PEPs define a “top of the hierarchy” (Steering Committee, Council, Trio, GUIDO, etc.), but PEP 8012 and 8014 don’t.

We can observe the following paradigms of governance:

Working groups

Some PEP (8011, 8012, 8015) define “working groups” (or “experts” or “Python Teams”).

They are explicitly involved in the decision process, and may be seen as the second level of the hierarchy.

We can compare the working groups with the Linux organization and the Linus lieutenants, who works on dedicated topics. Each lieutenant manage a topic and merge patches dedicated to this topic. This sound like a pre-filter, after this a general core developer can decide to merge patch or a series of patches inside the top level repository.

These working groups can introduce the notion of core commiter with limited rights (rights limited on a specific topic), example, you can become core developer only for the performance team (dedicated to the performance topics), or become core developer only for the security team.

I personally really appreciate this approach, due to the fact that python need to find more core developers to treat subjects and to spread the workload over core members, so if we increase the number of core members we also increase the well being of them. It’s my point of view.

Voting process and decisions

All over these PEPs the voting process and decision process is strongly around the core developers in all governance PEPs. Candidates must be core developers, only core developers can vote, etc.

Only the PEP 8014 define that every Python user (everybody) can votes. Votes can be for a PEP or for choices and orientations, by example, to example a few.

Only PEP 8013 excludes core developers from its council.

Companies lobbying

When a technology is owned by a community the risk that companies try to own her by lobbying exist.

To avoid companies to own the language, to impose theirs decisions, some PEPs, like PEP 8015 and PEP 8016, restrict companies to have strictly less than 50% members of the council:

PEP 8015: 1 member

PEP 8016: 2 members

Other PEPs have no restriction.

The idea is to reduce the risk that a group of people or companies “takes over” the Python project through just a couple individuals. The project must remain autonomous and open to everybody.

I totally agree this restriction, I think it’s essential to keep Python independent and owned by the community.

Enforce diversity

Some PEPs (PEP 8011, PEP 8014, PEP 8015) take care about the diversity and mention it, especially the PEP 8011 who try to make an effort about this topics by saying:

Take every effort into including members from under-represented group into consideration.

Personally I’m convinced that diversity is the key of new ways of thinking and doing, so I think that diversity need to be an important effort on the python governance next generation.

What’s next?

Now, the vote for the choose of the new governance will happen in 2 weeks-long window from the Friday 16th of November 2018 to the Friday 30th of November 2018 (anywhere on earth). All the PEPs will be frozen to avoid mistakes and changes during this period.

This article is motivated by a discussion that I’ve had the last week with an end user of python who is afraid since the Guido announcement, so, I think it’s important to share news with the community and beyond.

I really advice you to read the Victor Stinner post to dig more deeply this topic and to have more precise overview. Also, a major parts of my write are extract and/or rewrite from its post, and my main goal is to spread the words to more persons than the core community, to reach python end users, and to help you to keep confidence in python.