Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The race to replace Redis

lwn.net

Post reply on HN
Print view View original

171–180 of 520 posts

Re: The race to replace Redis

#171

Post by masklinn »

tison wrote: post #7
tison wrote: post #5

For the first time, I know our (Apache Kvrocks, an alternative to Redis on Flash) committer Binbin Wang committed nearly 25% of the commits to the newer Redis version. You can find his contributor for both at: * https://github.com/apache/kvrocks/graphs/contributors * https://github.com/redis/redis/graphs/contributors

And here is an interesting conversation when Binbin came to the Kvrocks community: https://github.com/apache/kvrocks/pull/1581#issuecomment-163... * Me: @enjoy-binbin Out of curiosity, do you have a fuzzer to test out Kvrocks? Your recent great fixes seem like a combo rather than random findings :D * Binbin: They were actually random findings.I may be sensitive to this, doing code review and found them (also based on…

Yeah some folks are built different. I’ve a colleague who once every few weeks opens random files and notices weird patterns, I’ve no idea how his mind works but boy does it work.

Re: The race to replace Redis

#172

Post by mythz »

vasco wrote: post #128
mythz wrote: post #69

Earlier quoted context omitted.

The licensing change only applies to their future versions which they own all contributions of which AWS won't be allowed to leech off anymore.

AWS leeches as much as Garantia Data no?

AWS are the largest leeches of OSS, syphoning off most the profits and contribute relatively nothing back towards the OSS projects they rent seek from.

The "Free for all except mega cloud corps" license changes are to disrupt this status quo which currently sees the mega cloud corps with impenetrable moats from capturing most of the value of OSS products others spend their resources into building, AWS are then able to use their war chest profits to out resource, and out compete them, using their own code-bases against them.

It's unfortunate organizations need to resort to relicensing stop this predatory behavior, but its clear in AWSs 20+ year history they're not going to change their behavior on their own.

Re: The race to replace Redis

#173

Post by hsbauauvhabzb »

x3n0ph3n3 wrote: post #121
dkuntz2 wrote: post #54

Earlier quoted context omitted.

Well, except for the fact that "redis" the organization didn't create redis and isn't even the main developer of redis. The origin of Redis the company is literally as a hosting provider for the open source redis that they didn't create.

Not only that, AWS has been offering redis-as-a-service longer than the "Redis" organization has been.

But if the shoe were on the other foot, AWS wouldn’t hesitate to rip the carpet from under anyone.

Re: The race to replace Redis

#174

Post by bramblerose »

ufocia wrote: post #138
brody_hamer wrote: post #48

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…

> This is more about preventing AWS from eating their lunch by providing redis-as-a-service, without paying any sort of compensation to the redis developers. But the developers licensed the software at no charge. What kind of compensation are they entitled to then? Sounds like a case of sellers remorse/take-backsies one of the problems that open source was aiming to solve.

They are not entitled to compensation over their previous work, but you/me/AWS are also not entitled to their _future_ work.

Re: The race to replace Redis

#175

Post by throwaway5959 »

tsimionescu wrote: post #87
nerdponx wrote: post #41

Isn't this the reason why AGPL has started to get more popular? Everyone has to play by the very strict rules except the copyright holder, who can do whatever they want, but the community still benefits from the core software being open source. The BSD license in particular seems like a particularly bad way to run a business.

The whole move to new "open-core" licenses started with the most famous (infamous?) AGPL project - MongoDB. The AGPL is not what companies like this want (Mongo, Elastic, Redis etc). They don't want AWS's code: AWS is already providing that. They want AWS to pay them royalties or stop competing.

Then they shouldn’t have open sourced it in the first place.

Re: The race to replace Redis

#177

Post by pmontra »

fractalb wrote: post #157
crabmusket wrote: post #146

Earlier quoted context omitted.

Am I right in understanding that the relicensing was possible because of the CLA, not just because of the BSD license? Would a permissively licensed project that didn't use a CLA be vulnerable in the same way?

GPL mandates that all derived software must carry the same license. No need for CLA, as I understand it.

The copyright owners of a GPL software can do whatever they want with future versions, even going proprietary. The problem is that all the owners must agree on that. That's why some GPL software only accepts contributions by people that give copyright to a single maintainer entity. An example is FSF's copyright transfer, which to be fair is more nuanced than that and has also other purposes.

https://www.fsf.org/bulletin/2022/fall/copyright-assignment-...

Re: The race to replace Redis

#178

Post by crabmusket »

mooreds wrote: post #102
crabmusket wrote: post #4

Earlier quoted context omitted.

Why specifically venture funding?

My thesis is that when you don't have the pressure of VC funding (gotta hit the revenue numbers you promise to investors sooner or later), alignment between the business and the OSS community isn't as tough to find.

I'd agree with that. Your message sounded to me like you thought VC funding was desirable for software projects. I wonder why we can't just fund software like a regular business- why look for venture returns?

Re: The race to replace Redis

#179

Post by tsimionescu »

thayne wrote: post #164
tsimionescu wrote: post #87

Earlier quoted context omitted.

The whole move to new "open-core" licenses started with the most famous (infamous?) AGPL project - MongoDB. The AGPL is not what companies like this want (Mongo, Elastic, Redis etc). They don't want AWS's code: AWS is already providing that. They want AWS to pay them royalties or stop competing.

> They want AWS to pay them royalties or stop competing. But the switch from AGPL to SSPL didn't do either of those things. AWS still built DocumentDB to compete with Mongodb, and didn't use any SSPL OR AGPL code in the implementation (at least according to their FAQ[1]). And AFAIK AWS isn't paying mongo any royalties. [1]: https://aws.amazon.com/documentdb/faqs/

Well, I was using AWS more as a catch-all term for cloud. They never actually offered a managed MongoDB service, but other like IBM and Oracle did (or still do?). I'm not sure what impact this had exactly, whether those services were discontinued or if they are now paying Mongo for them - but surely they had a significant impact one way or the other.

Re: The race to replace Redis

#180

Post by harryf »

To me Redis has always seemed like a Trojan Horse for developers. The first impression is its this simple key-value database, so easy to use. Oh wait... it's also a cache, nice! Let's cache all the things too! And look... all the cool kids are are using it too, so it must be cool, meanwhile the old Unix mantra of make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features. ( http://www.catb.org/~esr/writings/taoup/html/ch01s06.html ). Fast forward 10 years and you need to download it's Enterprise Whitepaper ( https://redis.com/solutions/use-cases/caching/ ) to make the right caching decisions.

Where this is coming from is having worked on a project where Redis was being used as a database and a cache, on different ports. And of course most of the dev team hadn't read the the manual because Redis "is simple and just works". And of course someone forgot to actually configure the Redis instance that was supposed to be a cache to actually _be_ a cache. And someone else thought the instance that was supposed to be a cache but wasn't was actually a database. And yet another had used TTL caching to solve all their performance issues. And pretty soon mystery bugs start showing up but sadly no one can actually REASON about what the whole thing is doing any more, but there's no time to actually clean up the mess because it's a startup struggling to stay afloat.

And I remember asking "why didn't you memcached for caching?" and the response was "Dude! No one is using memcached any more". So the technical decision for Redis was based on "what's cool right now".

Anyway... I feel a bigger rant brewing so I'll stop here.

Post reply on HN