Off-the-shelf governance models for small FOSS projects?

A one-person open source project with a governance model, is that ridiculous? In this blog post I want to convince you it isn’t, and it could be key to solving widespread problems in the FOSS (Free and Open Source Software) ecosystem.

The problems

The free software movement is successful in many ways, but there are still annoying aspects to it. There are many situations where I feel like there is no shortage of people with goodwill, but we still fail to work together.

As a user of open source software, I often need to make a pick from a bunch of roughly equivalent solutions. Why do I need to choose between KeePass, KeePassX and KeePassXC? Why so many Linux distributions? Why all those open source navigation apps? If only their authors could work together to offer one real alternative to Google Maps, as functional and well rounded!

As a contributor to FOSS projects, I struggle with getting my changes accepted. My proposals routinely go unreviewed for months, if they ever get reviewed at all. When I consider contributing a change, I need to factor in this risk, so I regularly give up because the backlog of open pull requests left to rot is a red flag. I could imagine helping with maintenance of some of my dependencies, but there is often no way to even apply for that in the first place.

As a maintainer, I struggle to attract new contributors to my projects. If I do get some contributions, their authors do not stick around much. I get tired of this maintenance work. I feel lonely and depressed.

Why is it that way? There are surely many factors, but to me, a crucial one is cultural. We don’t really have the culture of setting up structures for team work. When I start a new open source project, I primarily think about the use case I want to support. I want the tool to be really good: easy to use, reliable, architecturally sound, well tested. I make it open source because I want to make it maximally useful to people. I don’t have a plan for its sustainability, because I just assume that if my tool is sufficiently useful to enough people, contributors will somehow come and help out - isn’t that the point of open source? Look, I have even added a CODE_OF_CONDUCT.md document to my repository, so I’m a nice and polite guy that people should be able to work with!

Open source is full of people like me. I have been trained to solve technical problems, and to consider human problems as basically not in my department. To build communities around the projects I am involved in, I essentially hope that we’ll just bond over our common love for good software and that the rest will follow. This is the core of the problem I want to tackle: this assumption that team work will just succeed on its own if people come to help. In my experience it’s really not the case.

It’s not a ground-breaking thesis either. The essay “The tyranny of structurelessness” by Jo Freeman did such a great job (in 1970!) at explaining why formal roles and decision procedures are helpful to make teams function properly, even at a small scale.

A lot of established open source projects know that, and have indeed formal governance models that shape the day-to-day decisions, onboarding processes and other procedures. The FOSS Governance Collection contains plenty of examples of tried and tested models which were likely instrumental in the popularity of the projects which adopted them.

The problem is: none of those governance models seem tailored to small projects that just got published and don’t have a community yet. As someone who just started a small FOSS project, I can’t start requiring “three +1 votes from members of the Project Management Committee” to publish a release - I am on my own! So I don’t choose a governance model yet and just let the forge platform shape the permissions and interactions in my project.

The default governance model that forges push us into

In the absence of a conscious choice of governance model, the default workflows defined by the forge (such as GitHub or GitLab) are the de-facto governance model of the project. Let’s see what that looks like.

When I publish a new open source project on GitHub, the repository gets created under my own user account by default. I am the one and only “Owner” of the repository. I am able to add “Collaborators” in the settings. They do not have the same privileges as I have: for instance, they are not able to add other collaborators themselves. The list of collaborators on a repository is also not displayed publicly, nor is it possible to apply to become a collaborator via GitHub. If someone wants to help maintain my project, the options they have are fishing for my email address, or communicate by opening an “Issue”. Isn’t that a great metaphor? The fact that they offer their help is treated as an issue by the platform!

To be able to add co-owners, one needs to create an organization and tranfer the ownership of the repository to that organization. It does give more governance options, with the ability to create teams and assign rather granular permissions to them, but I am mostly left on my own to define those teams (I need to take the initiative to set them up) and it still does not let people apply to join them.

To summarize, in GitHub’s default governance model, the project has one leader and they are there to stay. It’s called implicit feudalism and corresponds rather well to the notion of Benevolent Dictator For Life (BDFL) used in the free software movement. While some projects make a conscious decision to adopt that model, it isn’t very helpful to grow a community and avoid maintainer burnout.

Needless to say, the default settings offered by forges have a huge impact on the overall ecosystem. I would be interested in working on improving those defaults, and Forgejo feels like a fitting project where to explore interventions around this problem.

Licenses and the “just fork it” mentality

Another reason for the lack of interest in governance models is, I think, the belief that an open source license is the only real governance model a project needs. It goes like this: if you are not happy with the way the project is run, you can “just fork it” and you have a copy that you can run the way you want. If you just stick to what most licenses say, publishing an open source project isn’t a promise to review and integrate other people’s changes in it, nor to onboard anyone on the team. Obviously, advising people to fork a project if they’re unhappy isn’t exactly ideal for community building. There are other issues with this stance, which are by now well known, such as the importance of certain assets (domain names, coordinates in package repositories…) that cannot be retained in a fork, or the difficulty for users to keep an overview of the fork landscape of a project.

Still, one nice achievement of the open source movement is that we have a common understanding of the importance of licenses. We understand that assigning licenses to software projects is crucial to enable their adoption, both for users and contributors. Many forge platforms will explicitly encourage you to add one when creating a project.

Can we grow the same sort of awareness for governance models? Can we get to a stage where most open source developers would have the reflex of systematically adding a governance model to their projects when publishing them, even for the tiniest, most insignificant libraries? The first step towards that goal is to convince you, reader, that it would be a worthwhile pursuit.

When I told a friend that I had adopted a governance model for a project I had just published and where I was the only contributor, their reaction was to ask: “what is there to govern?”. I think that’s a pretty natural reaction! So here’s my response. I wanted to:

• make it clear to prospective contributors that they are welcome to get involved, by showing a clear path to co-maintainership,
• make it clear to myself how I hope to integrate people in the project and make myself eventually redundant, so that I keep this as a goal even at the initial stage of the project where I have a lot of enthusiasm for working on it and taking responsibility for things;
• set up a basis for collective decision making before the need for it arises, because it’s a lot easier that way.

The main problem is: the existing FOSS governance models are designed for mature projects and it feels like a lot of effort to design one from scratch. Why should I reinvent the wheel? My project isn’t that special, and I am not a governance specialist so I wish I could adopt an off-the-shelf model. Just like I am not a copyright lawyer and wouldn’t want to write a new license for every project I publish.

Off-the-shelf governance models?

So this is what I have been dreaming of lately: when you create a git repository on a forge platform, it nudges you towards adopting a governance model for your project, and proposes a selection of well-known ones that you can add in one click to the repository as a GOVERNANCE.md file. Just like it nudges you to adopt a license. Ideally, it could also set up the appropriate teams and apply other configuration settings implied by the governance model you picked. Unlike licenses, which are mostly meant to be copied verbatim and not modified, the governance model would be meant to be a starter template to be adapted to the needs of the project as it grows (by specifying how the governance model can be changed). An additional benefit of having such well-known starter packs is that it would help prospective users and contributors quickly grasp the general spirit of a governance model, without having to read it all (just like we have built a common understanding of what the MIT or GPL licenses are and we don’t need to dissect them every time we interact with a project licensed as such).

What could this initial offering of governance models look like? Here are ideas of a few options:

• the BDFL model. There is one owner of the project, who does not intend to share ownership with others, but accepts contributions via pull requests, and may give limited privileges to some contributors for them to help out with certain tasks (such as issue triage and pull request reviewing). Although I am not enthusiastic about this model, it still makes sense to offer it as an option, given that it’s the current default. As a potential contributor, I would already find it useful to know that a project has consciously adopted this model.
• the “just fork it” model. The owner has no interest or capacity for integrating changes from others. The recommended way to improve this software is to fork it. Projects which adopt this model could disable pull requests and/or issues on the repository to make this clearer. This is a model that can make sense in a lot of cases: for instance, when academics publish code alongside an article to make their research reproducible, they rarely have the intention to develop a thriving community of contrbutors around the repository. Just like a research article is generally meant to be a final artifact that does not evolve after publication, so is often the associated code. Seen as a governance model, this is quite nihilistic, but it would still be worth stating, because it would help potential users and contributors better understand the intent of the authors and avoid wasting time trying to contribute to it directly.
• what I would call the Kanthaus model. Kanthaus is a collective I have been involved in for a few years. It has a governance model (called “Constitution”) with a position system defining how people can transition between the three roles (“Visitor”, “Volunteer”, “Member”). This system makes it possible for newcomers to have a clear pathway towards reaching the same rights and responsibilities as people who have originally founded the collective (“Member” status). The same sort of tiered system can be used in open source projects, and this is what I have been experimenting in Mergiraf, with small tweaks to make the model still applicable to a one-person team. Adopting a model like this makes sense when the creator of the project does not intend to retain full control over it indefinitely, and instead wants it to form a common that others will be able to steer and maintain.
• a wiki-style model, where write permissions to the code-base are given in a very lax way. Instead of avoiding the introduction of bugs by requiring reviews to code changes, bugs are remediated by reverting problematic changes after they were committed. I have heard of this model but I am not sure where it is used (if at all). It might be the right choice in certain cases.
• other established governance models, such as the Apache way, which could be used from the start if the project is already supported by a group of actors. Perhaps some can also be adapted to be made relevant for single project authors, still priming the project towards a governance fit for a mature project.

Surely there could be many more options! Let me know which ones you’d recommend. I am particularly interested in those which are already applicable right at the project start and help grow a contributor community. I have been thinking that surely, such templates must already exist out there, but so far I couldn’t find that. What I am aware of is:

• the FOSS Governance Collection, listing governance documents from mature projects, most of which are tailored to their particular situations and are not designed to be reused in generic FOSS projects,
• the CommunityRule website, a “governance toolkit for great communities” (so, targeting a broader audience than the FOSS ecosystem). It does come with “templates”, but those templates are not formulated in a way that can be applied to FOSS projects directly,
• articles such as “Understanding open source governance models” by Red Hat employees, which categorize governance models in broad families. That is helpful to get an overview of the possibilities, but again, it does not directly give me a viable template that I can apply to my project,
• established governance models like the Apache way or CNCF’s governance templates, which are designed to be applied in a specific institutional context: projects which have already reached a certain size and are affiliated to the corresponding foundations.

Let me also know if you think this dream is misguided or ill-founded. And if you are interested in working together on such a collection of reusable governance models, I would be thrilled to hear that. Comments can be posted as replies to this Mastodon post.

The "You wouldn't publish a repo with a license" meme was generated on the awesome youwouldntsteala.website.