How to become a Redis maintainer one contribution at a time

Madelyn Olson may not be the most well-known of open source developers, but chances are you’ve benefited from her work. Olson is a new maintainer for and a longtime contributor to Redis, one of the world’s most popular databases and regularly touted by developers as the most loved. You’ve used Redis when on Twitter, GitHub, Instagram, Airbnb, or if you use many other products. And if you’ve used Redis, you’re a direct beneficiary of the “small fixes all over the place” Olson contributes to make Redis great.

Five years ago, however, Olson wasn’t thinking about Redis. She was thinking about her university graduation. The story of how she went from student to AWS engineer to open source contributor is fascinating, and one that offers insights into how the best developers balance corporate and community hats, and why corporate and community interests align much more often than we might think.

Thinking about upstream contributions

Though Redis has historically been difficult for enterprises to manage, it is comparatively straightforward to develop, partly due to a compact code base. According to Olson, “If you compare Redis to other databases like PostgreSQL, it probably has a tenth the amount of code.”

This relatively small code base made it easier for Redis founder Salvatore Sanfilippo to bear the brunt of maintaining the project solo for a long time. It also made it possible for AWS to make significant changes that alter the Redis code, and to maintain them as part of the Amazon ElastiCache service. Olson and her manager, however, realized that it would be even better to “upstream” our changes so we wouldn’t have to maintain the code at all.

In doing so, would we be open sourcing essential intellectual property? Not really. “Much of the work we do with Redis is to make it operationally more stable,” Olson explains. Our customers look to AWS to manage Redis for them, to provision nodes—and more—via our APIs. Thus, it’s in our best interest—and everyone else’s—for AWS to help make Redis as stable and performant as possible, so that customers trust the underlying database, driving even more demand to AWS to manage it at scale.

This thinking really started with TLS, which Olson described as the “tipping point” for AWS’ involvement in Redis.

TLS tipping point

Historically, Redis didn’t support encryption. With ElastiCache, AWS made setting up transport layer security (TLS) in Redis easy, but we had to maintain this functionality ourselves. Sanfilippo had been reluctant to implement SSL or its successor, TLS, in Redis because it introduced complexity into an engine that he’d worked hard to keep relatively simple. When AWS’ Olson submitted a pull request (PR) to introduce a CPU-efficient approach to TLS, focused on keeping a more secure Redis “cheap per operation done,” Sanfilippo remained unconvinced.

Olson’s pull request, however, prodded others within the Redis community, such as Yossi Gottlieb and Oran Arga of Redis Labs, to consider her approach and to try to achieve the CPU efficiency of Olson’s PR while retaining the simple elegance of Redis. The result? PR #6236 (Abstract Connections I/O API & TLS Support), which Sanfilippo later described as “an SSL patch that was actually a pleasure to read: I could never have imagined this happening.” Sanfilippo also praised Olson for writing the initial implementation, saying, “that was also very useful to understand how to imagine the v2 design and implement it.”

Up until this point, Olson related, Sanfilippo had “completely ignored us,” but with the proposed TLS patch “he really engaged.” Sanfilippo’s response prompted Olson and her manager to decide that she could dedicate a quarter of her time to open sourcing code for Redis.

As work started on Redis 6, Olson began reviewing Sanfilippo’s code, submitting PRs to fix bugs or make other changes. They weren’t big changes. “Normally I’m the one making small fixes all over the place,” she says. But her consistent efforts over years built up trust with Sanfilippo—trust that translated into her being able to better prepare others’ larger code contributions to pass muster with Sanfilippo. (“I don’t have enough context, I haven’t looked at this recently,” he’d say, “Hey, Maddy, can you take a look at this?”)

Becoming part of the Redis family

And “look” she did. And code. She wasn’t angling for any particular glory, however. Sanfilippo was the sole maintainer of Redis. “There was no pathway to me becoming a maintainer,” Olson says. “I was not expecting it. I was just trying to be helpful and that ended up paying off.”

One key way that Olson helped, in addition to code contributions, was to improve communication within the Redis community. Olson set up a Slack channel for the primary Redis contributors, giving them a way to discuss changes to Redis and to communicate them to Sanfilippo. “When I started, no one talked to each other in the Redis community. If you submitted a pull request to Redis, just Salvatore commented, no one else did. And with the introduction of the Slack channel, that seemed to be the start of much more community-driven development,” Olson says.

When Sanfilippo announced he was moving on from Redis, Olson was asked to become one of five Redis maintainers—an honor, and a testament to the trust she has earned on the project.

While Olson has been recognized for the consistency and scope of her Redis contributions over time, other AWS engineers have also become increasingly active with Redis. Functionality such as failover commands (assigning roles to primaries and replicas in one command) had been implemented in ElastiCache, and the thinking inside AWS increasingly defaulted to open sourcing such functionality to make Redis better for everyone and more easily maintained by AWS.

Wearing many hats

So does Olson contribute to Redis for herself, for AWS, or for Redis? The answer is “all three,” but perhaps not quite how one might think. Stemming in part from the guiding principles for The Apache Software Foundation, open source contributors never represent their employers. Not really. “We firmly believe in hats. Your role at the ASF is one assigned to you personally, and is bestowed on you by your peers. It is not tied to your job or current employer or company.”

This is not to say one’s employment has no bearing on their contributions. Olson says, for example, that working for AWS puts her in a strong position to gain feedback from customers and then turn that feedback into PRs to improve Redis, which is what happened with client-side caching in Redis 6. Such changes benefit AWS, of course, but the benefits extend to all.

“It’s beneficial for everyone if AWS can make Redis a better product, if we can help it solve more use cases, if we can make it more robust,” Olson explains. “There are still a lot of people who don’t want to use Redis for one reason or another. So the more people for whom we can solve their use cases, the more end user problems we can solve, the more that grows the pie for everyone. That doesn’t just help us, it helps our customers and it helps other people using Redis. At some point in the future, those customers might come and use ElastiCache or they might not. So helping Redis as the community is good for us.”

But what if Olson’s manager insisted on Olson using her position as maintainer to advance code that helped AWS but not Redis? This isn’t really an issue, Olson explains, because what’s good for AWS should be whatever is best for Redis. “I’m not a maintainer on behalf of AWS, I’m a maintainer on behalf of myself,” she says. “Yes, I wear multiple ‘hats,’ but I would push back against my manager [in such a scenario]. We should only be contributing stuff that’s good for the community and not just good for AWS. That aligns well with how we want to contribute, anyway.”

Now let’s step back for a moment. I’ve highlighted Olson here for her contributions to Redis, but the best thing in this story is that there are actually multiple Olsons involved. Redis is not the work of one great person (Sanfilippo), or even five great people (the newly minted maintainers). Redis is a confluence of a wide variety of people, employed by different companies, some of which may directly compete. This is how open source is supposed to work, and with Redis, it’s working extraordinarily well.