[rubiquity]

Disclaimer: ex-AWS as well, worked very closely with MemoryDB, but not paid to shill!

You're entitled to your opinion but your line of reasoning for how MemoryDB for Redis came to exist or the reasoning about why it isn't in upstream Redis is not factual. MemoryDB's architecture uses Amazon's home grown log replication services as pointed out by Werner Vogel in his blog post about MemoryDB[0]. This architecture is fundamentally incompatible with upstream Redis. The real reason why MemoryDB for Redis exists is far less juicy: MemoryDB came about by meeting customers where they were. Customer's love Redis, especially for its non-caching features, but replication is a headache with all the existing solutions today.

Also as far as I know one of the lead committers to Redis is from AWS.

0 - https://www.allthingsdistributed.com/2021/11/amazon-memorydb...

[awill88]

“meeting customers where they were”

I’m a total AWS fanboy, but even I cringe when I read that superficial, customer-centric sound bite. You know who meets people where they are? FOSS maintainers.

“Also as far as I know one of the lead committers to Redis is from AWS”

Conveniently cryptic, what does from AWS mean? Do they still work there? Did they specialize in log replication?

[_msw_]

Disclosure: I work for AWS, but I don't work on Redis or managed services based on Redis.

Madelyn Olson, at present an AWS employee, is one of the members of the Redis core team [1]. The invitation was extended because she had "been actively involved in Redis development for several years, contributing numerous changes throughout Redis, including bug fixes and features."

[1] https://redis.com/blog/redis-core-team-update/

[strokirk]

Aren't FOSS maintainers famously "my way or the highway"?

[jacquesm]

Incompatible or not isn't the point. Not releasing is what it's about. And yes, they can. But that doesn't make it right.

[dottedmag]

What's the point of releasing a chunk of code that relies on internal AWS infra?

[awill88]

I think it’s the fact that the implementation details don’t change the optics; AWS had the resources and talent to both monetize AND be a Good Samaritan by contributing to the upstream. The contributions could have been RFCs, GitHub issues, etc. With that said, I can imagine the rumored culture of AWS engineering doesn’t support wondering souls that typically nurture thoughts of community service for the upstream.

[_msw_]

Disclosure: I work for AWS.

There were contributions sent upstream for Elasticsearch bugfixes and enhancements. Some of those PRs are still open, for example [1].

A sampling of additional PRs can be found in this blog post [2].

Further contributions upstream to Apache Lucene have been growing over the years. The new Approximate Nearest Neighbor support in Elasticsearch 8.0 comes from work that was sponsored by Amazon in upstream Apache Lucene [3].

[1] https://github.com/elastic/elasticsearch/pull/64513

[2] https://aws.amazon.com/blogs/opensource/stepping-up-for-a-tr...

[3] https://issues.apache.org/jira/browse/LUCENE-9004

[parkingrift]

Well isn’t it convenient that it requires AWS infra. And there is absolutely no way they could have designed it differently.

[lightbendover]

AWS had proprietary infrastructure that could solve the problem at hand; it's not reasonable to expect them to invest an incredible amount of effort to solve it again. AWS customers do not net-benefit from that duplicative effort.