Live data from Hacker News

Elastic and Amazon reach agreement on trademark infringement lawsuit

elastic.co

161–170 of 188 posts

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#161
post #144

Earlier quoted context omitted.

But, if the value-add is hosting more than the software itself, why would you prevent the 'value-adder' making the bulk of the money? I'm like OP, trying to take a step back. What do we want here? As users? As developers? That no one does too much (or any) money hosting our software for other people willing to pay? Profit-sharing? On what basis? Really, naively, apart from the use of the Elastic brand, that I might c…

I want anyone to be able to pick up development of the software, not needing permission to do so. If elastic the business goes under, hosted solutions should still be available, with changes still be made on it

I'm thinking this would first be an API compatibility problem? The service can be implemented in different ways, by different teams. See redpanda vs kafka or wire-compatibility for postgres?

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#162

Earlier quoted context omitted.

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.

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#163
post #10

Looks like pretty good news. Have worked in AWS before. So AWS is very famous for making money using open source products without contributing upstream. One very good example is Amazon redis. Amazon figured out that redis asynchronous replication didn't work at scale so instead of fixing issues upstream they chose to develop Amazon redis in house and monetized it. https://aws.amazon.com/memorydb/ Enhanced version mea…

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 fu…

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

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#164
post #12

Full disclosure: This is my tool that I'm using to generate the insights. When OpenSearch was announced, I shared some insights into how both Elasticsearch and OpenSearch were evolving, and I'll share some more up to date insights here. Looking at recent pull request activity, OpenSearch had 52 contributors https://oss.gitsense.com/insights/github?q=pull-age%3A%3C%3D... while Elasticsearch had 181 https://oss.gitsens…

Thanks for gathering some data here. Very insightful and it confirms some suspicions I've had. I'm one of the people that is no longer creating pull requests for Elastic. I was never a big contributor and I only did a handful of small PRs. But all little bits matter and I was OK with doing that under the Apache 2.0 license and putting my time in and doing my small part. That's not a thing for me anymore. I charge money for commercial software development.

In practical terms, I now have to worry about supporting both Elastic and Opensearch as a consultant (always looking for new customers to help, if you need some advice) and I can't really recommend people stick with Elastic with a straight face either because Opensearch really is a decent alternative and increasingly the default for new users; as I have noticed with my own customers.

I maintain a Kotlin client for Elasticsearch and I have started work on making that work for both Elasticsearch 7, 8 and Opensearch; something that is complicated by the fact that Elastic intentionally made sure their Java client (which I depend on) no longer talks to opensearch. They also deprecated it and introduced a completely new one recently. And of course the recently released Elasticsearch 8 complicates things with a few new features, compatibility breaking changes, etc.

On top of that, Opensearch is starting to get its own features or alternatives to Elastic-only features. I agree that the momentum is still with Elastic but it is not the case that Opensearch is a dead fork. I know of several people that quit their jobs at Elastic because of the license change and that are now working on Opensearch or on Opensearch plugins. It will be interesting to see how the two forks evolve.

IMHO, the license change is long term a mistake for Elastic. They've cut themselves off from open source contributors who can still contribute to making Opensearch, Lucene, or Solr better. So, that's long term not going to be helpful. Elastic has always leaned on opensource heavily for contributions and hiring. A lot of their early hires came from the Lucene community and the many researchers contributing to that and later from people contributing to Elasticsearch. Additionally, a lot of value gets added to the ecosystem by OSS plugins. The authors of those now have to choose between Opensearch and Elastic. That's long term not good for Elastic as a lot of cutting edge stuff usually starts in the plugin community.

I don't necessarily like what Amazon did but I do think they did it the right way from the point of view of creating a credible alternative. And I think that the way Elastic responded to that is throwing out the baby out with the bathwater.

Perhaps the most striking statistic is that the total number of PRs for both combined declined: everybody loses. IMHO, they should just roll back the license change and grow their community rather than fragmenting and shrinking it. Amazon is going to get some of their customers either way. I actually think the fork is working out better for Amazon than it is for Elastic currently. It was a mistake. Amazon is not the most likely steward of open source. But stranger things have happened. Take MS in recent years for example. It's a sound business strategy to not piss off OSS developers. Elastic would do well to take note of that.

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#165

For anyone who wanted out of this fiasco, checkout MeiliSearch: https://docs.meilisearch.com/ It's written in asynchronous Rust with native application speed albeit using much lower memory usage than ElasticSearch, and comes with even more features than ES, so it's feature-rich, blazing fast and can still benefit on multithreaded CPUs. Downside is that it does not have distributed indexing mode yet, but it is schedul…

I'm sure it is fine and has interesting features. But at first glance it's objectively a tiny subset of the features that either Elasticsearch or Opensearch has. If that solves your problem; great. But if you need a good all round solution for search I would not start with this.

The low end of the market is well covered with solutions that don't really offer a lot of features, are a bit challenged on the scalability front, lack usability, etc. Some of those have more merit than others of course than others. Things are not automatically better when they are half implemented in Rust. Lucene is an amazing piece of technology that over the years has resisted multiple attempts for people to do better in other languages. Contrary to the popular belief, it's actually pretty good with memory. Most of it is off heap memory or operating system file caches these days: it relies on memory mapped files for a lot of things. It's also pretty good with doing things concurrently. E.g. updating index files with 32 CPU cores while also serving queries is not an easy problem to solve. I've indexed documents at a rate of 500M/second on a 30 node cluster once. That's pretty amazing to see happening. I was basically saturating IO and CPUs. Indexed over a billion documents in about 1 hour.

Lucene has many issues; scaling isn't one of them.

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#166

Earlier quoted context omitted.

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.

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#167

Earlier quoted context omitted.

One of the key benefits of FOSS is that if I don’t want to (or am not capable to) do something with the software, I can pay someone to do that part for me. Maybe that’s fix a bug, extend/modify the software, or maybe it’s operate and host it for me. I’d like to choose AWS to do this hosting in a lot of cases, assuming they’re willing. Barring them from hosting it is impinging on my freedom as a user and therefore wit…

I don't think they want to stop you from doing those things, and hiring out to do that, I think they want it to not be offered as a prepackaged product. So it's a reduction in freedom, but it's not a reduction in user freedom.

Those are just differences in timing and system efficiency. In one view, RHEL is a pre-packaged product. In another view, it’s a bunch of users outsourcing a portion of FOSS management to an expert company because they don’t want to do it.

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#168
post #76
post #10

Looks like pretty good news. Have worked in AWS before. So AWS is very famous for making money using open source products without contributing upstream. One very good example is Amazon redis. Amazon figured out that redis asynchronous replication didn't work at scale so instead of fixing issues upstream they chose to develop Amazon redis in house and monetized it. https://aws.amazon.com/memorydb/ Enhanced version mea…

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.

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

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#169
post #75

Hopefully this will let each of them compete on their own merits. I’ve been tossing up moving our workloads to Elastic Cloud anyway, because AWS ES Service is a source of constant headaches for us. Feels like at least once a week a server ends up in a state where we can’t fix it, and AWS engineers have to manually fix their internal state. Their standard response is “add more nodes”; well, we did that, and it is cost…

I hate to say it but your problem here is ES itself.

If you just need "Lucene but clustered" I highly suggest looking at Solr instead, it's design is much more straightforward and has pretty much all the most important knobs for actual indexing that ES has.

If however you are tightly coupled to ES API or use it with 3rd party systems you are sort of up shit creek without a paddle...

Ran ES at large scale for many years, eventually gave up and only use Solr or custom built search engines these days.

Re: Elastic and Amazon reach agreement on trademark infringement lawsuit

#170

Earlier quoted context omitted.

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?

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