What does an open source maintainer do after burnout?

Maintaining an open source project is far different from coding, which is a problem if coding is what you love

Contributor, InfoWorld |

What does an open source maintainer do after burnout? — Thinkstock

Redis founder Salvatore Sanfilippo hadn’t run up against term limits. No one was demanding he stop leading the project, and he wasn’t struggling to keep Redis innovating. But on June 30, 2020, Sanfilippo announced the “end of the Redis adventure” for him. Effective immediately, he relinquished his lead maintainer role, saying “I don’t really know what there is for me in my future,” except to “just look around... without doing too many things.”

Despite (or, rather, because of) being the face of Redis for over 10 years, Sanfilippo was done. He needed a break. While Sanfilippo’s departure only affects the Redis community, the reasons have far broader implications.

So let’s talk about open source maintainers, and how Sanfilippo’s example translates into best practices within the enterprise.

The other kind of ‘low code’

If you’re familiar with how open source communities work, you can skip ahead, because you likely already know this: Maintainers don’t write much code. As the GitHub Open Source Guide says, “If you maintain an open source project that a lot of people use, you may have noticed you’re coding less and responding to issues more.” Instead of writing code, you’re communicating with would-be contributors to help them shape their code to be useful for the project, or you’re documenting processes and vision, or any number of other things.

But coding…? Not so much.

Talking with the maintainer for the popular OBS project, founder (and maintainer) Jim Bailey told me that one of the major headaches of maintaining a project is that the incoming software often “isn’t very good.” As he explained, “It can be very difficult to review people’s code, because you want everything to be consistent in your project.... There’s a lot of bad code that people try to contribute.”

Of course not all the code is bad, and sometimes it’s “bad” because it’s somewhat narrow and self-centered. As Bailey put it:

People only contribute stuff that’s useful for them, almost exclusively. They usually don’t contribute code that is useful to everybody, though sometimes they do…. [M]ost of the time, maybe 80 percent of the time, whenever you get a pull request for something, a request to merge code, it’s almost always [for their narrow self-interest].”

Which translates to lots of time spent talking with these contributors, trying to rehabilitate their code. According to Bailey, this has led to burnout multiple times for him. He’s currently dealing with a backlog of 115 pull requests that he needs to review, but he keeps getting pulled into writing code. “I have so much work to do and I just need to focus on one thing and I need to not code. I need to focus on maintaining the project rather than coding the project…. It burns you out really, really easily.”

Which brings us back to Sanfilippo.

‘I never wanted to be a software maintainer’

As Sanfilippo said in an interview, he didn’t set out to up-end the cozy world of relational databases. He just couldn’t cost-effectively build a real-time analytics engine using MySQL, so he broke all the rules of databases to deliver an in-memory database that has grown to become the most loved and top 10 most popular database on earth.

Which, it turns out, is a problem, as Sanfilippo writes:

Redis is, incredibly, one of the main parts of so many things. And year after year my work changed from building this thing to making sure that it was also as useful as possible, as reliable as possible. And in recent years, what I do every day changed so much that most of my attention is spent in checking what other developers tell me about the Redis code, how to improve it, the changes it requires to be more correct or faster or more secure. However I never wanted to be a software maintainer.

But isn’t maintaining a project the apex of open source software development? Not for Sanfilippo, who “write[s] code in order to express myself…. [M]y first goal is to make something that is, in some way, beautiful. In essence, I would rather be remembered as a bad artist than a good programmer.” See the conflict? He continues: “Now I’m asked more and more... to express myself less and to maintain the project more. And this is indeed exactly what Redis needs right now. But this is not what I want to do.”

Speaking of the intersection of open source software development and cloud services, open source luminary Tim Bray has said, “The qualities that make people great at carving high-value software out of nothingness aren’t necessarily the ones that make them good at operations.” The same can be said of maintaining open source projects. Just because you’re an amazing software developer doesn’t mean you’ll be a great software maintainer, and vice versa.

Perhaps more pertinently to the Sanfilippo example, developers may be good at both, yet not be interested in both. (By all accounts Sanfilippo has been a great maintainer, though he’s the first to say he could become a bottleneck because he liked to do much of the work himself rather than relying on others.)

Sanfilippo has given open source communities a great example of how to think about “career” progression within these projects, but the same principle applies within enterprises. Some developers will thrive as managers (of people or of their code), but not all. As such, we need more companies to carve out non-management tracks for their best engineers, so developers can progress their career without leaving the code they love. The alternative is unhappy developers burning out and checking out. As Sanfilippo shows, there’s a better way.

The other kind of ‘low code’

‘I never wanted to be a software maintainer’

Read more about open source: