The struggles of an open source maintainer
I don&#x27;t maintain anything as big as Redis, but I&#x27;ve faced many similar problems all the same and I think I have an approach which makes it palatable. I wrote about my approach at length here:<p><a href="https:&#x2F;&#x2F;drewdevault.com&#x2F;2018&#x2F;06&#x2F;01&#x2F;How-I-maintain-FOSS-projects.html" rel="nofollow">https:&#x2F;&#x2F;drewdevault.com&#x2F;2018&#x2F;06&#x2F;01&#x2F;How-I-maintain-FOSS-proje...</a><p>But the main thing is that almost all bug reports, feature requests, and so on, get sent to &#x2F;dev&#x2F;null. Users who care about a problem are expected to work on that problem themselves. In the case of software like Redis, pretty much everyone reporting a bug is also qualified to fix that bug, so it works particularly well.<p>Then I focus only on helping new contributors get their bearings and making regular contributors happy and comfortable with their work on the project. So far this approach has been very successful for me - I don&#x27;t get burned out, and neither do my contributors, and we have happy, healthy communities where people work at a pace which suits them best and aren&#x27;t stressed or overwhelmed.<p>Sure, lots of feature requests and bug reports get neglected, but I think the net result is still a very positive impact on the project. The occasional drive-by bug submitter provides far less value to the project as someone who writes even one patch. Focusing on keeping the people who create the most value happy makes for a more productive project and a better end result. Some people are put out by the fact that their bug report, feature request, etc goes unanswered, but I can quickly put the guilt out of my mind by reminding myself that ignoring them is doing a benefit to the project. And in practice, I generally have time to give people some words of encouragement and a nudge in the right direction towards writing a patch without burning myself out.