Before we jump into the interview, let’s review what Python is. Python is a general purpose programming language that is interpreted, interactive, object oriented, and of course, open source. It was created in 1991 by Guido van Rossum to and is particularly popular with researchers.
What are the different types of governance you have experience with? What are your thoughts on those experiences?
A lot of older, more established projects were more likely to start with BDFL (Benevolent Dictator for Life) and then adjust as they grow. BDFL works when the project is small or older but to be sustainable and not burn out the maintainer, it has to go beyond BDFL.
Python uses a Steering Council model. We combine it with Working Groups that can focus on individual topics and it works really well. The Steering Council is selected by the Core Developers.
There are a few steps to become a Core Developer. First, the person must contribute patches that meet the quality standards; a current Core Developer will most likely mentor the person, and they must gain the trust of the core development community.
For the Working Groups, there are a few ways you can break it down. You can have standing Working Groups or ones that have a specific charter with a beginning, middle, and end to them. The Working Groups are around ten people and cover matters like diversity and inclusion, planning events, workflows, and core documentation. People apply to be part of them and either the Board or Executive Director decide. It’s mainly core developers but some work groups ask for participation from the broader community.
How do you choose which type of governance is best for your project and how does that change over time?
It is important to take time to stand back and see what is working and what’s not working regardless of structure, and be prepared to adjust your plan. It is healthy to have a Board that has turnover. It allows for new ideas and gets away from the, “We have always done it this way” mentality. When succession planning, plan for this and give people a graceful exit plan if it’s not possible for them to continue.
How does your choice of governance affect areas like onboarding?
The type of governance you choose can be a barrier to entry for people not in the majority group. It is important to have a mission in your organization and bylaws to help you know if you are doing well.
To help with onboarding we did a few things, including:
- Creating a developer guide called “How You Contribute to Python”
- Having a core mentorship mailing list
- Using Discourse
- Connecting core developers with non-core developers for mentorship
- Recruiting folks who have been active and putting them on a triage team
How do you ensure the governance you have put in place is representative and is inclusive? Are there policies or mechanisms in place to help with this?
It’s hard to get diversity when you start from having no diversity, but we are moving in the right direction. The Python Software Foundation’s Board is very inclusive, although we do have room for improvement in geographic representation.
When electing members of the Python Software Foundation Board, a large part is dependent on name recognition, and it can be a popularity contest as people get voted in. However, the Working Groups help people get that recognition.
How do you design and implement new governance in such a way that you bring all your stakeholders along and do not alienate them? (those uncertain of change, those who had a stake in the status quo)
Brett Cannon and I did a “Talk Python to Me” podcast immediately after Guido van Rossum, author of Python, resigned. We said, “the processes are still in place and the only thing that will change is that the acceptance of new features is on hold until the new governance model is decided.” We then pulled together a group of people that had governance experience and wrote a bunch of PEPs (Python Enhancement Proposals) about governance. We had an in-person sprint with 40% of the developers there. We were able to bounce ideas off of each other, including asking people to identify one thing they would like to change about Python and one thing that is good about Python. We talked about all different kinds of governance and people wrote PEPs about each different type of governance. Guido stayed on for the inaugural Steering Council but was still able to step back and do the coding he loves.
We learned that having proactive communication and being honest and straightforward was what our contributors wanted. They all wanted to work together as they felt they owed it to Guido to continue with the language the way it was.
What advice do you have for someone who is new to open source community leadership?
- Increase the amount of time you spend listening vs speaking and writing emails
- Ask more questions rather than making statements
- Educate yourself on governance including nonprofit governance or reading books on governance
- Leveling up communication and conflict resolution skills
Read the other posts in our Accidental Maintainers series:
