It's hard to be an Open Source project maintainer

Original author: Salvatore Sanfilippo
  • Transfer
Posted by Salvatore Sanfilippo, developer and maintainer of the free Redis DBMS

A few months ago, the maintainer of a single open source system project with a rather large and active community wrote to me. He wrote that for many years he has been struggling to support his project, but is experiencing serious psychological stress. I asked for advice. I replied that I was hardly able to give advice, but I promised to write a blog post about what I think about this.

Several weeks passed, I started writing this post several times and stopped because I did not have time to think it over thoroughly. Now, it seems, I have completed the self-analysis of my weaknesses, difficulties and desire for freedom. These feelings inevitably embrace the human mind when it concentrates on some task, and a negative aspect manifests itself for a long time. Of course, supporting the Open Source project also brings a lot of joy and pleasure. The last ten years of my professional life will certainly be remembered for a long time. These are good years, although not the best (it was even more fun during the launch). But here I will focus on the negative side. Just keep in mind that there are positive points.

Avalanche of requests

I do not believe in “quick action”, “quick thinking”, “victory over time” and the like. I don’t like the surface world with the lack of concentration and attention in which we live because of social networks, chat rooms, email and a schedule full of events. In the early years of Redis, I still had a lot of time. When the letter arrived, I could calmly concentrate on what the author was trying to say. I could recall the relevant part of the Redis code and, after carefully considering the issue, finally express my real thoughts. I believe that this is how most people should work, no matter what their job is.

When a software project reaches popularity, like Redis, and communication between people is so simplified, as in modern social tools, then everything changes. Users treat you as an inanimate entity, and the number of messages, questions, requests, offers grows exponentially. But at the same time in the Redis community (although it seems to me that this is a common problem), the number of people who are able to expertly answer these questions is growing very slowly. Obvious congestion is created. Most people are too pragmatic about this problem. We close the ticket if the top starter has not answered our question within two weeks. Close all tickets with vague wordings. And other options for mechanical cleaning of the stream. But the reality is that it takes time to process reviews well. Otherwise, you simply pretend that the project has few open tickets. It would be nice to have a lot of resources for hiring paid fulltime experts to support each Redis subsystem for a full day, but in reality this is not feasible.

So what is going on? You begin to prioritize more and more: what to consider and what not. And you feel like a piece of shit, ignoring so many questions and so many people, and contributors believe that you do not care about their work. This is a difficult situation. Usually, in the end, only critical problems are solved in the end. Everything new is ignored, since new functions have not yet become basic, and who wants to increase the code base, get even more pull requests and problems? Perhaps you are starting to write more confusing code than usual. The more confusing the code, the more difficult it is to track the root cause in the event of a critical error.

Role change

Due to the avalanche of requests described above, your work is also suddenly changing. Redis has become popular because I kind of know how to design and write code. And now, instead, I mainly deal with problem solving and pull requests. And constantly it seems that I myself would write better code than in these pull requests. Although sometimes the code is better than I could do myself, because there are better programmers in the Redis community. But mostjust written to solve one specific problem. While I always represent the system as a whole, because I have been working on it for many years. But there’s no more time to do this. Thus, large new functions are less organically integrated into the main code. What is there to do? Sometimes I just hammer on tickets and pull requests for several weeks, because I code or design: this is a work that I really love and enjoy. But this, in turn, increases psychological pressure, because I ignore everyone.

To do what I love and know how to do well, you have to feel like shit.


There are two problems of long work on one project, at least for me.

Firstly, before Redis, I never worked without a break, every working day. I could work a week, stop for two, then work for a month, disappear for two months. Is always. People need to recharge, get new energy and ideas, get creative. And high-level programming is creative work. Redis itself lived like this for the first two years, that is, when it developed at maximum speed. Because the total exhaust from my work when I want to work is greater than when I have to work every day in a sustainable way.

When I worked alone, I could afford a free schedule. As soon as I started getting money from Redis Labs, my ethics no longer allowed this. I had to force myself to work on a normal schedule. This is a serious fight with myself, which I have been waging for many years. Moreover, I am sure that because of this the quality and volume of work has decreased, but there is nothing to be done: everything is arranged in this world. I did not find a way to solve this problem. I could tell Redis Labs that I want to return to my old schedule, but it makes no sense, because at the moment I am “reporting” to the community, and not to the company.

Another problem is that a lot of work on one project is also a difficult thing, mentally. In the past, I specifically changed the project every six months. I’ve been doing the same thing for ten years now. To keep my mind, I started subprojects inside Redis. Once I made a cluster, another - disk storage (now abandoned), then HyerLogLogs, etc. Basically, these things are useful for the project, but in essence they are something else. But in the end, you always return to the same page with tickets and pull requests and do the same thing every day: "The replica is disconnected due to a timeout" and so on. Well, let's get this over again.


I always had some fear of losing technological leadership in the project. Not because I'm not good at designing and developing Redis, but because I know that my paths do not match what a large number of users want, and what most people in IT consider to be good software. Therefore, I have to constantly balance between what I consider to be a good design, a set of functions, development speed (slow), project size (minimal), and what I should give out to most users. Fortunately, there is a percentage of Redis users who understand Redis-way very well, so at least I get a few words of support from time to time.


Some people are complete jerks. They are everywhere, it’s natural. In my opinion, there are a lot more good people in programming than in other areas. But there is always some percentage of absolute assholes. As the leader of the popular OSS project, you will have to deal with them anyway. Perhaps this is one of the most stressful things I dealt with during the development of Redis.


Sometimes it seems to me that even the most excellent software will never last forever, as a masterpiece of literature. Please note that this is not because of its quality, but as a side effect of its utilitarian function ... It is useful in practice. That is why something more useful will come to replace it. I would like to have time for other classes. Therefore, sometimes it seems that all my work is, in the end, in vain. We design and write systems, but then new ones will appear. In general, is at least one applied programmer, and not a theorist with "big ideas," capable of leaving any kind of trace? From time to time, I think I had the opportunity to work on big ideas, but I focused on writing the software, rather than thinking about it. Therefore, I could not use my potential in this regard.

Nevertheless, I was able to work for many years, doing what I really loved, which gave me friends, recognition, money. This is not to say that it was a bad deal. However, I fully understand that people face huge challenges as soon as their project becomes popular. This article is dedicated to them.

Also popular now: