Maintainer's Woe - A rebuttal to the suffering of Open Source project maintainers

TL;DR

Maintainers should step away from their work to take care of themselves. Nothing will happen to either them or their projects if they do. Everything will be fine. But it is hard to step away, because maintainers are people with people feelings.

NOTE: There will be a movie spoiler, although this movie was released in 1999 so the spoilers are all over the internet anyway

Some Background

Hi! My name is Nisha, and I am the maintainer of an Open Source project called Tern. I get paid to maintain this project by my employer, although the project belongs to the Linux Foundation. I am also a non-white woman in tech and a parent. This is relevant to the subject of this article.

I’ve only been a maintainer for two years, and Tern isn’t what I would call “popular”, but over that time there have been some talks, discussions on twitter, and blog posts by some influential people in the Open Source community about their experiences with burnout. I am glad that folks are talking about burnout. I am by no means dismissing these experiences.

However, I do take issue with the way these discussions are being presented - mostly in the form of self worship, complete with an all-green GitHub activity monitor, by maintainers who are almost always men. Part of the reason why I am writing this is because in one of these discussions, I asked this question: What’s keeping maintainers from stepping away from their project to do other stuff?

The answer I got was: That presupposes that maintainers don’t want to see their projects grow and flourish

Hmm…

Does this mean that unless project maintainers give the demands of the people who interact with them the highest of priorities, higher than their own well being, their projects will not grow and flourish? I’m not sure as I haven’t been a project maintainer for very long. Two years is really not that long. Projects take over a decade to mature. However, I began to wonder if perhaps this notion giving your open source project your all even if it kills you actually has its roots in the power and glory of being the maintainer of a popular Open Source project. What’s not to love about CEOs of tech startups showering praise, requests to give keynotes at conferences, random people on the internet begging for pearls of wisdom, press time, resume building and selfies with the top leaders and thinkers in tech?

In the movie, The Devil’s Advocate (Rated R so don’t watch with your kids), a skillful lawyer takes a job under a very influential boss. He overworks himself, justifies defending people who are obviously evil, and neglects his stay-at-home wife. Why? Because he is told constantly that he’s a rockstar by his boss and the elite he hangs out with. I love Keanu Reeves in this movie. He portrays a character who repeatedly questions what he sees and hears but dismisses those feelings because he believes he is a rockstar. Spoiler: the boss is the devil, who often says, “Vanity is my favorite sin”.

Everyone is a little vain and everyone likes to feel important. But being an Open Source project maintainer sets up a power dynamic that is like speed to the vain in your brain. There is a reason why a sole project maintainer is called its Benevolent Dictator For Life. This power dynamic has produced some jerks, but it has also produced some folks who are driven to justify the adulation showered on them. After all, your Open Source project is not popular for nothing. In the words of the maintainer who wrote the blog post I linked to: “Redis became popular because I supposedly am able to design and write software”. So what about the other Open Source projects out there that are not well written (we make fun of them all the time but folks still use them).

I don’t mean to pick on the maintainers of Redis. I just want to highlight that these complaints about “maintainer’s virtue” tend to come with some self-serving bias, that the maintainers are inherent rockstars and the burnout is a byproduct of being a rockstar.

Now, I did say that being a non-white female parent was relevant here. I have to multitask between taking care of an Open Source community (which I am very grateful to do while getting paid to do it) and taking care of my family. I’ve had to force myself to set and enforce boundaries. As a result, I have found myself not really understanding what the fuss is about (hence asking the question). I am not swimming in the same water. I am more or less an unknown in the community and constantly struggle to generate interest in the project I maintain, but I think I have a sustainable work-life balance. By the way, I am writing this on a weekend, but these are my own opinions which are somewhat loosely bound to my maintainership duties at best.

If you’re interested in comparing GitHub green charts, go ahead and take a look at mine. It’ mostly grey. But I do get to spend breaks with my family. I’m good with that.

I am the maintainer of Tern. However, it is not the maintainer of me. I really don’t want to be Keanu Reeves in that movie :).

I hope what I write here will change the perspective on the situation a little bit. Perhaps my own vanity is showing. It looks like I have found the solution, but in reality, I find myself at the edge quite often. The grey parts in the chart are places where I back away from the edge, only to come back to it again because it’s thrilling and I love getting the attention and the cookies.

The Trainwreck part of Open Source

In the beginning, there was a Guy (almost always a guy) who had a cool idea. He set to work, working day and night (but mostly night), to create the Thing. And it was good. So good that his friends wanted to work on it too. And so they worked on the Thing, but mostly Guy, because the friends really didn’t understand what was going on. But Guy knew. Guy knows all. And Thing became cooler! So cool that a company started using it. It worked well! But it would be so much better if it could do this one extra thing. So the company people asked Guy (probably filing an issue on GitHub) to do the extra thing. This extra thing seemed a good idea to add. So Guy and Friends worked, but mostly Guy, day and night (but mostly night), to add Extra Thing to Thing. And it worked! And the company people were so happy. They sang praises and spread the word to other company people. The other company people tried Thing. And it worked! But it would be so much better if it could do this other extra thing. So the company people asked Guy to do Other Extra Thing. Guy thought maybe this Other Extra Thing was not a good idea and he told the people so. The people said “Boo! We thought you were all powerful Guy! Turns out, you’re just a pleb!”. Guy thought, “I’m not a pleb!”. And so he worked, maybe with Friends but mostly by himself, day and night, and this time all day and night, for many days, until he finally got Other Extra Thing to work. And it was good! The company people were so happy. They sang praises and told Guy he was amazing and his Thing was beautiful. But they kept asking for More Extra Things. And by this time Friends grew bored and went to do something else. Guy was bored too, but what could he do? Thing needed him! Company people needed him! He must work to add More Extra Things. And Still More Extra things! And on and on until Guy could do no more.

Well, that was a sad story. Or not, depending on your sense of humor. But I think this is the archetypical maintainer story for projects that become popular. From the sidelines it looks like the maintainers unwittingly dug themselves into a hole that they couldn’t get out of. And, like the judgy losers we are, we can clearly see all the things they didn’t do, especially the part where they didn’t say ‘NO’. But could they say ‘NO’? I’ve been in and know people who have been in abusive relationships enough to know that attention and flattery are what hook you in first. We say that the projects we create are just hobbies, but really, we would like them to be a reflection of our skills and intuition. It’s a wonderful feeling when someone submits a pull request to your project. It indicates to you that they see worth in your work. I was so excited when I received the first dump of pull requests to Tern. But I was also overwhelmed. I didn’t have a CI/CD pipeline in place. Most of my unit tests were broken. The contributors didn’t even bother to check to see if their code worked. And Tern is a baby project, not the giant monstrosities that other Open Source projects are.

Speaking of abusive relationships - the abuse happens when there is retaliation for not doing something the abuser wants, such as withdrawal of attention, finances or freedom. There is also some emotional triggering by the abuser to get their partner to do what they want. That looks like someone who is using a project demanding their issue be given the top most priority, or else the project is not worth their time, which is very precious indeed. For example, someone filed an issue against Tern a while ago. I decided not to get to it until I had a CI/CD pipeline in place. I was working to fix some other part of the codebase. The person replied, in essence, that the project was not worth the time to go through 3 install steps rather than one. It stung my ego and I have no doubt that it was meant to do that. I had my manager talk me down before I responded. This is a very mild case though. Perhaps others won’t see it the way I did. But it is far worse elsewhere.

So yes, the environment in which Open Source projects live tends to be abusive. It takes a lot of emotional load to step off a ledge some rando on the internet put you in. Want to know why only 5% of Open Source contributors are women? Well, this is it. It’s something underrepresented groups in tech have had to deal with throughout their careers. It doesn’t help when a maintainer continues to perpetuate the “rockstar” persona of themselves. It just gives them and their followers permission to yell at some other Open Source project maintainer. You can’t stop all the jerks. It is the internet after all. But you can encourage other maintainers and leaders to call out the jerks. It would mean working to spend less time nursing your own bruised ego, and acknowledge that you’re not alone in experiencing this abuse.

The Installed Dictators

I am one of those maintainers that got hired by my employer to work on an Open Source project. So yes, I work for the man. This is the case with most Open Source projects these days. Red Hat is the king of this kind of maintainership. All the Google projects used to be closed-source and now require Contributor License Agreements (CLAs) if you want to contribute to them. Many Cloud Native companies originate Open Source projects that have maintainers that are paid by the company. So this kind of maintainership is more the norm these days. As one of these installed BDFLs, I am measured by the project’s metrics. It’s my incentive to get folks interested in the project - a job that I do not particularly relish but one I know I have to do. It doesn’t mean I am not passionate about it. I don’t do this job half-assed. But I also treat it like a job, which means I step away from it at the end of a workday to do other stuff. To top it off, I work from home, so this boundary needs to be doubly enforced. I hope I got the point across that I, and many others like me, are not working day and night on our projects and having that balance does not necessarily affect the success of the project.

Not that there isn’t room for abuse here. It just looks more familiar. You go to an office and work, you take your work home, you don’t pay attention to your home or family and work, and you do this day in and day out. And maybe you do this because you want to succeed in your career or you want that promotion. It’s no different from an Open Source maintainer working by themselves. The job consumes you until you have nothing. Tern’s metrics are not great, but they were 0 two years ago. That was with the times I took off to take care of my child and to be with them during their breaks. Not everyone has this kind of work environment. I didn’t have it before. When my child was younger, they would get febrile seizures when they had a temperature. I was always ready to head out the door. My leads and managers knew this. But once, my lead expected that I would take care of an issue at work rather than take off for a medical emergency. He threatened to write me up. I told him to go ahead and do so as my child was way more important to me than his issue. Really, he had no on-call plan. He just assumed his employees were available on demand. Perhaps many project maintainers who are installed by the company they work for feel this pressure to perform. It takes a lot of effort to enforce boundaries in this environment. I could have very well lost my job there, but luckily, I had support from my skip level manager and some other senior engineers.

The Tools of Oppression

I’ve always felt that Open Source maintainership as a function sets up an automatic power imbalance. The maintainer is the keeper of the project. Contributors submit PRs for their review and acceptance. Maintainers bless the PRs with LGTM (looks good to me), and the PRs are merged into the fold. For projects with governance, there is a roundtable of elders, to whom proposals are submitted. The elders discuss amongst themselves. Even if the event is open, most of the jargon is indecipherable to a layman. They might as well be speaking the language of the gods. To those who are the keepers of Open Source projects, it must be a heady feeling to be in this position. UC Berkley psychologist, Dacher Keltner, wrote a book called The Power Paradox which talks about how being in a position of power affects the human psyche. Needless to say, it brings out the worst in us. I am, at this stage in the project’s growth, at the bottom, with a couple of active contributors but me mostly doing the heavy lifting. And even then, I have a tendency to abuse my merging privileges. I’m sure other maintainers do this. Usually, on the way to the top, what is foremost in mind is getting the code to work.

Incidentally, the book also talks about how leaders gain power. It’s not something that is taken, but something that is given by the community. The power that mantainers wield is ultimately given to them by others on the journey to the top - the peers who concurred the idea was good, the folks who did things like code cleanup, backlog scrubbing, some level of self-enforcement or enforcement over the PRs coming in, that one person who made the cute project logo, or those other people who contributed to documentation. Although, most of the work is done by the maintainer, what makes the project “popular” is the community supporting the maintainer’s goals. Nevertheless, this community is completely ignored when the same maintainer talks about burnout.

Perhaps it would make sense to document everything that is in your head, have a growth ladder to get to the maintainership level and think about governance to choose a successor. But it is very hard to give up control. I’d liken this to when parents have to relinquish control of their children once they become independent. As a mom of a growing child, I find myself fighting an internal battle between whether to let them go or hold on to them for a little longer. My greatest fear is that they will get hurt. I know what mistakes my child will make before hand because, well, they are my child, but also because I’ve watched them make those same mistakes before but in different scenarios. I can either hold on to them and continue to nag at them until they learn, or I can let them make the mistake, feel the consequences of the mistake, and learn on their own. The latter is definitely more painful for me. But it is probably better for them. I think a maintainer’s control over their Open Source project works in a similar way. Maintainers have seen the project grow. We know where all the technical debt is. We know exactly what commit caused that weird regression. Surely, we would be the only ones who can take the project to greater heights. If anyone else were to take over, the project will surely fail. Two feelings are at play here: fear and pride. Fear is easy to talk about. Pride is not. If we don’t want our work to consume us, we will have to practice some humility and understand that our skills and intuition are not unique to us and we are really not that important to a project as we think we are.

Enforcing Boundaries and Letting Go

In the process of explaining why I think the burnout problem with Open Source maintainers partly stems from our own ego and insecurity, I have revealed a few personal things about myself and my experiences as a maintainer, a parent, an engineer and a woman. I want to point out that I am not unique in these experiences. Anyone who has been at the short end of the power dynamic stick has struggled with setting and enforcing boundaries. This entails walking a fine line between being ostracized and subjecting themselves to harm. So others may have a different take on how best to walk that line. However, I feel that most Open Source project maintainers are not in a position where failure to comply with what a community member or corporate member wants will result in job loss or a stunted career. So I think it is easier for maintainers to enforce boundaries without fear of retaliation. One nice thing about Open Source is that you will always find someone who agrees with you and who will connect you to new opportunities. So with that in mind, here are my tips on enforcing boundaries and letting go as an open source maintainer.

  1. Realize that you are not special. There are other folks who are as good if not better than you are and they would maintain the thing you created just fine.
  2. Realize that the project does not define you and you are a person in your own right.
  3. Realize that the project doesn’t belong to you and is probably an entity all by itself by the time it reaches maturity.
  4. Realize that Open Source is not a business, even though many businesses use it to make money. If you want to make money, start a business based on the Open Source project you created.
  5. Realize that the people who interact with your project are not customers but collaborators. Encourage and enable them to work with you.
  6. Realize that the project might fail. And that’s totally OK. It’s not your fault.
  7. Realize that you don’t have all the time in the world. Use your time wisely.

Once you understand the above, take the next steps by:

  1. Taking time off to take care of yourself
  2. Practice humility
  3. Practice empathy towards others
  4. Check back with the community you have created (but don’t get sucked in)
  5. Mentor a newbie contributor
  6. Contribute to a knowledge base with lessons learned
  7. Reach out to communities you are not active in (I did mention most OSS maintainers are men, right?)

PS: I don’t have comments enabled, but you can reach me on Twitter if you would like to have a discussion. I hope we can figure it out together :).

References