A Venn diagram of Open Source governance

Good governance of Open Source projects is really important:

• Allows for direction, priority and planning (both short and long-term).
• Allows for opinionated design decisions.
• Can resolve conflicts.
• Enables a financial body, i.e. to uphold fixed costs or compensate developers.
• Oversees maintainer workloads.
• Can enforce a Code of Conduct

But rather than having clear governance, I see most projects (including my own) default to an unfulfilled mix of maintainers, community and owners.

Here is the diagram, I’ll discuss it a bit, but you can also stop reading here and use it in your own way before reading what I had in mind.

Definitions

Ownership, maintenance and community are fluent categories, vulnerable to different definitions. You can make up your own, too. Here, we understand community loosely as someone who uses the software and would care to raise an issue in a repository or participate in support questions. Let’s say that the owner of the project posts all the issues themselves and answers all the support questions: Then the project doesn’t have a community.

A project has maintenance as long as the owner or someone else is around to keep it alive.

Finally, ownership is about who does all the executive calls: Adds new maintainers, sets a direction for the project.

We can use such a diagram to understand and discuss governance of Open Source projects, but we can also stop to think:

When is a project really Open Source?

Does it have a LICENSE file that says it’s legally speaking Open Source? Okay, nice, but there are so many examples of unused/unusable “code dumps” with LICENSE files. Clearly there are other issues at stake:

• Does the project have documentation?
• Is the project relevant to others?
• Is it possible to send in a Pull Request?
• Barriers of usage: Does the project hide anything about how it can be self-hosted, built locally etc.?
• Is there some participatory governance in place?

I asked the other question to show that in some conceptual understanding of a sliding scale of less<=>more Open Source, then a democratic governance model would - in my opinion - make a project more Open Source.

You can also ask this in a framing of sustainability and health. Asking questions about the governance of a project unlocks the same areas of concern as asking about its general health and whether it’s gonna be alive next year.

Intersection 1: Ownership and maintenance

Here we have the first of several classics: This case happens often when the large company or NGO have created an Open Source project and simply published it. They might even have documentation. But because of factors that should be understood better, they don’t have a community.

• Maybe the users are passive or lack motivation?
• Maybe the project isn’t relevant to anyone else but the company/NGO that owns it?
• Maybe paid staff take up too much space, pushing out the community?
• Maybe the project looks and feels commercial, making potential community behave towards the maintainers as if they are a customer service?

Intersection 2: Ownership and community

Have you ever seen a project where there’s lots of community and someone owns the project but isn’t maintaining it? It’s that project where hundreds of PRs are stale, and people are talking about which fork to switch to.

How did we get here? Well actually, there’s a bit of success here: Despite the lack of maintenance, the community is still around waiting for something to happen.

• Clearly, the owners should have not also been the sole maintainers
• …but it’s not just the owner’s fault. While they were still maintaining the project, the active community could have noticed the single-maintainer-and-owner issue.
• The BDFL-by-default is undesirable: If it’s declared as an intentional choice, then we can rely on it.

Intersection 3: Maintenance and community

Is it a problem that there is no owner around? Well, yes it will eventually be a problem. You need an owner to onboard new maintainers, and you need them to do other owner things. Changing settings in a GitHub organization, CI, package publications etc. The absence of an owner might not seem problematic at first, but problems will usually start appearing and slowly suffocate the energy of community and maintainers.

I know many examples where this has happened. They are both related to having a single owner, or a company that hasn’t take responsibility for the community and maintainers they have made dependent.

The owner clearly should have given away the keys instead of disappearing with them. But why haven’t they?

• Motivational challenges: People and companies may not benefit from their own projects and disappear.
• Identifying a new owner is too difficult.
• Reality-check pending: The owner may not perceive their own absence.

Intersection 4: Maintenance, community and ownership

Here is the sweet spot where good, democratic governance can thrive: There’s an active community, maintainers and present owners. This is where things can get started.

How do we get from having all the components to an actual governance model? Well, that’s a whole other topic. But having all the ingredients seem necessary… ?

Next steps

While we can think about many ways of understanding how Open Source projects are failing or succeeding, good people are already hard at work. I recommend checking out the new Django Commons project, which is building on the lessons from Jazzband.

This blog post was initially posted by Benjamin Balder Bach on https://overtag.dk