The Hidden Struggles of Maintaining a Popular Open‑Source Project

A few months ago an open‑source project maintainer wrote to antirez describing the mental burden of sustaining a project for years and seeking advice.

antirez replied that he could not give direct advice but would write a blog post to share his thoughts.

He admits that maintaining an open‑source project brings joy but also has a dark side.

Flood Effect

When Redis was small, there was enough time to read and thoughtfully reply to emails. As the project grew popular, the volume of messages, issues, pull requests, and suggestions increased exponentially, overwhelming the limited number of qualified people who could handle them.

Many try to solve this the wrong way: closing issues after two weeks without a reply, closing ambiguous issues, or marking all mailing‑list messages as read.

Properly handling community feedback requires sufficient time; otherwise, it feels like pretending the project has no unresolved problems. Hiring full‑time staff for each subsystem works but is hard to achieve.

Prioritizing critical problems over new, non‑core items is essential, yet this decision is complex and can cause anxiety and the perception of indifference from contributors.

Role Change

After Redis became popular, the maintainer’s work shifted to reviewing PRs and issues. While some contributors perform better, most contributions remain average, merely solving given problems.

Designing Redis feels like treating it as a whole, but expertise in one area leaves little time for other tasks.

The maintainer’s solution is to take weeks off from PRs and issues to focus on programming or design, the activities he truly enjoys, though this creates additional psychological pressure.

Time

Working on a single project for long periods presents two problems. First, the maintainer never experienced a regular work‑day schedule before Redis, alternating weeks of work with weeks off, which helped recharge creativity.

Receiving payment for Redis forced a normal schedule, leading to struggle and a feeling of under‑achievement.

Second, mentally, extensive work on the same project is complex. Previously, the maintainer switched projects every six months; now, after ten years, he stays on Redis, deploying sub‑projects to retain creativity.

Fear

The maintainer fears losing technical leadership of Redis, not because of personal inadequacy, but due to a mismatch between his design philosophy, feature set, development speed, project scale, and user expectations.

Fortunately, a portion of Redis users understand his approach, providing occasional comfort.

Friction

Even though most programmers are good, some troublesome individuals exist. As a leader of a popular open‑source project, dealing with such people is one of the most stressful aspects.

Futility

The maintainer believes software is great but not timeless like a centuries‑old book; it has side effects and will eventually be replaced by more useful software, leading to feelings of futility.

He questions whether people who only write code without contemplating the larger creative vision can truly create new landmarks.

Overall, he has been able to do what he loves for many years, gaining friends, recognition, and money, which is not a bad deal. However, he fully understands that once a project becomes popular, people struggle to make a living from it; this article is written for them.