Russian Aggression Must Stop

Politics in your FOSS project? It's more likely than you think!


One common concern raised on various tech forums is that of politics in open source projects (and also software projects in general). Often this discourse rears its head when a FOSS project adopts a code of conduct (we'll get to that) or participates in inclusion and diversity initiatives. Often this is followed by calls to "keep politics out of open source projects" and to focus on "merit and code" rather than "pushing political agendas".

Obviously this discourse is not exclusive to open source projects and the surrounding communities, essentially the same discussion takes place regarding almost all types of media. However, as a software developer I'll focus on the FOSS politics topic. Draw parallels to other media as you please.

The meaning of politics

If we are to talk about politics in FOSS projects, I think it's worthwhile to first establish exactly what we are talking about. It's easy to throw around short and simple slogans, but I think we should look beyond them and establish a common vocabulary first.

Let's start by looking at the sentiment of these people when they are concerned about "politics". Generally, these commentators seem to ascribe the following properties to "politics":

  • It originates from outside and is part of some larger collective
  • It is not desirable and is somehow disruptive
  • It runs counter to some idea of merit

The implicit assumption is that before this "politics" is injected into a FOSS project, the project exists in a state of apoliticism.

This on its own is kind of vague and the implicit assumption is actually quite big, especially considering that Free and Open Source Software as an idea is quite heavily steeped in politics.

As a counterpoint, I am going to offer a broad definition of politics as a tool that we can use to maybe figure out what is going on here. I shall define "politics" thusly:

Politics is the process of dividing resources and deciding who gets to decide how those resources are divided. Resources being anything in limited supply (time, manpower, physical items, etc).

It is quite a broad definition, but I think it's generally acceptable definition that people can get behind without too much controversy and which encompasses political activity.

Now, what's the interplay between this definition and the prior properties given to the word "politics"? Well, it's quite easy to see that they aren't actually really that compatible. Maintaining an internal status quo is something that fits into the general description while running counter to the perception that politics comes from outside or that it's disruptive and undesirable. Open source projects also make constant resource allocation and governance decisions, such as deciding which issues and features are prioritized and who is granted maintainer permissions to the code base, even if that decision is the decision to not grant maintainer permissions to anybody.

So, the problem here seems to be related to specifics. There seems to be some kind political activity which is considered innocuous and ordinary and the kind of political activity which is undesirable and disruptive.

What are Codes of Conduct anyway?

"Code of Conduct" (often shortened as "CoC") is a string of words that seems to cause a lot of consternation in some people. Adoption of these codes of conduct is seen as text-book political infiltration by these commentators and plenty of them champion for their removal in places where they are adopted.

But why? Let us investigate.

As our first action, let's actually break down what a code of conduct is and what it aims to do. Wikipedia has a concise definition of a Code of Conduct:

A code of conduct is a set of rules outlining the norms, rules, and responsibilities or proper practices of an individual party or an organization.

Okay, that seems… incredibly ordinary? We could have derived that definition from just semantic analysis: a code of conduct is a set of rules (a code) for proper behavior (conduct) in a group. Basically every place you could visit either online or physically has either an explicit or an implicit set of rules, even the places that claim to eschew rules and moderation.

In the absence of an explicit code that governs behavior, the community will establish some sort of a set of implicit norms of behavior and the community establishes means to defy deviations from that norm. If the community has no means to directly eject "deviants", they can still attempt to do so by making the environment uninhabitable to those who would defy their norms.

It's worth keeping in mind though that most places aren't anywhere close to that "wild". Basically every website where you can interact with other people has a set of rules, even those websites where you go to complain about codes of conduct. If a website has a set of "posting rules" for comments, nobody bats an eye because that is incredibly normal. And if a FOSS project would establish a set of rules (and remembers to call them just "Rules") that ban things like spamming in the project spaces or insulting people, basically nobody would kick up any kind of dirt.

So, what's the deal with codes of conduct then? What has got people so up in arms when these get brought up? Well, let's have a look at one that draws a lot of ire: the Contributor Covenant. Let's start from the top and see what's up:

We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.

We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.

Wait a moment… I think I've just connected the dots.

The "real" meaning of "politics"

People who complain about "politics" in FOSS projects are obviously not complaining about politics in the general, this we have already established. Neither are they complaining about having norms. What they have a problem with are specific politics and specific norms.

I think it's time to drop the facade. What this comes down to is that some people feel that there are certain types of people that they want to keep out. This is why certain codes of conduct draw so much criticism whereas others don't. Codes of conduct like the Contributor Covenant are quite specific about diversity and inclusion, which just so happen to be topics that the anti-CoC crowd also seems to oppose.

So, "keep politics out" is just an attempt to say something quite specific without saying it out loud. It's a "politically correct" way to oppose the idea that we should allow equal participation in these projects to people who may represent some type of a social minority. Which specific kind of minority they oppose changes as time goes on and societal expectations change, opposing transgender people in particular seems to be "in vogue" at the time of writing, but obviously not the only ongoing campaign.

Ironically, many of these people who claim to want to keep projects "apolitical" go on to say that they do not care about things like gender and skin color. But they will vehemently oppose rules that require people to conduct themselves appropriately regardless of these factors. Quite possibly because if these rules are left vague and unspecified, it opens the door to establishing new implicit norms that would allow kicking out people you irrationally hate.

The fall of empires - playing the long game

I wrote my bachelor's thesis in university about a topic I found quite important. That being the life-cycle of a open source project. That particular thesis included researching how open source projects keep going and what results in their death and potential rebirth. People, as it turns out, is the primary determinant.

Open source projects often start out more or less as the work of one person. Exceptions of course apply, but if you think of the mass of projects out there it's a fairly safe bet to make that a randomly selected project originated from one person. This one person is a de facto dictator of the project while they are the only person working on it and sometimes that status persists after other people start contributing to the project. The term "benevolent dictator for life" still applies to many major open source projects, such as the GNU project and the Linux kernel.

However, dictatorships, even benevolent ones, come with a built-in flaw: dictators will eventually die. This means that projects that are heavily centralized to one person will eventually be thrown into disarray if the singular maintainer disappears one day without a continuation plan in place. Additionally, a single maintainer can only do so much to advance the project by themselves. Luckily, open source projects are naturally built for collaboration and even in the worst case scenario it's often possible to resurrect a dead open source project because the code most likely doesn't disappear.

Collaboration between multiple people ensures better efficiency because certain tasks can be done in parallel without duplication of work and establishing a community-based maintainer process ensures that the project's bus factor (the risk of significant number of key people disappearing, or getting run over by a bus) goes down. But this all requires people.

So, if you really want to play the long game in open source, you must consider the following aspects: developer attrition and potential contributor base.

Attrition is something that happens in projects of all kinds. It is the process of people leaving the project due to any reason. Some will leave the project through the natural process of illness and death, some because they have become too busy with the rest of their lives and some people don't get along with others. The key thing is to reduce excess attrition by making people already in the project feel like they want to continue working on the project. If they are getting insulted and harassed in project spaces, they'll be more likely to leave. And this is something that we, unsurprisingly, consider to be bad.

You also need to consider the potential of finding new contributors to the project. For this you must project an image of being welcoming to having new contributors in the first place. If the project spaces look like toxic pools of waste to outsiders, they may have little interest in participating in those spaces. Different people have different expectations, you'd want to be optimizing the project in order to accommodate, not everyone's, but most people's expectations.

Some may now be, sarcastically or otherwise, asking how these considerations apply to exceptionally talented people in these projects who behave poorly in project spaces but produce very good code. The simplest answer is to consider the utilitarian calculus: while individuals have certain merits, the collective merit of the project should also be considered. If one talented individual imposes a lower cap for collective merit, then the utilitarian calculus says to kick the talented jerk out.

So, does this necessitate that all projects must somehow achieve perfectly minimal attrition and maximal appeal to the highest number of potential contributors, all other considerations be damned? Obviously not. Some projects are not aiming for a high number of contributors and long-term success, so demanding them to act that way isn't really feasible. However, there are projects that are striving for long-term success and projects that we are relying on and which would benefit from a critical consideration of improving on these factors. So, when these projects take steps to be more welcoming and to retain more contributors, this is objectively a good thing for all of us.


This post has been long time coming. Some of these ideas have been bouncing around in my head for quite a while now, but some of the recent happenings in the open source world made me finally sit down and write them down.

Some people as they read this may feel offended by how I framed the motivations of people who oppose so-called "politics" in open source projects because they themselves are not transphobes and whatnot. And I have no doubt that those people also exist, but I would really suggest to those people to really think critically what consequences they are hoping to avoid or bring about by carrying the flag of "no politics in FOSS projects" banner. It is quite easy to be misled out there and be fooled into championing causes not your own, on that one I can speak from experience.

And regarding codes of conduct, I would highly recommend checking out the Contributor Covenant FAQ, because it goes over some of the same ideas about what the effect of having a code of conduct actually does and what it does not.

If there's one goal I am hoping to achieve with this post, it is that people wouldn't so easily fall for the "no politics" gambit that certain highly-political actors seem to play. Politics is all around us and our decision to keep things the same is just as political as our decision to make a change. Much more valuable conversations can be had about the consequences of keeping things the same versus changing them would be.

>> Home