Valkey Is Rapidly Overtaking Redis | Hacker News Reader

Valkey Is Rapidly Overtaking Redis

devops.com

192 pointsCrankyBear85 comments

One of the challenges Redis labs here have is that there's very little reason for their userbase to stay loyal to them.

antirez retired from Redis development a few years ago.

From https://github.com/redis/redis/graphs/contributors it looks like activity since he left has been mostly from people who didn't overlap with him much.

Redis Labs have not shown themselves to be outstanding stewards of the project as far as I can tell. Why shouldn't people support the fork?

Here's some additional insights regarding Redis and Valkey

https://devboard.gitsense.com/redis?id=f66d8a46ef

If you ignore comments and just look at people raising issues and pull requests, Valkey has more contributors

https://devboard.gitsense.com/redis?id=f66d8a46ef&comments=i...

Full disclosure: This is my tool

I'm wondering how much of this is related to initial setup and rebranding. Iirc OpenTofu had a 2-4 week surge in PRs just getting builds, infrastructure, and rebranding cleaned up so they could build Terraform on new CI under a new name.

I would say a lot right now. If you look at contributors with open or merged pull requests

https://devboard.gitsense.com/redis?id=f66d8a46ef&comments=i...

Redis has 14 contributors vs 48 for Valkey. I think it is very unlikely that Valkey is adding a lot of new code right now, so the activity is probably related to the rebranding to Valkey.

Changelog line items is probably a better measure (assuming the line items are aligned to features and bugfixes and not just a list of PRs) https://github.com/valkey-io/valkey/releases

Maybe version number/release cadence is also helpful.

I have a metrics called LCMFC (last contribution minus first contribution) which can give you insights into how long people have been contributing for. In a few months, I'll be able to better segment things.

I had (and will reintroduce in the future) a contributions insights tab that focused on labels, which I think can also help you understand how things are changing without actually digging into the code.

> Why shouldn't people support the fork?

That's a valid question and to be fair to Redis, we should also ask ourselves what are the incentives for Redis (or any other commercial oss) to continue development of truly free and open-source Redis?

If the answer is opensource ideals, it is not an honest or realistic answer.

If the answer is they can always get paid through hosted offerings and product support, Redis folks are saying that's not a sustainable option because of cloud providers.

Redis users fall into broad categories of individual developers, startups, medium level companies and enterprise scale companies. Individual users are unlikely to pay. Enterprise customers are big enough to have dedicated resources for support. It leaves startups and medium level companies. These users are leaving on-premise and moving to cloud providers and if there's a frictionless hosted solution by the provider itself they are likely to prefer that over paying Redis. There are always exceptions but I don't think this is far from reality.

If the quip is, Redis should offer a better product, they cannot! Not when competing with cloud provider's own offerings. They will be always be at a disadvantage in terms of total cost(for marketplace products) and resources spent for development of the core product itself.

I believe their license changes is about them trying to reduce the impact of cloud offerings.

I don't know if there is a better approach for Redis and the community but as users of their product we are also responsible to provide a sustainable path for development and come up with a solution for this common problem. Otherwise, Redis will not be the only product to take this direction.

PS: There are exceptions like postgres but there aren't enough of them at that scale.

> PS: There are exceptions like postgres but there aren't enough of them at that scale.

We need more communities and projects like PostgreSQL. Why can’t Valkey be another one?

The biggest mistake Redis Labs made was doing a rebrand at the exact same time as a license change. Usually you want rebrands to be loud and well known and license changes to be silent and ignored until it's too late and people have adopted the new license. In this case, they loudly announced that they're making an unpopular change and it gave everyone the will to switch.

I’m amazed that they thought that they could do this and get away with it. Redis is almost a foundational tool for modern caching architectures. Every company I’ve ever worked at used redis like candy to cache stuff that wasn’t important enough for the reliable but expensive and slow data stores. Additionally, the main features 99% of people want and need have been in redis for a decade. Even a fork that only fixed security bugs will have done better than Redis Labs after this debacle. It’s like if the author of nano, the text editor, would try this license change. I suspect this will be much like the {open/libre}office changeover. Maybe soon ‘apt get redis’ and others will be aliased to Valkey.

> Even a fork that only fixed security bugs will have done better than Redis Labs after this debacle

This describes Redict, not Valkey. I think it's actually great we have two forks, so they can focus on different things.

I'm curious about the impact of the licence change on the average company.

Were you self-hosting redis in all your companies, or how were you using it?

I think that the uproar about license changes are less about actual license impact and more about the impact to the community and social framework that Redis has fostered as a project previously. People are switching because at this point they think they can’t trust Redis Labs not to do more dumb stuff later. Combine that with my previous assertion that redis is very important software at most companies, and the calculus leans in favor of using the fork because any further major license changes might necessitate it anyways, and it’s easier to do now than under the gun. It’s important to not do stuff that loses trust when you’re a company founded on a community.

Yeah, I'm willing to trust the Linux Foundation won't pull a stunt like this but I have zero faith that in 5 years there won't be another announcement that "<other users of Redis we think have money> are no longer allowed to use it without paying."

> The biggest mistake Redis Labs made was doing a rebrand at the exact same time as a license change.

I honestly don't think that was the issue. The issue, unlike Elastic vs Amazon is, this change affects a lot of big players like Google, Amazon, and Oracle.

Elastic change affected amazon so much that they forked.

I think the real difference is that Redis Labs never hired the majority of contributors.

It's too dangerous to build a company around open source. You're trapped between AWS eating you or having to relicense and AWS eating you. Source-available from the beginning protects you from this. The problem with OSS stuff is that people are generally price-sensitive and you can't beat the platforms for this since they get the R&D for free.

It's sort of how I don't hire junior people. When others have trained them up, I can just hire them for more. The other guys have to pay to train them so they hope to get some reward for that, but switching costs are low. I can just take pre-trained guys.

And just like the pre-trained guys in this scenario, AWS can always offer a better deal. You need to moat your stuff in some way. Elastic License is ideal if you want to build a company around this. If you just want to make things for the good of mankind or whatever, you can use BSD/GPL/MIT/whatever, but you're doomed if you want to build a company around those licenses.

Elastic made it by being quick to the jump. Others have followed. The only really successful model that's different has got to be Kong and RHEL and they've both been around a while. Kong's adoption is troubled because once you get successful, using their OSS thing is better than the enterprise because their pricing tiers go up. But they seem to have good enterprise sales team. Don't know about RHEL.

But if I were starting a company around this stuff, I'd be very careful about having core tech be true OSS. Source-available yeah, but true OSS is too risky.

All well and good, except a lot of us here go out of our way not to build software on top of proprietary software. (It’s a pain in the neck to move between cloud providers, sure. You’re kinda stuck with that sort of lock-in. But RDS is popular only because it’s a hosted PostgreSQL. If you don’t like it you can switch to the real thing.)

> It's too dangerous to build a company around open source.

You could always just like, not do that? There is nothing preventing anyone from simply not open-sourcing their software. Complaining that "people can use your open source software" is like complaining about how trees split water

The reality is we've seen very few source available projects take off, and it's likely that we'd all be using a competitor if Redis had started source available from the beginning.

Saw a presentation by them at this week's Open Source Summit. Seems like a lot of the major contributors to Redis have moved over to this project. And it seems like AWS is a major supporter of it. I suspect their Elasticache Redis will soon be Elasticache Valkey.

I would personally never contribute to a project with non-free license without getting paid. It's basically working for a company without pay.

I would never contribute to commercially backed, freely licensed project unless I was being paid. Saying this as a developer who is paid for exactly that, not it any inside knowledge that points to ulterior motives, but just the idea of giving a company free labour is unsettling.

> I would never contribute to commercially backed, freely licensed project unless I was being paid.

Based on what I've seen, a lot of people contribute to VC/commercially backed projects for resume/career growth reasons.

It's fair to say that in the early days of the FOSS movement, people were contributing for prestige and recognition. The commercialization into "Open Source" meant that work was appropriated for profit by organizations that weren't interested in either the "free as in beer" or "free as in freedom" aspects. Naturally people followed their mercenary lead and started to work on them for the financial benefits.

I'll do small contributions if I wanted to learn about the software and discovered bugs or other small issues.

Commercially backed is a pretty big bucket and includes things like Linux and a lot of Apache Foundation projects (iirc Apache projects need to maintain a sponsoring organization but it doesn't have to be for profit)

> I would never contribute to commercially backed, freely licensed project unless I was being paid.

I understand that position, but I think it depends on a few more factors.

Like the Go project?

Of course "it depends", and people should make their own mind up with what they're comfortable with.

Google doesn't monetise Go, so I would have less problems contributing to it. Redis, before the license change, is a perfect example of what I wouldn't contribute to.

It is almost same as transferring your hard earned money to the founders of the company. Of course it is unsettling.

Technically you do that all the time when you buy any sort of product. Ideally you derive value of some sort for your payment.

The problem is that an open source project you contribute to can become non-free from under you at any point. This pattern is becoming more and more common now.

This is only half true in my opinion. Only future versions will be non-free, all the contributions before the license change stay free and can be forked.

Any project with a permissive license (BSD/MIT) can always be made into a commercial product. I could fork Valkey any minute, change the name and start selling it.

There are ways to prevent that which in retrospect we should have paid more attention to. For example, (L)GPL with no CLA cannot be changed later.

In retrospect, Redis Labs is about to learn a lesson that many have learned before.

Community willingness to maintain popular software under the old license means that attempting to make free non-free will result in a fork taking over.

As a prior example look at what happened a few years back when Oracle tried to make Hudson non-free. Now nobody has heard of Hudson, but everybody uses Jenkins. Which name was chosen for the sheer mockery value and reference to the then infamous https://www.youtube.com/watch?v=mLyOj_QD4a4.

There are people who think we need the legal protection of the GPL. But there are others who trust in community pressures to make the right thing happen.

Was Jenkins a Leeroy Jenkins reference? Seemed to be just continuing the butler theme from Hudson.

It served as both, but at the time I definitely saw people referring to it as a Leeroy Jenkins reference. With the fact that can also refer to a butler as a bonus. Though I'm sure some saw it the other way.

It's a kind of pun that programmers like. For example when I asked, Larry Wall said that he named Perl, Perl after he had two acronyms. Namely Practical Extraction and Reporting Language and Perfectly Eclectic Rubbish Lister.

A lot of younger folks probably never heard of XFree86 or OpenOffice.org. In a few years Terraform and now Redis might end up just like them.

That's the decade old philosophical fight about what to consider free software. GPL/GNU vs BSD.

I think both opinions are fine, if you don't want your contributions to end up in a commercial product, you can't contribute to a project with BSD/MIT license. On the other hand most companies prefer to support projects with a permissive license over projects with copyleft (GPL). For many projects (except the big ones like GNU/Linux) copyleft seems to be more of a burden.

antirez wanted to allow it, not prevent it:

https://news.ycombinator.com/item?id=39863371

Thanks, that's a perfect summary of the problem and the reasons why the BSD license was picked. It's perfectly fine though to disagree and do it differently.

"Rapidly", so most people don't even know the story about Redis changes and I would say 99.99 never heard about Valkey.

Redis (64.7k stars): Excluding merges, 8 authors have pushed 8 commits to unstable and 10 commits to all branches. On unstable, 173 files have changed and there have been 2,002 additions and 3,194 deletions.

Valkey (12k stars): Excluding merges, 41 authors have pushed 147 commits to unstable and 181 commits to all branches. On unstable, 473 files have changed and there have been 10,635 additions and 9,663 deletions.

You may as well just start mentally teaching yourself to alias redis to valkey.

Those numbers mean nothing because obviously a fork in its inception will have a burst of activity. Half of those changes are probably just renaming redis => valkey, too.

Let's check the numbers in 6 months or a year for a truly meaningful figure about the health of each project.

Based on your logic “activity” may never be a good metric for usage.

I don't know what gave you that idea?

I'm fine with using the activity comparison to declare a winner.

But valkey was created a few weeks ago, obviously it's going to have a burst of activity. However most forks die off rather quickly after the initial burst of enthusiasm. That one might be different, because it has corporate sponsors.

So, in 6 months, do the exact same comparison (recent activity, # of recent contributors) and it'll be good enough for me.

And that’s also true insofar as it’ll never be a perfect measure and in some cases (such as comparing a mature project to a brand new fork), it’s a bad measure.

My thoughts exactly, same thing with OpenTofu recently

How are we supposed to interpret these numbers? In its whole history, Redis has had 8 contributors? And in less than a month Valkey has added 33 contributors?

But what value have those 8 vs 41 authors added to the project with those changes? I think that's the primary concern here.

We are experiencing exponential growth in the last week, going from 1 user to 2.

100% week over week growth is nothing to sneeze at

Relevant xkcd https://xkcd.com/605/

Ah, I was expecting https://xkcd.com/1102/

Linear growth in husbands? Pathetic. You'd need at least quadratic to amount to anything.

Once the big cloud providers start to charge extra for Redis over Valkey in a few months everybody will know.

Valkey just released their first stable version 3 days ago. So it might take another week or two until it's popular ;)

At the company, I mentioned Valkey, and no one had any clue what I was taking about (we use Redis).

I was aware of the license change but not of the forks. Now I am.

Redis holds such a special place in my heart. It was the definition of awesome, open-source software. It always felt like Redis was THE definition of open source. The fact that the license has changed is heart-breaking.

It’s a understandable move, it’s the same reason as Elastic. AWS and other hosting companies ate their lunch, of course they want a piece of the pie to stay alive.

That’s my take away from this anyway!

Even if there was no AWS product for managed Redis, how many businesses would bother paying Redis Labs and introducing extra latency to their cache server if they could easily set up their own instance on AWS (in EC2/ECS)? Configuring Redis is not rocket science.

I think the right way to frame this situation is how Corey Quinn did in the quote at the end of the article. Redis Labs is the party that forked Redis when they changed the license. Redis Labs may own the name, but the community maintainers are carrying on the original project, just under a new name.

Hopefully this will help resume work on a better High Availability code. Where one could have a cluster of 3 ValLey servers, with a superior HA protocol.

> At the time of the fork, Redis CEO Rowan Trollope didn’t seem too worried.

I have the feeling that CEOs are mostly stupid people.

LOL, Redis CEO Rowan Trollope. Man I despise that guy. After successfully navigating the Cisco Contact Center, UC and WebEx business into oblivion, he ends up at Five9 architecting the crash and burn Zoom acquisition that failed 'successfully', and now he pops up at Redis.

Run away screaming as fast as you can.

I'm curious. Do you have a summary which goes over that without having to read a dozen articles?

Good. I hope Redis Labs dies a slow death for stealing the project from the community.

There's something wrong at Redislabs, it took them over a year to get RESP3 rolled out into their hosted service, you'd expect a rollout of that to be a bit quicker when they're the owner of Redis.

It affected us when upgrading Sidekiq to version 7, which dropped support for older Redis, and their Envoy proxy setup didn't support HELLO and RESP3: https://github.com/sidekiq/sidekiq/issues/5594

I was honestly shocked by this too, I never intended Sidekiq users to left in a lurch like this. It took them over three years from the RESP3 release before their service supported it. I figured any good SaaS should be dogfooding their own releases, but I guess not!

Having not heard of any of this before now, I'm struggling to wrap my head around why this would be evidence that they're not good stewards of Redis-the-project (as opposed to their Redis service). If they had delayed the general release until their cloud could support it or tried to expedite their cloud release by moving resources over to the cloud services, I feel like that would be much more worrisome in terms of their stewardship of the project as a whole. If anything, it sounds like they basically chose to prioritize Redis in general over their own offering, which is exactly what I'd expect people in the community to want.

This is a very common but wrong assumption.

The OSS and Cloud divisions of most companies are very different beasts. The engineers that staff them are different, and their focus is different. This has often lead to issues where the company that creates the project doesn’t always have the capability to support it at scale.

TBH, while I don’t support that kind of behavior, the cloud providers probably provide the best SaaS support for most OSS projects, just because of the operational capabilities they have created.

Nothing was stolen. The license allows commercial forks.

Also, nothing of value was lost. The new forks have all the source code.

> Also, nothing of value was lost. The new forks have all the source code.

What about the community fragmentation and the eventual rise of incompatibilities as the development will take on slightly different directions? E.g. what happened with MySQL and MariaDB.

It’s a risk. It’s not clear what will happen. Maybe one fork will win, or maybe the competing forks will come up with a common standard (like browsers).

An issue with databases is that unlike browsers, there’s not that much incentive to standardize, since most apps pick one and stick with it, and their users don’t care.

Comments generally covering the situation well.

The one thing I take as a bit of a potential bitter irony is that if Redis had had the level of support & contributions ValKey has, Redis Labs might have been able to keep doing what they were doing?

Seemingly a bunch of companies are happy to start paying for open source, when weeks ago many were passive consumers.

Redis Labs required would-be contributors to sign a CLA to hand over their copyright. If ValKey doesn’t require that, it alone could account for the difference.

I wouldn’t sign a CLA to anyone other than maybe the FSF.

Right, but that CLA stemmed directly from the decision that they needed to monetize better & change their licenses.

Point remains: there's a more than small irony here that a company wasn't doing well/was struggling with open source, but could perhaps have done great if the help freshly created has been at all available when they were fully open source.

This article is just propaganda, as many others from Steven J. Vaughan-Nichols.

I was literally waiting for a primary fork to emerge. Bye Felicia (Redis)

Is there any reason I don’t just stick with redis 7.2.4 instead of trusting redict/valkey to not inject some backdoor trash? I can avoid the corporate pivot and the random fork at the same time.

This new narrative makes it as if backdoors started existing the moment xz happened. As if that wasn't always a threat, and that xz more than anything did prove that free software is a lot more resilient than to suffer similar attacks that have happened and will continue to happen without public acknowlegement or as much publicity in unfree software/SaaS.

One is maintained and the other isn't. If you don't care about that you could definitely stick with the old version.

Redis hasn’t materially changed since about 2.8 so tbh unmaintained is more than fine.

This (and simliar) is pretty materially a good reason to update to something more modern:

https://github.com/vulhub/vulhub/tree/master/redis/CVE-2022-...

Maybe take a look at the other fork, Redict?

https://redict.io

Reply on news.ycombinator.com