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...

“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?

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/

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

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.

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

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.

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

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

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.

So.. Redis had a choice of licenses: BSD (improvements do not need to be contrbuted back) or GPL (improvements do need to be contributed back).

For whatever reason they chose BSD. And now Amazon made some improvements and is not contributing back.

Not sure why anyone is surprised.

GPL wouldn't prevent Amazon from forking and then providing managed instances of the project without releasing the source code of the fork. AGPL would, though.

But yes, this is the reason I won't work for free on my own or others' BSD or MIT licensed projects.

BSD and MIT don't grant patent rights; this might be one reason Facebook uses them, though they did try to get predatory in the only way Facebook can: https://news.ycombinator.com/item?id=14779881

ianal, but imo, Apache License v2, Mozilla Public License v2, and xGPLs v3 are better at protecting the rights of the consumers (including contributors).

Sometimes fixing upstream is hard / not possible, when maintainers don't want to accept others' proposals/vision, or are cautious to change architecture with breaking changes.

So they don't release the result as OSS because upstream wouldn't have included it?

I don't know much about this particular case. However generally speaking that is not true. They would just need to make the fork public. Whether the maintainer accepted the changes upstream is irrelevant.

Unless they actually tried to upstream it, this point doesn't really matter. From what I can see, they never actually tried or intended to upstream their changes, so this is irrelevant. They didn't even release the fork's source, let alone try to upstream it.

Ahh, the new Oracle.

No, not everything negative is the new Oracle. AWS has very little in common with how Oracle has operated historically.

Oracle didn't build their company in the style of AWS Redis, that cloning maneuver. Oracle's database was a pioneer. Oracle didn't get where they are by cloning open source and claiming it as their own. Despite the numerous bad things that can be said about Oracle's culture, that's not one of the key negatives about Oracle.

Agreed. Not an Oracle fan boy but they didn't deserve to be brought up in the context.

They killed and re-proprietarized OpenSolaris.

Had OpenSolaris developed a sufficient community outside of Sun/Oracle, this would have been much less of an issue. Which is why community is a big deal. A large company can always decide that some project is no longer interesting and, if they're the only ones supporting it, it's going to die. They certainly have no obligation to support it.

At this point in AWS' life, enterprise sales is king. Not surprising that there's shades of Oracle / Microsoft in them. May be, Google hired Oracle #2, Thomas Kurian, to head GCP for similar reasons. Like it or not, Oracle-sized shadow looms large over BigCloud.

It surprises me when people lump Oracle (or AWS for that matter) in with the likes of Microsoft.

The process to make MS-OOXML an ISO standard was a dirty one https://en.wikipedia.org/wiki/Standardization_of_Office_Open... and 2008 wasn't that long ago

Ballmer era Microsoft is a very different beast to Nadella era Microsoft

I don't see Microsoft jumping to fix all the interop issues their software has with ODF.

Why? They're all enterprise software companies. They participate in open source to greater or lesser degrees. They seem absolutely part of the same category. This isn't either positive or negative commentary but just observation of what they do as businesses.

In that Microsoft is way worse or way better? I’m not clear, because they’re all pretty scummy.

You are right Microsoft could be a more difficult entity to deal with.

A side question: is there anything licensed AGPL that AWS uses? Either AWS releases the code or found a way around the license?

Yes, but AFAIK it isn’t modified.