You may have heard that we are producing an Accidental Maintainer series, a collection of interviews and resources to help open source maintainers navigate difficult decisions in unfamiliar territory. The first subject we’re tackling in this series is that of open source project governance.
Before we start, let’s first discuss the most important question… what is governance? Governance is the action or manner of governing. It affects how you make decisions, how you plan, who contributes, and how they do so.
We were able to interview some big names in the open source world including Jacob Kaplan-Moss, co-creator of Django; Carol Willing, Member of the Steering Council for Python; and Kinnaird McQuade, creator of Policy Sentry and Cloudsplaining. We got the scoop on each project’s type of governance, how they make changes, and how governance affects their community.
Types of Governance
New projects tend to start with the BDFL (Benevolent Dictator for Life) model. Most “accidental maintainers” will find themselves with this model. It is one person or a small group of people who are in charge of the project. While BDFL is the most common governance model, it commonly becomes “Ask the Founder” and leads to burn out. It also frequently leaves the community out when making decisions or crafting succession plans.
Although, it’s worth pointing out that Kinnaird McQuade, who would be considered a BDFL for Cloudsplaining and Policy Sentry, has done a great job of involving key stakeholders and contributors in his decisions–so the model is not mutually exclusive with community engagement. While he may look like the only person making decisions, he actually empowers his contributors to own issues and answer any questions that arise around that issue. He reaches out to his stakeholders when large decisions are being made to get their opinion on the change and to take in any advice. With all decisions he makes, he is thinking about how he can set Cloudsplaining and Policy Sentry up to succeed if he isn’t involved.
Django has gone through quite a few different types of governance models. They started as BDFL and then moved to a Core Team model where every one of the committers gets a vote. The Technical Board — a subset of the Core Team with formal voting powers — came next. A Technical Board can be broken down two ways: a simple structure where anyone who has the commit bit gets to vote on technical items, or a hybrid structure, where the foundation controls the intellectual property and the community, and committers control the code. Django then removed the Core Team to become a Member Driven Organization, in which people were elected into their roles rather than appointed. This broke down the barriers between technical and community governance. They also switched from all volunteer-driven to some paid positions for the more grueling and less enjoyable work that’s involved in project maintenance.
About this transition, Jacob Kaplan-Moss said,
When Adrian and I stepped back, we made a deliberate decision not to say what people should replace us with. The whole point was that we didn’t think that the BDFL model was working particularly well, so having the last thing we do be to dictate was bad. We stepped down because we were unhappy with our own leadership.
Python uses a Steering Council model selected by the core developers. It is combined with Working Groups that focus on individual topics. The Working Groups are around ten people each and focus on areas such as diversity and inclusion, events, workflows, and core documentation. They are mainly made up of core contributors, but not exclusively.
How to Make Changes to Your Governance
Making changes to your governance can be tough, and the way you go about it will be unique to your project and your community. When Guido van Rossum, creator and founder of Python, stepped down, Carol Willing and Brett Cannon immediately went on the “Talk Python to Me” podcast. They wanted to have proactive and honest communication of what the contributors and committers should expect to happen. They pulled together a group of people that had governance experience and later held an in-person sprint with 40% of the developers there. When bouncing ideas off of each other, they made sure to include one thing you would change and one thing that is good about Python. After they talked about all the different types of governance, they wrote a PEP (Python Enhancement Proposal) for each one. When they made their decision, Guido stayed on for the inaugural Steering Council. Carol says,
“I was surprised how well everyone worked together. There are a lot of strong personalities and strong opinions. But I think when push came to shove, most people felt they owed it to Guido to continue the language and the spirit of which it was created and to improve on it. And putting it in those terms instead of a winner and a loser, we all won.”
Django took a different approach. When Jacob Kaplan-Moss and Adrian Holovaty stepped down, they didn’t want to influence the governance model. They knew the BDFL model they were using wasn’t working and wanted the foundation and the contributors to come up with the new approach. Jacob pointed out that it’s important to have a strong sense of direction and to recognize that change is needed, to determine as a group how the decision will be made, and to provide very structured opportunities for feedback.
Since Kinnaird’s projects are both less than a year old, we talked about how he is going to make the change in the future. He said that documentation, keeping an open line of communication, and engaging directly with contributors is how he will make the change. We also talked about how imposter syndrome is real, even among open source project creators, and how it can lead people to not want to rely on others for help or their expertise. Kinnaird keeps in mind where his strengths are and where he can empower other contributors to step in.
Even though all three of these are different approaches, all of them touched on how important it is to communicate with your contributors and set expectations.
How Governance Affects Your Community
The type of governance you choose can affect all areas of your project community. Our next series will focus on building an inclusive community, but, as every decision influences this, we also wanted to see the three maintainers’ thoughts on it. A common theme we heard throughout was that building an inclusive community needs to start at the very beginning — both the inception of the project and the beginning of the committers’ experience with the project.
All three projects talked about how governance can be a barrier to entry. It can be overly complicated, not welcoming to members of a minority group, or not welcoming to people who are new to open source in general or that language in particular. Documenting the onboarding process with a beginner’s mind can go a long way toward welcoming people in. Kinnaird made some observations from the early days of his projects:
“I’ve noticed there are people who have made really meaningful feature requests to either of my tools where they are actually learning Python. One person reached out and said ‘I want to turn this into an AWS Lambda function and expose it as an API.’ I could have tried this myself — but in the interest of expanding the community, I just messaged back and forth with this person about how to write a Lambda function and how the backend of my tool worked, and they were able to figure it out. They even helped uncover some bugs! I’ve found that if it takes a bit longer, but the community grows a bit more, the extra effort on my part is worth it.”
Python is addressing this issue by providing mentorship opportunities between core contributors and non-core contributors, and finding people who are active in the Python community and putting them on the triage team.
Part of documentation and governance is also having a Code of Conduct and enforcement procedures. All of the projects that we talked to have a Code of Conduct, but Jacob mentioned how it’s about more than just the Code of Conduct itself. You need to have a committee who receives and handles violations. You need to ensure the safety of every member of your community!
If you have a governance model such as a Steering Committee, Core Team, or Technical Board like Python and Django do, holding elections for these positions can help with bringing diversity and inclusion into your project. That said, you need to make sure it doesn’t turn into a popularity contest or only voting for people who look like you.
Building an inclusive community is something you need to keep in mind with all the changes that you make as a maintainer. We are excited to dive into this topic deeper with our next topic of “How to Build an Inclusive, Welcoming Community.”
Want to Know More?
We could have filled a book with our discussions with Carol, Jacob, and Kinnaird, but we settled on a blog post! Ping @SalesforceEng on Twitter with your thoughts on governance or any topics you want us to cover!
For a deeper dive into what these maintainers thought, check out their interviews:
