It’s hard to be an Open Source project maintainer.
By Salvatore Sanfillipo, developer and maintainer of the free Redis DBMS.
A few months ago, I wrote a maintainer of a single system open source project with a rather large and active community. He wrote that for many years he struggled to maintain his project, but he was experiencing a serious psychological burden. Asked for advice. I replied that I could hardly give advice, but I promised to write a blog post about what I thought about this.
A few weeks passed, I started writing this post several times and stopped, because there was no time to think things through. Now, it seems, I have completed the self-examination of my weaknesses, difficulties, and the desire for freedom. These feelings inevitably embrace the human mind when it concentrates on a task, and for a long time the negative aspect manifests itself. Of course, support for 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 ones (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.
I do not believe in “quick actions”, “quick thinking”, “victory over time” and the like. I do not like the surface world with a lack of concentration and attention, in which we live because of social networks, chat rooms, email and graphics, 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 is trying to say. Could remember the relevant part of the Redis code and after careful consideration of the issue, finally, express their 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, everything changes. Users treat you as an inanimate entity, and the number of messages, questions, requests, suggestions 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 competently answer these questions is growing very slowly. An obvious congestion is created. Most people are too pragmatic in their approach to this problem. We close the ticket if the topstarter has not answered our question for two weeks. Close all tickets with vague wording. And other options for mechanical cleaning flow. But the reality is that it takes time to process feedback. Otherwise, you just pretend that there are few open tickets in the project. It would be nice to have a lot of resources for hiring full-time paid experts to support each Redis subsystem for a full-time job, but in reality this is not feasible.
So what happens? You are starting 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 think that you don’t care about their work. This is a difficult situation. Usually, only critical problems are solved as a result. Everything is ignored, because new functions have not yet become major, and who wants to increase the code base, get even more pull requests and problems? Perhaps you start writing more complicated code than usual. The more complicated the code, the more difficult it is to trace the root cause in the event of a critical error.
Because of the avalanche of requests described above, your work also suddenly changes. Redis became 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 it constantly seems that I myself would have written 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 most are simply written to solve one particular problem. While I always represent the system as a whole, because I have been working on it for many years. But no more time to do it. Thus, big new functions are less organically merged into the main code. What is there to do? Sometimes I just hammer on tickets and pull-requests for a few weeks, because I code or design: this is a job that I really love and enjoy. But this, in turn, increases the psychological pressure, because I ignore everyone.
To do what I love and know how to do well, you have to feel like crap.
There are two problems of long-term work on one project, at least for me.
First, before Redis, I never worked without a break, every working day. I could work for 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, do creative work. And high-level programming is a creative work. Redis himself lived this way for the first two years, that is, when he was developing at maximum speed. Because the total exhaust from my work, when I want to work, more 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 began to receive 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 struggle with myself, which I have been waging for many years. Moreover, I am sure that because of this, the quality and volume of work have decreased, but nothing can be done: this is how things work in this world. I have not found 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 matter, mentally. In the past, I specifically changed the project every six months. For the past ten years, I have been doing the same thing. To keep my sanity, I started sub-projects inside Redis. Once I made a cluster, the other - disk storage (now abandoned), then HyerLogLogs, etc. Basically, these things are useful for the project, but in fact they are something else. But in the end, you always return to the same page with tickets and pull requests, and every day you do the same thing: “The replica is turned off due to a timeout” and so on. Well, let's deal with this again.
I always had some fear of losing technological leadership in a project. Not because I'm not good enough in designing and developing Redis, but because I know that my ways do not coincide with what a significant number of users want, and with what most people in IT consider to be good software. Therefore, it is necessary to constantly balance between what I consider a good design, a set of functions, development speed (slow), project size (minimum) and what I have to give out to most users. Fortunately, there is a percentage of Redis users who are well aware of the Redis-way, so at least from time to time I get a few words of support.
Some people are complete assholes. They are everywhere, it is natural. In my opinion, there are much more good people in programming than in other areas. But there is always a certain percentage of absolute assholes. As the leader of the popular OSS project, you will somehow have to face them. Perhaps this is one of the most stressful things that 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 it will be replaced by something more useful. I would like to have time for other activities. Therefore, sometimes it seems that all my work, in the end, is in vain. We design and write systems, but then new ones will appear. In general, is it possible that at least one applied programmer, and not a theorist with “big ideas”, is able to leave behind some trace? From time to time I think that I had the opportunity to work on big ideas, but I focused on writing software, and not on thinking about it. Therefore, I could not use my potential in this regard. This is the opposite of the impostor syndrome: I'm sorry to have to be more modest.
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 enormous challenges as soon as their project becomes popular. This article is dedicated to them.
A few months ago, I wrote a maintainer of a single system open source project with a rather large and active community. He wrote that for many years he struggled to maintain his project, but he was experiencing a serious psychological burden. Asked for advice. I replied that I could hardly give advice, but I promised to write a blog post about what I thought about this.
A few weeks passed, I started writing this post several times and stopped, because there was no time to think things through. Now, it seems, I have completed the self-examination of my weaknesses, difficulties, and the desire for freedom. These feelings inevitably embrace the human mind when it concentrates on a task, and for a long time the negative aspect manifests itself. Of course, support for 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 ones (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 actions”, “quick thinking”, “victory over time” and the like. I do not like the surface world with a lack of concentration and attention, in which we live because of social networks, chat rooms, email and graphics, 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 is trying to say. Could remember the relevant part of the Redis code and after careful consideration of the issue, finally, express their 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, everything changes. Users treat you as an inanimate entity, and the number of messages, questions, requests, suggestions 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 competently answer these questions is growing very slowly. An obvious congestion is created. Most people are too pragmatic in their approach to this problem. We close the ticket if the topstarter has not answered our question for two weeks. Close all tickets with vague wording. And other options for mechanical cleaning flow. But the reality is that it takes time to process feedback. Otherwise, you just pretend that there are few open tickets in the project. It would be nice to have a lot of resources for hiring full-time paid experts to support each Redis subsystem for a full-time job, but in reality this is not feasible.
So what happens? You are starting 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 think that you don’t care about their work. This is a difficult situation. Usually, only critical problems are solved as a result. Everything is ignored, because new functions have not yet become major, and who wants to increase the code base, get even more pull requests and problems? Perhaps you start writing more complicated code than usual. The more complicated the code, the more difficult it is to trace the root cause in the event of a critical error.
Role change
Because of the avalanche of requests described above, your work also suddenly changes. Redis became 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 it constantly seems that I myself would have written 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 most are simply written to solve one particular problem. While I always represent the system as a whole, because I have been working on it for many years. But no more time to do it. Thus, big new functions are less organically merged into the main code. What is there to do? Sometimes I just hammer on tickets and pull-requests for a few weeks, because I code or design: this is a job that I really love and enjoy. But this, in turn, increases the psychological pressure, because I ignore everyone.
To do what I love and know how to do well, you have to feel like crap.
Time
There are two problems of long-term work on one project, at least for me.
First, before Redis, I never worked without a break, every working day. I could work for 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, do creative work. And high-level programming is a creative work. Redis himself lived this way for the first two years, that is, when he was developing at maximum speed. Because the total exhaust from my work, when I want to work, more 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 began to receive 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 struggle with myself, which I have been waging for many years. Moreover, I am sure that because of this, the quality and volume of work have decreased, but nothing can be done: this is how things work in this world. I have not found 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 matter, mentally. In the past, I specifically changed the project every six months. For the past ten years, I have been doing the same thing. To keep my sanity, I started sub-projects inside Redis. Once I made a cluster, the other - disk storage (now abandoned), then HyerLogLogs, etc. Basically, these things are useful for the project, but in fact they are something else. But in the end, you always return to the same page with tickets and pull requests, and every day you do the same thing: “The replica is turned off due to a timeout” and so on. Well, let's deal with this again.
Fear
I always had some fear of losing technological leadership in a project. Not because I'm not good enough in designing and developing Redis, but because I know that my ways do not coincide with what a significant number of users want, and with what most people in IT consider to be good software. Therefore, it is necessary to constantly balance between what I consider a good design, a set of functions, development speed (slow), project size (minimum) and what I have to give out to most users. Fortunately, there is a percentage of Redis users who are well aware of the Redis-way, so at least from time to time I get a few words of support.
Disagreement
Some people are complete assholes. They are everywhere, it is natural. In my opinion, there are much more good people in programming than in other areas. But there is always a certain percentage of absolute assholes. As the leader of the popular OSS project, you will somehow have to face them. Perhaps this is one of the most stressful things that I dealt with during the development of Redis.
Futility
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 it will be replaced by something more useful. I would like to have time for other activities. Therefore, sometimes it seems that all my work, in the end, is in vain. We design and write systems, but then new ones will appear. In general, is it possible that at least one applied programmer, and not a theorist with “big ideas”, is able to leave behind some trace? From time to time I think that I had the opportunity to work on big ideas, but I focused on writing software, and not on thinking about it. Therefore, I could not use my potential in this regard. This is the opposite of the impostor syndrome: I'm sorry to have to be more modest.
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 enormous challenges as soon as their project becomes popular. This article is dedicated to them.
Source: https://habr.com/ru/post/452332/
All Articles