Live data from Hacker News

Official Elasticsearch Python library no longer works with open-source forks

github.com

121–130 of 144 posts

Re: Official Elasticsearch Python library no longer works with open-source forks

#121

PostgreSQL should be everyone’s first choice for a data store. It can do so much, including serving as your full text search system.

I love postgres and the full-text search feature works great in some use cases, but it is not really comparable to elastic search in many scenarios (huge document stores, complex text processing or querying, etc).

For sure, but I would posit most startups and smaller stage companies can get by with it. It really comes down to indexing data properly and designing for your search patterns. If your search patterns are vast or change constantly, ES might be better, but if you just need basic text search over X attributes, Postgres will be sufficient.

Re: Official Elasticsearch Python library no longer works with open-source forks

#122
post #120

Earlier quoted context omitted.

The lessons that some contributors (myself included) will learn from this, is that it’s now a common bait and switch to build your product with open source contributions, and then relicense it when it’s time to monetise. I used to talk most of my employers into letting me bug fix open source projects that they were having issues with, now I just talk them into maintaining their own forks. The open source “freemium” b…

I fear you might underestimate the maintenance costs of forking. A nice anecdote I heard a long time ago was comparing the approach to custom engineering between SuSE and Red Hat. SuSE was always very happy to do custom engineering for paying customers and developed and shipped these features in their Linux Distribution. Specifically I am thinking of some interesting features done in the Kernel. At that point, SuSE r…

[deleted]

Re: Official Elasticsearch Python library no longer works with open-source forks

#123

Earlier quoted context omitted.

Makes me think of "Oracle poetry": https://dacut.blogspot.com/2008/03/oracle-poetry.html

So the idea is that a poem, being a work of art, is actually copyrightable? Does this legal hack work?

The finding in Sega v. Accolade would seem to exclude this Oracle 'hack', too, as being fair use: https://www.copyright.gov/fair-use/summaries/segaenters-acco...

Re: Official Elasticsearch Python library no longer works with open-source forks

#124

Earlier quoted context omitted.

They have the right to do so, but that doesn't change the fact that it's a bad idea politically. It comes off as Elastic prioritizing their war with Amazon over the community, leaving room for Amazon to continue to position themselves as the community's ally.

At the end of the day, CTOs and decision makers in corporations don't go with the company that position themselves as "allies". They go with the company that is shipping important new features, with better support and resiliency. If Elastic is shipping features faster than AWS is, then they'll go with Elastic. I bet most CTOs aren't even aware of the politics happening - it's only the echo chamber in Hacker News that…

> They go with the company

...that is the bigger name and perceived as lower risk, better enterprise support, and fits with less internal work in their broader strategy even if that means sacrificing feature speed.

I mean, at least, most of the established market, rather than startups burning through VC dollars. But even the latter is likely to do one stop shopping with a big cloud vendor like Amazon unless particular features of an alternative are key to their business.

Re: Official Elasticsearch Python library no longer works with open-source forks

#125

Earlier quoted context omitted.

It's entirely possible that the relicense and now this will have the the precisely the opposite effect though. I'm sure the relicense was an attempt to increase Elastic NV's revenues from SaaS by locking out competitors from using their same codebase (from public financial filings, Elastic NV is not profitable so they are probably looking to become so). But open source also attracts new customers and improves the pro…

1) Is outside contribution really important going forward? Most of the Elasticsearch contributors are probably already employed by Elastic. 2) Open source doesn't attract new customers. There's nothing special about having software where anyone can contribute freely, that makes it attractive to customers. There is however, something special in making it free to download, setup and use in your own servers that makes i…

>There's nothing special about having software where anyone can contribute freely, that makes it attractive to customers

Community, support, acquisition, extendability and code quality.

Community/Support -- lots of documentation available for free, generally multiple vendors that offer paid support, free access to updates. Don't have any data but I suspect finding people to support/run it is easier (skills are more marketable and easier to learn on your own)

Acquisition -- eg less of a vetting/auditing process for places where that matters (you can handle vetting the code and supporting company separately)

Extendability -- you can hire developers to add features or integrate without being subject to the owner's timeline e.g. you don't have to plead for features

Code quality -- being open, it's more apparent if the software has a high number of bugs or large amount of technical debt that could lead to instability. Usually the issue trackers for OSS are open to everyone

These apply more to large companies with dedicated teams

Re: Official Elasticsearch Python library no longer works with open-source forks

#126
post #78

Earlier quoted context omitted.

It's entirely possible that the relicense and now this will have the the precisely the opposite effect though. I'm sure the relicense was an attempt to increase Elastic NV's revenues from SaaS by locking out competitors from using their same codebase (from public financial filings, Elastic NV is not profitable so they are probably looking to become so). But open source also attracts new customers and improves the pro…

It’s moves like this that have made me go from largely neutral in this fight to actively hating elastic.co. It’s their fault for not differentiating their offering enough. When I looked at logz.io, I spent hours trying to get it to work and ultimately gave up, irritated that my seemingly plain vanilla use case (send ubuntu journald logs to ES) wasn’t as straightforward as I would’ve liked. (I’m aware they aren’t affi…

People give Amazon flack but they offer solid support with reasonable escalation when you have an issue. Imo it's a bit sad Elasti Co couldn't out compete ES on their own product.

When AWS released ES you couldn't even dynamically scale cluster nodes and you had to use Amazon's special library to sign requests for IAM

There are other companies that run curated & managed SaaS on providers like AWS, GCP, etc that offer better services than the native ones. For instance, MariaDB SkySQL offers DBAs with their product and will help tune the DB for the workload vs AWS where they offer limited app-level support outside suggesting things like Performance Insights. When I looked, SkySQL was also a bit cheaper than AWS RDS for comparable hardware

Re: Official Elasticsearch Python library no longer works with open-source forks

#127
post #63

Good? Amazon deserves no support in branding their version 'open'.

You do realize that Amazon would have been happy selling hosting for the official Elastic code until Elastic forced them into a situation where the pull the rug out of all of their customers or fork? Amazon is actually the more open company when it comes to Elastic at this point. Open source does best when it’s not the meal ticket of the company developing it.

It's a bit clunky, but Amazon's fork also comes with security by default. ES open-by-default has caused breaches for years. Amazon's is a bit clunky to setup but at least comes with defaults where you are less likely to leak your data

Re: Official Elasticsearch Python library no longer works with open-source forks

#128

Elastic, like others at the time, have used open source to their advantage - to start. The obvious one is that it is built around the Apache Lucene, and I have no doubt that this is one of the reasons ES ended up being initially released under the Apache license. Secondly, being released under a permissive open source license definitely helped with its adoption. I was working as a senior developer in a UK Government…

I keep hearing the AGPL-makes-corporations-wince argument, and I'm curious: what are the reasons given?

Does the AGPL really place such burdens on the organization such that the benefits of a locked-open, community-guaranteed (albeit popularity not guaranteed) technology aren't worthwhile?

Or is it kind of a cargo-culting and cultural-norms phenomenon where people don't use AGPL projects because they've heard that other people don't use them, thus continuing the cycle?

Re: Official Elasticsearch Python library no longer works with open-source forks

#129
post #51

Earlier quoted context omitted.

Yes I know for sure. Postgres search is essentially an easier to use regex engine. If you have a recall-only use case and/or a small dataset, then that works great. As soon as you need multiple languages, advanced autocomplete, misspelling detection, large documents, large datasets, custom scoring, etc you need Solr or ES.

While I don't doubt that you know your usecase and weighed/tried the option. > Postgres search is essentially an easier to use regex engine. I'm not sure exactly what you meant to convey here, but if you're searching with LIKE or `~` you're not doing Postgres's proper Full Text Search. You should be dealing with tsvectors[0] > As soon as you need multiple languages Postgres FTS supports multiple languages and you can…

[deleted]

Re: Official Elasticsearch Python library no longer works with open-source forks

#130
post #128

Elastic, like others at the time, have used open source to their advantage - to start. The obvious one is that it is built around the Apache Lucene, and I have no doubt that this is one of the reasons ES ended up being initially released under the Apache license. Secondly, being released under a permissive open source license definitely helped with its adoption. I was working as a senior developer in a UK Government…

I keep hearing the AGPL-makes-corporations-wince argument, and I'm curious: what are the reasons given? Does the AGPL really place such burdens on the organization such that the benefits of a locked-open, community-guaranteed (albeit popularity not guaranteed) technology aren't worthwhile? Or is it kind of a cargo-culting and cultural-norms phenomenon where people don't use AGPL projects because they've heard that ot…

In one of the of the organisations I mentioned, they had a strict policy against using any GPL dependencies, let alone the AGPL. I tried discussing this with the legal policy person but they were quite resolute - they feared it’s use could “infect” our code and therefore must be avoided.

I frankly doubt there’s any sort of cost-benefit analysis being done here. Certainly in my experience it was much more driven by legal uncertainty and risk-aversion.

Post reply on HN