
Redis Core Team Update - itamarhaber
https://redislabs.com/blog/redis-core-team-update/
======
antirez
Both Madelyn and Zhao are _terrific_ programmers. In case you wonder, they are
not random people put there for reasons, like for example since Madelyn is a
woman so there was some pressure to add she. She deserves this 100% and is one
of the top Redis contributors of the last times, with deep technical knowledge
in basically every aspect of Redis. The same for Zhao, he is simply
impressive, can track bugs about complex conditions like almost nobody can.
I'm happy to see them aboard. Btw they were both effectively part of the
informal "core team" that was forming spontaneously in the recent times.

~~~
the-dude
As a non-native English speaker, I am always thrown off by the word
_terrific_. It sounds horrible to me, and apparently it can also mean _very
bad_.

[https://www.merriam-webster.com/dictionary/terrific](https://www.merriam-
webster.com/dictionary/terrific)

~~~
xeromal
Awesome is a similar word. It used to mean awe-inspiring, but now can simply
describe an enjoyable bowel movement. lol

~~~
bryanlarsen
The original meaning of awful used to be awe-inspiring too. Awesome came about
as a replacement when awful started acquiring significant negative
connotations.

------
derefr
Interesting move, putting “SLA-driven” infrastructure engineers (i.e. people
working at public clouds to deliver Redis-as-a-Service solutions) in charge of
the project. (Not just these two from AWS and Alibaba Cloud, but the rest
being from Redis Labs.)

It seems like, for one reason or another (Redis Labs because they want to sell
their “core plus proprietary modules” service; the clouds because they want to
push you to use their other products for use-cases that fit them better), all
the new leadership has reason to want to _not_ add any more developer-facing
features to Redis Core. I expect the Redis Core you see right now, is the same
Redis Core we’ll have 10 years from now, client-API wise. Redis, as a USP, is
“done.”

Unless, that is, some third-party comes in with their own polished feature PR,
and pushes really hard for it. In other words, Redis is kind of moving to the
Linux kernel model, where “new use-case out of nowhere” features come in
mostly not from internal development, but rather from external contributors
petitioning the core-maintainership priesthood with reasons their patch should
be upstreamed.

Either way, there’ll certainly continue to be plenty of ops-staff-facing
innovations, bug-fixes and polish. That’s what gets this new core team up in
the morning. I’m sure people running Redis in production are happy about that.

~~~
imron
> I’m sure people running Redis in production are happy about that.

I sympathize with the main points you were making, but surely ‘people running
Redis in production’ are the core use case for Redis, so ultimately this move
seems good for the project’s overall direction.

~~~
derefr
Zooming out, there are two kinds of production infra software:

1\. the kind that devops people directly see a need (usually a scaling need)
to integrate it into a stack of _existing production software_ ; where this
integration may or may not require additional development-time work (i.e.
connector glue code in the business layer), but is either way an _ops use-
case_. Examples: any caching layer, any message queue.

2\. the kind that developers integrate with in order to get the _semantic
guarantees_ that particular kind of software offers; and then ops people are
left "holding the bag", needing to deploy that same software (or something
compatible with its wire protocol) in production because that's what the
business logic was written to depend on. Examples: most databases; object
storage; map-reduce workload engines.

Usually, it's pretty clear which bucket a piece of infra software falls
into—either it's developers or ops people that suggest it as a solution, but
rarely is a piece of software equally loved by both.

But Redis straddles the line between these usually-clear clusters of software.
It can be a metrics-reactive "patch" to a running system to get it to scale
better; but it can _also_ be a development-time foundation for business logic,
or a dependency of a library where it was a dev-time foundation for _its_
business logic (e.g. any "background worker" library.)

In other words, Redis Core as a project, serves two masters: it must _both_ be

1\. a stable, scale-multiplying, worry-free daemon you can easily toss into
your existing legacy infra;

2\. a feature-rich "durable data-structure server", allowing developers to
obviate the keeping of durable state in the app layer itself.

The new leadership certainly will care a lot about use-case 1.

I'm pretty sure, though, that the previous leadership (i.e. Antirez) cared
almost exclusively about use-case 2—making developers' lives easier by taking
durable-in-memory-state-management code they were writing, and replacing it
with calls to Redis. That's why we didn't see TLS support and so forth for so
long. Redis wasn't being _built_ for ops people; it was being built for
developers. Code that went into complex deploy-time use-cases, was only ever
added _by Antirez_ as a consequence of systems developed for Redis now
_depending_ on running it in production. (E.g. you don't _scale_ Redis into a
cluster; you _develop for_ the sharding semantics of Redis Cluster, and so
therefore you must deploy Redis Cluster. You _can_ "upgrade to" Redis Cluster
after-the-fact, but it's far harder than just writing your code to be
"cluster-safe" at the start. It's idiomatically a _development-time choice_
you're supposed to be making, knowing the eventual "scaling goal" of your
system.)

Yes, the rest of the core team—mostly ops-focused engineers—gradually accrued
around Antirez. That's why many of these ops-time use-cases _did_ start
getting addressed.

I'm mostly worried that now, with Antrirez out of the picture, the team is
unbalanced in the other direction: there's no one on the core team pushing the
"developer productivity" side of the story.

To me, that laser focus on developer productivity was what made Redis
consistently the infrastructure component I would most want to integrate to
solve a problem, if it offered a solution to that problem. I knew that "the
Redis approach" would always involve just a library import, a connection URL
instantiation, and one or two atomic Redis command calls; whereas other
libraries might require me to write delegate modules, serializers, attach to
special listener modes, etc. _And_ I always knew I could just open redis-cli
and prototype out those same commands against my local zero-initial-config-
required Redis server; where other infra might require me to fiddle with
everything from setting my own compile-time flags, to JVM memory-management,
to Docker image volume mounting, etc.

I really just hope that the new leadership retains enough of the spirit
Antirez has been injecting into Redis, that they'll reject PRs that solve ops
use-cases but come _at the expense of_ developer productivity (e.g. moving to
entirely-async command execution, and then deprecating the text-based Redis
wire protocol because it's hard to integrate its parsing into a Jepsen-correct
threaded execution engine, or something like that.) Such features wouldn't
hurt _cloud deployments_ for _existing Redis users_ at all, but they'd sure
scare away new developers from finding new ways to replace business logic with
Redis.

~~~
imron
This follow up comment was insightful. Thanks.

------
swagonomixxx
What will be interesting to see is how Redis fares without Antirez.

He was the heart and soul of the project.

It also makes me think, what would Linux be when Linus decides to step away? I
kind of don't want to think about it.

Thank you to Antirez for all your hard work on Redis.

~~~
johnfn
One of my favorite bits of trivia: What would Git be like if Linus stepped
away? Oh yeah, he stepped away after a few months and Junio Hamano continued
running it for the next 15 years[1] (!!).

[1]:
[https://github.com/git/git/graphs/contributors](https://github.com/git/git/graphs/contributors)

~~~
sdesol
I'm not sure what your point is. Antirez has been contributing to redis for
over 11 years and accounts for 80% of all its code churn.

[https://imgur.com/RnlzECa](https://imgur.com/RnlzECa)

In just the last 90 days, he accounted for 50% of the code that is being
changed in redis. I'm currently indexing the Git repository, as I'm curious to
see the impact Linus had before he left, but I don't think Linus leaving, is
anything like antirez leaving.

Sorry if this post comes of confrontational, as that is not its intention. I
just don't understand what comparison you are trying to make.

~~~
quietbritishjim
I think they were replying to a different bit of the parent comment than you
seem to think:

> ... what would Linux be when Linus decides to step away?

~~~
swagonomixxx
I think it was a fair reply. Linus's contributions to Git, while basically
100% of the project initially, were not sustained over as long as Antirez's
contributions to Redis.

------
seemslegit
As with Yossi and Oran vis-a-vis Redis labs, it is not clear whether Madelyn
and Zhao are in the core team in their personal capacities or as
representatives of Amazon and Alibaba respectively, we know that Redis labs
reserves the right to name replacements for Yossi and Oran, is the same true
for Madelyn and Zhao and their current employers ?

------
yjftsjthsd-h
So that at least looks like good news. Hope they can make this transition work
smoothly!

