The Hidden Power Dynamics of Open Source

A little over a year ago I attended a programming workshop for women, hosted by an open source organization. I got involved in the organization afterwards and started volunteering my time: planning other workshops, contributing to their blog and resources. I was changing careers at that time, and had heard that contributing to open source would look good on my resume. In fact, it seemed to be a requirement for getting a programming job; everyone I talked to asked me about my GitHub profile and which open source projects I was working on. Besides that, I really enjoyed my work for the organization.

Fast forward a couple of months. I had organized workshops in my free time, was contributing to the blog on a weekly basis, and had given my first conference talk about the organization. At one point, most of my free time was centered around this work. My friends and family didn’t understand why I was doing this, especially since I wasn’t paid. Oftentimes, I had to choose between putting time into the organization or putting time into getting better at coding. I chose the organization. I really loved what I was doing.

About eight months later I was burnt out. I hated the organization, I hated the people, I hated everything else I did, I hated the work I once loved so much, I even hated programming altogether. I even felt a bit like a liar telling people how great the organization was.

What had happened?

Photo CC-BY See-ming Lee, filtered.

As my involvement in the organization increased, I slowly realized that while I was more than welcome to volunteer my time for the organization, I wasn’t allowed to make any suggestions. After all, it was *their* organization, and one of the founders made it very clear that they were the one making decisions. What they seem to have forgotten is that the whole project would have never gotten so big had it not been for the many volunteers who put endless hours of work into this project. Yet the two names which are always mentioned when it comes to praising the project publicly are the names of the two founders. Other people do the work, but usually only the creators get recognized for it. I quickly learned that the organization wasn’t concerned about me and my feelings: what they were mostly concerned about was their project’s reputation.

Today, I don’t feel very welcome and sometimes I think they really don’t want me as a part of their project anymore. I stopped making suggestions since they’ll be rejected anyway. I stopped organizing workshops. I stopped contributing to resources. I stopped spending my time in their Slack channel. The only thing I still do is contribute to their blog. Something that I once loved and which part of me will always love had turned into something toxic for me. And they didn’t care about losing me.

I’m just one of many.

Privilege, Power and Politics

Photo CC-BY Jónatas Luzia, filtered.

It is a common pattern that people open source their projects and ideas in order to let other people work on them for free, making them bigger and better, but still keep the attitude: “You can contribute to my project, but you have no say at all. This is my project, only my ideas count.“

This is plain exploitation and toxic behavior, but it even happens in organizations and projects which are very respected in the community. Despite our mythologies of open source as a flat, accessible, democratic model for software development, the way we lead our open source groups consistently proves otherwise.

Take, for example, the elitist clubs we call “core teams.” Most of these core teams don’t even have rules of what it takes to become a member, and it seems that really all it takes is to have good contacts to other club members, which is a privilege only very few have. Unsurprisingly, it helps if you are a white cis dude. I’m not aware of any core teams that have more than a handful of female members, most don’t have any female members at all, or one or two at most. Usually you have to make technical contributions, but there is no rule on quantity or quality. If you have really good contacts, you may even get in without having made any technical contributions at all. It’s up to the club members whether you are in or out.

To this day, I have not received an answer to my question of what it takes to become a core team member of the organization I worked with, or if there are any kind of rules. I suppose there aren’t. It’s more like “You are my friend, you won’t disagree with me, ergo you can become a member of my core team”.

It’s not only about whether you are a core team member or not: people who are early founders or early members of a project, organization, or core team, are typically privileged over later adopters even as the organization grows and changes. It doesn’t matter how many contributions you have made as a later adopter, the founders and early adopters will stay the stars of the project… after all, *they* built it, not you.

For some open source projects, the leadership structure is at least a bit more defined through software foundations and boards of directors. Unfortunately, this leadership is usually no more transparent, diverse or welcoming. Directors have a lot of power: a few years back it was even the case that a company hired almost the whole board of directors of a certain software foundation in order to gain power over the foundation itself and obtain a large presence at its high-profile conference. Directors decide who gets access to certain mailing list and therefore access to information, or at least the kind of information they decide to make available. They decide whose ideas they want to adopt, who gets a voice. And often, no one really knows what’s going on behind the curtain.

There can be a lot of money involved, sometimes tens of millions of dollars when it comes to larger projects with hundreds of contributors, yet it’s up to a small group of people to decide what they want to spend that money on, who gets a grant and how big that grant is, and who will receive a monetary “gift” for helping organize a conference… even when “officially” the policy is “everybody pays their own ticket.” It’s up to them to decide which projects and initiatives get funding, and therefore have a future.

Directors are often appointed from the top; for others there is at least a voting system, but usually this voting system has very little to do with democracy. Oftentimes there are barely enough nominees to even fill all the board seats, and voting is restricted to only certain members, who are active code, community, or financial contributors. Having the time and money to contribute to a project is again a privilege which not many have. Membership is limited and typically allows only certain people to join. Often club members are asked to nominate people they would like to become members next, with the result of keeping it as exclusive and homogenous as possible. The rules of who gets to be a member and who doesn’t are of course made by the board of directors itself, which basically means the people who have the power, choose the people who get to vote for them. It’s a vicious circle.

The paradox is that a lot of times the non-members actually do more work for the community and software than the members do: a lot of members are just part of the club because it’s prestigious and looks good on their resume. After all, it’s all politics, and politics are corrupt.

How Open Are You Really?

Photo CC-BY Sam Wolff, filtered.

The only part of open source that is really open is the code. Contributions are usually also open: after all, you are free labor, and who doesn’t like someone working for them for free? Of course, contributions are only open to the point where you start making suggestions or trying to bring in your own ideas.

What’s not open at all are memberships, core teams, the ability to vote for people to represent your interests. The open source software world is not a democracy. What is even more concerning is that people are almost forced to start working on open source projects and to expose themselves to these toxic environments in order to get jobs. Recruiters told me that when they encounter candidates who don’t contribute to open source projects, they wonder whether those people are lazy or just not willing to learn.

As it is, we’re going to continue burning out people like I burned out. We have two options: We can either continue not only losing valuable contributors but also seriously harming their mental health, or we can start changing things.

For open source projects, start by acknowledging and thanking your contributors. Be friendly, patient, and kind, and take the time to explain things. These people are willing to volunteer to contribute to your project, so instead of telling them they suck or their ideas are stupid, be a good mentor. Listen to people’s ideas and suggestions. I’m not saying you have to actually do what your contributors suggest, but make an effort to listen to them, acknowledge that you heard them, give their ideas some thought, and if you decide not to execute them, explain your reasons. Open source projects are community efforts. You may be the creator of a project but without the time and effort of many volunteers, your project wouldn’t be as big and successful as it is now. Treat your contributors as friends, not your employees.

What we also really need to start doing is paying people for open source contributions. Having the time to contribute to an open source project for free is a privilege, and after all someone is making money off of these projects, so it’s only fair that we start paying the project contributors, and thereby making the project accessible to people who simply can’t afford to work for free.

For core teams, have clear rules of what it takes to become a core team member. If I know that I have to make 100 commits to a project in order to become a core team member, that is something that I can work towards. I can earn it. If there are no rules or if the only rule is that I have to be friends with other core members, that’s not only unfair but also a privilege which some people may never achieve. Open up memberships and voting rights. Let people register as members, don’t appoint members, and give all members of your project the right to vote. It’s irrelevant whether their contributions are big or small, whether they spend 2 or 20 hours a month working on your project, their work and opinion matters.

A lot of times the only membership category projects have are the so called “developer memberships”, meaning only people who contribute code to the project, can be appointed as members. That is wrong! Don’t categorize your members. There are people who have never submitted a line of code but spend hours working on community related tasks. Your code may be great but it would be nothing without the community around it. Community contributors should be able to become members as well, and they shouldn’t be seen as “second-class” members and be put into their own category just because they don’t contribute code.

And finally, if you’re a recruiter, reconsider if someone’s GitHub profile and their open source contributions are really all that matters. People who don’t contribute to open source are not lazy or not willing to learn. A lot of times they are not privileged enough to be able to spend their time working on projects for free because they have to put in those hours at a paid job in order to make a living. Maybe they also stopped contributing because open source was toxic for them and harming their mental health, and they burned out like I did. No one should be judged just because they don’t contribute to open source, and frankly the reason doesn’t even matter.

What matters is that we at least try to change things, try to be more inclusive, and make open source more open, democratic, accessible, and fair.