Redis vs. the trillion-dollar cabals

Recently Redis changed its license, and mountains of misinformation have followed, not to mention a fork driven by trillion-dollar cloud company AWS. Among that misinformation is Steven J. Vaughn-Nicols’ earnest but incorrect declaration that the Redis change “means developers can no longer use Redis’ code.”

This is simply not true. For 99.9999999999999% of developers, their rights under the license remain exactly the same as they would under the most permissive of open source licenses. What it does mean is that trillion-dollar cloud companies like AWS can no longer take Redis’s code without contributing back.

AWS, after years of pulling plump profits from Elasticache (its Redis service), panicked and started a fork (Valkey), enlisting others so that it wouldn’t have to shoulder all the cost. The company learned that expensive lesson with its Elasticsearch fork, OpenSearch. Lest you think this is about community winning out over corporations, keep in mind that this “community” is more like a cabal of trillion-dollar tech companies ensuring a steady supply of cheap or free software to which they contribute virtually nothing. The members of the trillionaire club have founders worth more than the market valuations of Redis and all of the so-called open source baddies combined.

It’s time we stop pretending that the major clouds (and one in particular) aren’t directly responsible for this mess. The Redis story may be about profiteering, but it’s the trillion-dollar club holding the big bag of cash.

What about the developers?

Let’s first be clear: Developers are largely immune to Redis’s license change. The only developers that are “hurt” by the changes Redis made are those who work for the cloud companies (and even they, with one exception, haven’t contributed at all). One Hacker News commentator makes this very clear:

For my own use in my company or project as an individual:

• Can I have full access to the source, clone it and modify it? YES
• Can I do a pull request to improve it? YES
• Am I allowed to download, use and have it for free in my company even if my project is commercial and is making money from using Redis? YES
• Can I create a product that uses Redis as a technology for free in my startup? YES …
• Can I git clone / make / make install it like before? YES …
• Can I resell Redis as a service taking the source code and running it on my cloud without a paid license? NO (boo hoo hoo)

Catch that? The only thing—literally, the only thing—a developer can’t do with the Redis code is build a managed cloud service, unless they want to contribute the infrastructure used to run it. Is that open source? No, not according to the Open Source Definition. But is it Armageddon Day for developers, as it’s being portrayed? Nope.

Beyond being able to modify and distribute the Redis code, consider the reality that most developers have no desire to do that: What they want is great code that will continue to be supported and improved over time. This is where the Redis Inc. investment is so important. The innovation in Redis hasn’t come from AWS (with an exception I’ll note below), Microsoft, or Google. All the talk about community development of open source projects is mostly myth. The companies jumping behind the fork of Redis have done almost nothing to get Redis to its current state.

Consider Salvatore Sanfilippo who founded Redis. You’d think someone like that, who has had such a tremendous impact on Redis, would be supported by the forkers, right? Not so much, as our Hacker News commentator calls out:

Antirez [Salvatore] has 21K followers and 9 sponsors who donate on GitHub. NINE! Not 10, not 50, not 1,000 sponsors… It’s 9—a carpenter that lost a finger at work can still count them.

By the way, not one of those sponsors is a cloud vendor. Sure, it’s very possible that they no longer care about Sanfilippo, given he’s no longer involved with Redis, but they never supported him while he was building Redis, either.

What developers need most is great code that they can openly access, use, and depend on to be well-maintained. Redis hasn’t taken this away from them. All Redis did was try to maintain developer access to its code and to keep the clouds from siphoning away the means to invest in that code.

Changing licenses, but why?

Vaughn-Nichols points to a pattern: “A company will make its program using open source, make millions from it, and then—and only then—switch licenses, leaving their contributors, customers, and partners in the lurch as they try to grab billions.” He’s “sick of it,” but so are the companies he’s castigating. No one makes that kind of change unless under duress.

Vaughn-Nichols suggests the problem is that these companies “mistook ‘open source’ as a business model.” He’s wrong about that too. The problem is that the clouds mistook open source as a commons from which they could take and not contribute.

This is one reason I’ve been agitating for the OSI to live up to its mission and introduce strong copyleft for cloud software. Give developers (corporate or otherwise) the means to protect the freedom of their code and we’ll see less source-available software. It’s that simple.

Meanwhile, the Valkey fork tells us that the clouds are afraid of losing the Redis gravy train to which they’ve done little to contribute. Again, I’m mostly talking about one particular cloud (AWS).

The irony is that Redis is one of the very few areas where AWS is actually a contributor. I regularly cited the impressive work of Madelyn Olson, a Redis maintainer, as an example for AWS on a daily basis. Part of that is because Olsen is awesome. The other reason is she was virtually the only example AWS had. As she noted recently, “I worked on Redis in my free time.” That isn’t to say she never worked on Redis for AWS, but it also exposes the reality of engineering open source at AWS. A big reason AWS engineers contribute little relative to their peers at other clouds is that engineering leadership sees little value in doing so. This has started to change in some teams (like the RDS/Aurora teams realizing it was in their self-interest to do more for Postgres), but they’re the exception, not the rule.

Don’t believe me? Despite AWS’s newfound love for the Linux Foundation through the Valkey/Redis fork, you’d be hard-pressed to find contributions commensurate with how much money AWS makes. Just take a look at the CNCF devstats.

Really, pick a project. How about Kubernetes? AWS is the biggest Kubernetes vendor, making billions. Yet its contributions are Lilliputian compared to Google or Red Hat. AWS’s Kubernetes contributions rank behind DaoCloud Network Technology Co. Ltd., and just ahead of The Scale Factory Limited. Chances are you haven’t heard of either of these companies, yet they’re contributing roughly as much as AWS.

The same is true of Prometheus, OpenTelemetry, etc. AWS draws on these projects to provide a cloud service, yet it doesn’t make the Top 5 in contributions to OpenTelemetry or even the Top 20 in contributions to Prometheus. Across any open source project you can name (with the exception of the few that AWS has launched), AWS collectively makes tens of billions of dollars without contributing even tens of thousands of lines of code.

Is this somehow a violation of open source? No, not at all. But it’s the reason for the “open source rug pull” that folks have lambasted Redis over.

How about some customer obsession?

Lest you think I’m biased by my current employer MongoDB (which changed its license, similar to Redis), you might be interested to know this was my constant refrain when I ran the open source strategy and marketing team at AWS. The last thing I did before leaving AWS was to author a six-pager on why and how AWS could better support its open source partners. My argument was that AWS should more deeply invest in the code and commercial success of its open source partners, thereby making it more profitable for these companies to keep their software open source.

I believed then, and I still believe, that this would both protect AWS’s open source supply chain while best serving customers. No customer really wants Valkey (the Redis fork) or OpenTofu (the Terraform fork), or OpenSearch (the Elasticsearch fork). They want the original, “full-fat” version.

It really isn’t difficult to figure out how to ensure customers continue to get full-fat Redis, Elasticsearch, Terraform, etc. The clouds can learn how to partner better. To be fair, some already do. Let’s use Elasticsearch as an example. Google Cloud has long supported open source companies and partners with Elastic to deliver a great Elasticsearch experience. Microsoft, too, has actively contributed through code and cash to open source, including an expansive partnership with Elastic. AWS? Well, it wrote some blog posts that portrayed itself as the victim, then it forked Elasticsearch, in a profoundly customer-unobsessed move.

To be fair to AWS, its adherence to its Leadership Principles both supports and complicates its relationship with open source, as I’ve written. The “customer obsessed” approach would be to partner. But in order to “deliver results,” the company feels the need to control. That makes partnership more difficult.

It’s a quandary, but why should AWS’s internal dilemma be turned into a problem for open source companies that are already doing most or all of the hard work of software development? AWS has made some improvements, which I’ve celebrated, but no one should view them as an open-source hero in the Redis fork.

For now, we can only imagine a world in which the clouds contribute to existing communities rather than fork those communities when their trillion-dollar market caps are threatened by the prospect of collaboration. It’s easy if you try.