Redis maintenance moves to a core team

Redis has reached a scale at which its creator's daily work is mostly maintenance and review. Salvatore Sanfilippo says that work no longer matches what he wants to do. He is stepping back as maintainer and has asked Yossi Gottlieb and Oran Agra to continue the project. Their response is a proposed core team that can distribute development responsibility beyond a single final decision-maker.

The new leads' announcement is dated June 30, 2020. Sanfilippo explains his decision in his own account. The two statements describe related changes from different positions. One explains why the existing arrangement has become unsuitable for its maintainer, while the other describes how the incoming leads intend to organise the work.

I have used Redis since its release, and I care about the continuity of the project behind its command interface. A succession announcement needs more than a list of names. The useful questions concern who makes decisions, how contributors become effective and which design preferences the successors intend to preserve.

A successful project changes the maintainer's work

Sanfilippo describes a transition from building Redis as an expressive programming project to spending much of his time reviewing proposed changes. The work includes assessing correctness, security and performance. He recognises that this is work Redis now needs, while saying it is not the role he wants to continue performing.

That distinction gives the decision a concrete explanation. The announcement does not say that Redis has stopped requiring maintenance or that its users can do without careful review. It says the person who created the project no longer wants the occupation produced by its growth. Succession makes that mismatch explicit.

He plans to remain involved through the Redis Labs advisory board and as a source of ideas. That is a different role from controlling routine development. The announcement also says he does not want to design the new development arrangement himself. Gottlieb and Agra are left to determine how to work with other contributors.

The separation matters because an outgoing maintainer can otherwise remain the implicit final approver after a formal transfer. Sanfilippo's statement assigns the new arrangement to his successors. Their announcement can therefore be read as their proposal for exercising the responsibility they have been given.

There is no basis in these accounts for describing the change as an abandonment of Redis or the end of its development. The named successors have been asked to maintain it, and the creator describes an ongoing advisory relationship. The daily responsibility is changing, with the reasons for that change stated by the person leaving the role.

The incoming leads describe concentrated authority

Gottlieb and Agra describe the earlier project as largely depending on Sanfilippo's final decision about changes and design tradeoffs. They say he was generally the person who committed changes or merged contributions. Review and integration authority were therefore concentrated even though discussion with the community was open.

This is a useful distinction between participation and responsibility. Many people can propose fixes and discuss a design while one person retains the final integration decision. Increasing the number of participants does not automatically increase the capacity of that final step. The new leads identify the project's scale as a reason to change this arrangement.

Their proposed core team is small and selected for demonstrated familiarity with Redis, contributions and commitment. Itamar Haber is named as the first person to join. More members are planned, but those appointments remain future work in today's announcement. A description of the new team should preserve that provisional status.

Selection through demonstrated work gives the proposal a practical criterion. The announcement does not describe an election of representatives from every user organisation. It describes gathering developers whose work and knowledge support taking responsibility for the project. That is the model being proposed at this point.

It also does not establish that every future decision has a fully specified voting procedure in these two posts. The incoming leads link to a governance model, but their announcement's concrete commitments are the core-team structure and the qualities they seek in its members. Claims about detailed procedures need the corresponding contemporaneous text.

Preserving simplicity still requires decisions

The new leads say they want to preserve Redis's preference for simplicity and for solving a limited set of problems well. That is a design intention. It does not determine the answer to every proposed feature. A project can agree on the word simplicity while disagreeing about the cost of a particular implementation.

A recent example is the 6.0.4 replication decision. That release removes meaningful offsets, an optimisation intended to avoid some full synchronisations. Its notes explicitly say the complexity cost had become too high after multiple bugs, including corruption in chained replication.

This example shows the kind of judgement maintenance includes. The optimisation had a useful goal, but evaluating it required considering failure modes and the team's confidence in understanding them. Preserving a design preference can involve removing a recently added feature when its implementation no longer justifies its cost.

The governance announcement identifies Gottlieb and Agra's previous involvement in the modules API, diskless replicas and other core changes. Their familiarity is therefore relevant to decisions about existing implementation tradeoffs. The announcement supplies that project experience as part of the rationale for the succession.

Their employer and their work on Redis Enterprise are also stated openly in the announcement. Those facts explain part of their technical background. They do not, by themselves, establish either the independence or the failure of the proposed model. The assessment available today concerns the responsibility and participation structure the leads have actually described.

Contribution already begins with a design discussion

The contribution instructions shipped with Redis 6.0.5 provide useful context for the proposed increase in participation. They ask contributors proposing major features or semantic changes to discuss the idea before beginning implementation. Use cases and conceptual fit come before the patch.

This sequence makes review partly an architectural activity. A well-written patch can still implement something the project does not want. Early discussion lets the project assess the proposed behaviour before the contributor invests in an implementation. Sharing that work across maintainers still requires a way to agree on the intended behaviour.

The instructions also distinguish bug reports and detailed feature requests from general support questions. They direct those other questions to the discussion group and point users toward the wider support community. That division is an attempt to preserve the usefulness of the issue queue for the work it is intended to track.

The file is explicit that overload can make issues and pull requests wait a long time. It says delay does not necessarily indicate lack of interest and explains that the project must prioritise. This is part of the practical background for the new leads' wish to make community members more effective contributors.

A core team can distribute review and integration responsibility, but the announcement does not promise that every issue will now receive an immediate answer. The proposed structure creates more places for responsibility to reside. Its effect on waiting times will depend on the people and practices that the team develops.

The contribution file also states the licensing terms for submitted code. Contributions, including patches and fragments sent through discussion, are offered under the BSD licence in the distribution. That existing submission condition gives contributors a concrete rule alongside the process for discussing and reviewing their changes.

The handover is an operating change

The announced transition changes the organisation that evaluates patches, decides tradeoffs and maintains the software people deploy. Those activities are part of the dependency an application takes on when it selects Redis. Their continuity is relevant even when no command changes on the day of the announcement.

I welcome the explicit distinction between creating Redis and maintaining a widely used project. It allows the handover to be assessed on the needs of the work itself. The outgoing maintainer describes the role he is leaving, and the incoming leads describe a team intended to carry that responsibility.

As of today, the next concrete step is forming that team around demonstrated Redis work. Haber is named first, and further appointments remain planned. The contribution instructions already ask for discussion of major semantic changes before implementation, giving the new leads an existing practice through which shared design decisions can begin.