liv 💖

My name's Liv and I'm a programmer of some sort? I work on Jekyll and Rust, as well as a bit of other stuff.

You can probably reach me on GitHub or via email.

Socialism and Open Source

First of all, let me satisfy the people who clicked on this article just to afterwards angrily mention me on Twitter: Yes, this post is not actually about an implementation of socialism in open source. Sorry to disappoint you, it’s called viral marketing.

Rather, this post is about a socialist analysis of open source structures and processes, and what we can learn and incorporate from socialist thought into open source itself.

So, at its base level, what is open source? Before we can have a look at open source, let’s look at what came before it: The Free Software movement. Basically, a couple of people were fed up with software being non-free, as in, sometimes costing money, but most times not being able to view the software’s source code. This is problematic in the sense that you, as a user, don’t know what you’re executing on your own computer. To combat this, the GNU Project was started by deep breath Richard Stallman in 1983, which later kicked off the establishment of the Free Software Foundation.

Free software (capitalizing the Free because it means more than just not costing money) was guaranteed to be Free by including a license known as the GNU General Public License (GPL), which states that users of the software should be able to freely run, inspect (= read the source code) and modify the software. If the software is modified and redistributed, it must be under the same license, the changes must be stated and the source must be disclosed. A lot of things were published under this license, including the Linux kernel, all GNU software and other software that is extremely popular nowadays.

Open Source naturally evolved from that. A lot of Free software licenses are also open source licenses, as they propose a requirement of publicly making source code available. The open source movement really took off with the introduction of GitHub for easily hosting and collaborating on Git repositories. Nowadays, it’s technically easier than ever to start contributing to open source, as a lot of software has been open sourced, and as our infrastructure relies on more open source software than ever. However, notice I said technically. There are still a couple of major roadblocks in order to truly empower EVERYONE to contribute to open source, and in order to identify and work on those, it’s useful to look at things from a socialist perspective.

If we look at a Git repository (or an equivalent version control system) in its most basic form, there seems to be a lot of anarchy - everyone can push to the main remote at any time (unless there’s a merge conflict), it’s even possible to completely replace the remote tree. This can work in situations where every developer knows what they’re working on and can even be useful for rapid iteration, but in most cases this quickly falls apart as there is no actual structure to maintain things in the long run. Instead, what most smaller open source projects nowadays look like is a clear hierarchical structure: There’s usually one maintainer or a group of maintainers who hold absolute control over the source code, which encompasses everything from merging in changes by contributors to releasing new versions. This approach is obviously flawed, as there is no good in handing over authority to a single person(s). But before we go on, let’s look at some larger projects:

Many large open source projects further split this hierarchy into smaller classes. Sometimes they’re called contributors, sometimes collaborators, sometimes members. Some projects incorporate a (working) group structure, which is good, but usually still reports to a higher authority, such as a steering group. Sometimes, even, there’s a board which represents people or companies with financial stakes in the project.

Now, what is there to learn from socialism and communism that can be applied to open source? Obviously, a lot of the basic principles are simply meant for a different context, so they can’t be applied. But one of the most important foundations of communism can be applied: The working class owns the means of production. This can be transposed fairly easily to the context of open source: Those who work on the software own the software and its means of development. It’s important to define a term used here, “work” does not only mean code contributions. Any contributions that move a project forward, be it code, documentation, marketing, or even bug reports, are valid contributions and should be counted equally. This plays into another central principle of marxism: “From each according to his ability, to each according to his needs”, as first said by Karl Marx in his critique of the Gotha Program. Every contributor should be treated equally, no matter their ability, their time investment, their social standing, et cetera. This is, in my opinion, where the classic hierarchical model of open source projects falls apart: You’re gating newcomers from being able to be recognized for their work, and putting that judgement into the hands of a few privileged.

Okay, so contributors should own the project and everyone should be treated equally. Doesn’t this sound a bit too much like a pipe dream? And yeah, sure, I’m not saying that this is the easiest thing to implement, especially in larger open source projects, but there’s a couple ones that have made some pretty good progress in working towards this:

  • Choo is giving every person making contributions write access to some repositories
  • Some NodeSchool workshoppers (for example how-to-npm are giving every contributor write access and also generally maintaining a very liberal maintainership status

As for treating everyone equally, it works when you plan it from the very start. Adopt and enforce a good Code of Conduct, know harassment when you see it, and don’t moderate only by yourself, then things should work out. It’s much harder when you have to implement it in an existing project, due to existing, potentially offensive structures. If a project isn’t willing to remove those structures when they’re pointed out, it’s probably not worth trying in the first place.

There’s a manifesto called OPEN open source which implements a couple of ideas that I think are very good, mainly centered around giving contributors write access. However, I don’t think this goes far enough. Here’s some points that I’d like to see in an open source project:

  • There’s no maintainers, the contributors hold complete power over all decisions
  • Contributing to the project in whichever way grants you contributor status
  • Higher-level decisions are made by establishing some form of consensus (via a representative system if need be)
  • Optionally, contributors can form specialized teams that do not place anywhere else in the hierarchy
  • A strong Code of Conduct should be implemented and enforced aggressively

I think this could be implemented into an existing project, however, what I think is lacking is the “contributing in whichever way” part. Due to the nature of the tools we use (e.g. GitHub), it’s currently hard to recognize non-code contributions, meaning that existing systems are biased towards code contributions. This is a thing that we, as a collective of open source contributors, need to get better at (and at the same time, the tooling needs to change).

Call it “open open open source” or just call it empowering the people who actually build open source software, these are the points I think we can extract from socialist thought into open source governance and organization.

(By the way, I wouldn’t even describe the ideas outlined in this post as radical per se, I think they kind of encompass what free software originally meant by “open source”)