Live data from Hacker News

The race to replace Redis

lwn.net

281–290 of 520 posts

Re: The race to replace Redis

#281
post #268

Microsoft's Garnet has the best chance of replacing Redis, the OSS project and the hosting company. Article doesn't mention it, but supposedly Microsoft uses novel algorithms and multi threading to achieve an order of magnitude improvement in throughput. Now if they can commercialize it with Azure, it should be a credible alternative to Redis Enterprise hosting.

Let's replace a project that failed because of a CLA with another project that requires a CLA

Garnet is MIT licensed.

See: https://github.com/microsoft/garnet

Re: The race to replace Redis

#282

Earlier quoted context omitted.

OpenSearch infuriates me to no end. It lacks so many improvements and advancements since the ancient version it was forked at, but because AWS already has an org's payments details, teams often refuse to look at Elasticsearch. Even basic things like autocompleting queries have been WIP for half a decade now: https://github.com/opendistro-for-elasticsearch/sample-code/... https://github.com/opensearch-project/OpenSear…

Query autocomplete is a feature of the Kibana web interface, not of the ElasticSearch database itself. Which isn't to say that it isn't useful, but it's more of a niche utility than a core feature of the stack.

Maybe you're unaware OpenSearch covers Kibana's functionality via OpenSearch-Dashboards? Just like the rest of X-Pack under OpenDistro pre-name change

It's not exactly a niche utility for observability unless you plan on hand searching hundreds of fields. But of course see my other comment for a list of the other observability fumbles they've made.

Elastic chose a pretty great time to start to give observability attention, and OS didn't keep up there. Meanwhile search is becoming more and more focused on integrating semantic search (which Lucene isn't particularly excellent at)

Re: The race to replace Redis

#283

It wasn’t clear to me until I read their blog, that redis will remain free to use in their “community edition”, which will continue to be supported and maintained (and improved!) So we as developers don’t have to scramble to replace redis in our SAAS apps and web based software. This is more about preventing AWS from eating their lunch by providing redis-as-a-service, without paying any sort of compensation to the re…

> that redis will remain free to use in their “community edition”,

I mean, they've already changed licensing for parts of the project twice in 6 years. I have zero faith that they won't pull a Vader and change the terms of the agreement again.

> continue to be supported and maintained (and improved!)

I'd guess that > 99% of any "improvements" Redis the company make, will affect As has been pointed out numerous times, it's essentially "done" in terms of functionality - but as a VC funded company they have to constantly do "something", so they'll keep adding niche upon niche features, giving the resume padders at other VC companies something sparkly and new to spend their budgets on.

Meanwhile 99% of people just need a fast key/value store, and maybe half of those need it to be distributed/replicated, and maybe a third need it to run some kind of scripting (Lua) to do "in-db" operations atomically.

With the addition of native TLS several years ago redis is, for 99% of users "functionally complete".

Sure, new TLS versions will come along and need support, kernel or library features they use will adapt or have improvements, etc, but I think you're vastly over estimating the amount of "improvements" to expect that will impact the vast, vast majority of users.

> preventing AWS from eating their lunch by providing redis-as-a-service, without paying any sort of compensation to the redis developers

Look I hate AWS more than most people would find reasonable, and even I'll admit they're not the "bad guys" in this scenario.

The project was released as BSD licensed, so AWS could if they wanted, fork it, and offer a service based on that, and make any fixes/improvements just in their service offering.

They didn't. They had paid staff contributing back to the redis project, for a number of years. This was literally the goldilocks project of the OSS world:

Numerous massive tech companies who all have the financial ability to simply run their own fork, and the legal right to do so (due to BSD-3), willingly contributing to the maintenance of the project.

As I've said before, the story of what's happened to Redis (and HashiCorp stuff) is likely to become a warning to the tech community in general: if an OSS project you rely on transfers control from it's founder(s) to a company, you probably need to consider continuing with a fork from the last open version, because apparently "(try to) monetise popular open source" is the newest way to win the douchebag villain award given to MBAs at VC funded companies.

Re: The race to replace Redis

#284
post #223

Earlier quoted context omitted.

It's not AGPL, but L GPL-3.0-only. Neither of these licenses is "hostile". And ftr, in my eyes, a project being created/initiated by ddevault is an asset, certainly not a liability.

You are correct. The issue is that any [X]GPL license has bad reputation in business environments. They see it as a big legal risk that will require constant legal supervision over the technical usage of GPL-licensed code.

¯\_(")_/¯

I pity the fool(s).

Re: The race to replace Redis

#286
post #185

Earlier quoted context omitted.

Ah, so it’s not about open source and moral responsibilities. It’s about the responsibility we all owe to VCs to ensure they make money. Gotcha.

Isn’t that the deal we sign up for when we take VC money? I like free money as much as the next guy, but VC isn’t it.

Who's we though? The former Garantia data did, but redis users didn't.

(And also I'd argue most of redis' value to users was already in place before the VC backed company got involved)

Re: The race to replace Redis

#287
post #244

All this outcry about license switch coming from "community" feels funny. After all, if there is the "community" then they can take the last open-source version and keep developing it themselves, right? But most "communities" are about "take, take, take", not "work, work, work". They often upset only because someone declared they aren't going to work for free any more.

If you only take, obviously there is no reason to complain. Now the problem is rather when contributors (those who "give", not those who "take") have to sign a CLA. Then the company who gets their copyright takes their work for free, to later use it in a non open-source project (assuming they changed the license, like Redis did). I think it is valid to find this immoral. The solution is pretty simple though: do not c…

No? They create a fork that maintains the existing terms. No cla required.

Re: The race to replace Redis

#288

All this outcry about license switch coming from "community" feels funny. After all, if there is the "community" then they can take the last open-source version and keep developing it themselves, right? But most "communities" are about "take, take, take", not "work, work, work". They often upset only because someone declared they aren't going to work for free any more.

That's a dumb take. That completely ignores opportunity cost of such actions. You can't just spin up a fork like that; there's barriers to entry, network effects, etc which prevent that from being a simple solution.

You really can just spin up a fork

Re: The race to replace Redis

#289

Earlier quoted context omitted.

Teams should refuse to look at Elasticsearch. It's license is SSPL and they ship free and non-free features in the same binary. It's a ticking time bomb to run it in your company. Also you can just keep your data in postgres and use paradedb and stop having to deal with dramatically more expensive infrastructure and the JVM.

Ah yes, battle-tested Elasticsearch is a ticking time bomb for not wanting to get their lunch eaten by Jeff Bezos. Just use this pre-V1 public beta software I stumbled upon instead.

The reality is that open search will be (if it is not already) more widely deployed and “battle tested” with bugs that production use raise resolved in it.

The narrative that opensearch is some kind of unsafe abandonware is clearly nonsense when you read the commit log: https://github.com/opensearch-project/OpenSearch/commits/mai...

All I can say is, sure, if you want elastic use elastic.

…but opensearch is fine. I use it and have no problem with it.

Re: The race to replace Redis

#290
post #225

Earlier quoted context omitted.

Yep still the biggest leachers. Token hires and flowery PR campaigns doesn't entitle them to most of the profits of other vendors products or absolve them of their predatory behavior. But they wont be able to leech Redis's future contributions. Knowing AWS they'll most likely create a fork to continue raking in most of the profits in the short-term.

AWS, along with Google and others have created a fork already. It’s very rude of you to call someone a token hire when they’re high up in the contributors list (#7 all time). Denigrating their work for no reason other than to “win” an internet argument. We’ll see what happens though. If redis Inc (that never created redis) wins over AWS, GCP and others (who also never created redis). Both contributed to its maintenan…

> It’s very rude of you to call someone a token hire when they’re high up in the contributors list (#7 all time).

I've called AWS's hiring of a single developer a token hire that they then go on to write flowery PR posts about to camouflage their predatory relationship with OSS vendors.

For concrete numbers they contributed 165/12111 commits for a total of a 1.36% of the commits.

Whilst that qualifies as a valuable contribution to any project, it's also dwarfed by the 350M investment in Redis Labs and doesn't absolve AWS from being a called a "leacher" by helping themselves to the majority of the profits whilst contributing relatively nothing back.

Post reply on HN