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
The race to replace Redis
281–290 of 520 posts
Re: The race to replace Redis
#282Earlier 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.
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
#283It 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…
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
#284Earlier 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
#285Re: The race to replace Redis
#286Earlier 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.
(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
#287All 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…
Re: The race to replace Redis
#288All 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.
Re: The race to replace Redis
#289Earlier 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 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
#290Earlier 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…
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.