This week wraps up my training in the Mozilla Open Leaders initiative. It’s been an amazing, very intense 14 weeks of learning, all in support of the team in the cross-project CMS privacy group.
The goal of the Mozilla Open Leaders initiative is to equip participants with the knowledge, leadership skills, and practical resources needed to build healthy open source projects, and to lead them in the open. Weekly reading and homework assignments were accompanied by the materials in the Open Leadership Training Series. In addition to those, we alternated weeks between one-on-one mentoring sessions (Hi Dave!) and group cohort chats.
(Our cohort was called Design and Concur. It’s the antithesis of Divide and Conquer. Get it?)
For the cross-project privacy group, the lessons I learned about open source governance, management, and sustainability have been documented in my final case study. You’ll find some surprises in there, and perhaps a spoiler.
For me personally, there were a few revelations about open source project leadership which I wasn’t expecting.
Leadership can start from the bottom
We think of open source leadership as existing from the top; for example, a large CMS project establishing transparent governance structures for decision-making. The training taught me that project governance can lead from the bottom.
What do I mean by that? Well, look at yourselves. A major plugin can have healthy governance. A code library can have healthy governance. A governance initiative can have healthy governance.
There’s no need to wait for the project leadership at the top to start processes which can take years. It’s your projects which can set the example.
Open source governance can be a form of gaslighting
Early on in the training we learned about the two major models for open source governance.
Open by design, the first model, is what projects should use. Open by design projects are:
- Intentional, ordered, strategic, process-based, inclusive, open for revision
- Practice openness in governance, content-development, and information-sharing
- Support shared practices for governance, collaboration, delegation, and conflict resolution
- Equitable, fair, and review themselves every few years
- When projects are open by design, people have a clear idea of how to be in an inclusive, collaborative community with others, how to get help, and how recognise one another and their contributions.
Open by default, the second model, is what most projects actually use. Open by default projects are:
- Vague, chaotic, tacked on as an afterthought
- Driven by legacy community members or strong personalities rather than active communities
- Inclined to insist that the project is open, for example, “anyone can contribute”, without addressing why people cannot contribute
- Inequitable, unfair, clinging to origin myths from years ago
- When projects are open by default, it’s because they stick something in a repo or throw an open license on it
That second category, open by default, occurs by accident through a lack of care; it’s the natural slippage that happens in all projects, and it can be easily remedied. But as we learned, there is a third category of open source governance, once that’s neither accidental nor repairable.
It’s called open washing. It’s what happens when projects are open in name only, usually in terms of the four software freedoms, but are not legitimate open projects by any other definition. Open washing projects:
- Practice closed governance, closed decision-making, and have little to no transparency in legal structure
- Use openness to divide and conquer, using active provocations of conflict within communities
- Are centred around specific personalities who are untouchable and unaccountable
- Set people up to fail with inadequate resourcing, communications, or support
- Exploit the four software freedoms as a tool for division – “if you don’t like how we do things, fork it”.
As someone who’s been told, in so many words, fork you, that particular lesson hit hard. The thing about finding out that someone’s been lying to you for years is that you’re actually happy about it. Finally, you know that you’ve not been losing your mind that whole time. You’ve been open washed.
It’s not you. It’s your project.
Working together is the way forward
As I said in the case study, having Mozilla at my back – and the group’s back as well – has been the key to moving forward. Sometimes you feel like the lunatic howling at the moon with your crazy ideas about cross-project collaboration and making the web a better place, and then a group of people come along who start the conversation with, and I quote, “we want to help you and your project succeed.”
We know, in the cross-project group, that we can do more by working together. We also know that groups like Mozilla can amplify our voices, connect us to the right people, and give us the resources we need to grow stronger. The training drove home for me that collaboration across projects and the open source ecosystem isn’t just a nice thing to have – it’s the key to sustainability for us all.
Now it’s your turn to follow our lead.