Hacker News Reader

Comment by jacquesm | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com