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.
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.
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.
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.
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.
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 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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
> 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.
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.
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.
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?
reply