Live data from Hacker News

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

github.com

111–120 of 144 posts

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

#111
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 department in 2013 and we had need for a full-text search engine for a project - and even before v1, ES was a contender, and it was eventually selected once v1 was released. This was largely due to a) ease of set-up/use and b) it’s release under an open source license. If it had been under AGPL, would we have still used it? Yes, probably - our specific use case wouldn’t have been affected by such a license, and the dept. was relatively open to more complex OSS licenses - but I have worked for several other orgs. where even just the AGPL would have resulted in a hard “no”.

Thirdly, ES has had contributions from a wide range of people. I honestly don’t know how I’d even begin to evaluate how much value ES has got from community contributions, but I feel it’s likely to be greater than the costs of managing those contributions.

But of course eventually Elastic got funding and had shareholders to placate. I don’t really have much sympathy for them about this conflict - their early choices were in part clearly made to maximise their value, and they decided to cash in on that value at a later date - the fact that those decisions had implications for their value should have been somewhat obvious to any investor who did any due diligence. I’m still not entirely convinced that the open source model is antithetical to commercialisation, but I think it does highlight how early decisions around OSS licensing can affect such processes.

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

#112

Earlier quoted context omitted.

Likely! It worked against SEGA, in the Sega v. Accolade case. Unlicensed Accolade (and later, SEGA Dreamcast homebrew games) displayed a Sega copyright logo because they were (believed to be) needed to run arbitrary executables.

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?

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

#113
post #26

Earlier quoted context omitted.

Heaven forbid a FAANG doesn’t touch your code. Look at all the exposure you’ll miss out on. They might actually have to spend resources to write and maintain the code themselves, instead of open source maintainers begging for scraps [1]. The horror. The homebrew maintainer couldn’t even get hired at Google [2] if I recall, even though they’re big fans of using the tooling internally! [1] https://arstechnica.com/infor…

Who said anyone was doing anything for exposure, either? I think open source is doomed if people fail to understand that when you release open source code under open source licenses, your users don’t owe you anything, and in return, you don’t owe your users anything either. As far as I’m concerned, I don’t even really care that much about whether or not people adhere to the licenses I use for the most part. Nobody is…

That sounds a bit like Thatcher 'there is no society' - society, I am not sure if open software can survive without permanence, trust and reliability (from the developer and customer side, not the code basis).

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

#114
post #96

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…

There are lots of open source projects that aren't bait and switch, like the Linux kernel, or Python. So I would encourage you to reconsider a blanket fork-everything policy and at least contribute to the projects that aren't backed by VC-funded companies and instead have a diverse community of contributors with multiple copyright holders.

Yeah I should have been more specific. I’m just whining about the open source as a business model type of projects.

My general approach has been, when I’m capable and have the time to, to fix any issues or obvious feature deficiencies that I come across in open source projects that I use. I still do that, but I now only contribute my changes back to projects that seem more trustworthy.

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

#115
post #15

Earlier quoted context omitted.

If they don't like it, they shouldn't have licensed their software under a free software license. This was an entirely foreseeable consequence. They only have themselves to blame. The AGPL generally fixes this perceived problem, but means that several large players (like Google) will never touch your code with a ten foot pole, let alone improve it. So, there's some difficult decision-making at the inception stage of…

> This was an entirely foreseeable consequence I disagree. I think it was hard to know that many years ago (10+?) how things would turn out. Especially not " entirely foreseeable." There's a cognitive bias called "hindsight biasy", namely "the common tendency for people to perceive past events as having been more predictable than they actually were", https://en.m.wikipedia.org/wiki/Hindsight_bias I agree with you abo…

> I think it was hard to know that many years ago (10+?) how things would turn out.

The long-term commercial advantage in Free Software being for the largest established players with revenue mechanisms centered around services rather than selling software licenses was widely recognized, with many observers independently coming to the conclusion, from at least the mid-1990s.

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

#116
post #64
post #26

Earlier quoted context omitted.

Who said anyone was doing anything for exposure, either? I think open source is doomed if people fail to understand that when you release open source code under open source licenses, your users don’t owe you anything, and in return, you don’t owe your users anything either. As far as I’m concerned, I don’t even really care that much about whether or not people adhere to the licenses I use for the most part. Nobody is…

An important distinction of Linux kernel development from most open source contributions is that the companies contributing code typically make their money off of selling hardware which must run or work with linux to be successful. These companies are all financially incentivized to keep the Linux collaboration successful.

Almost every open source package has a model where multiple contributors make money off something else. Usually that something else is software or hardware that is built with the open source package.

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

#117
post #4

I use to be a huge proponent of Elastic.co for search. I paid for their Elastic Cloud Enterprise product to offer an internally hosted Elastic as a Service. We ran a proof of concept with the the open source Elastic Stack before requesting the funding to get commercial support and the extra management features. I'm not sure I can recommend them anymore. The company doesn't seem to understand their customer's journey…

It is easy to judge another’s actions from afar when it’s their meal and roof they’re working for. It’s okay for Amazon (a trillion dollar company) to make money off of their work but not themselves? Imho, the problem isn’t “well it’s not open source anymore then.” The problem is people who give more weight to a religion/philosophy than sustainability. Who cares if it’s open source if the people developing it can’t s…

But you can actually multi-licence code. Put it under GPL and offer other licencing agreements for commercial actors. Copy-left inhibits commercial exploitation while your business licenses get you the money. That is entirely possible.

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

#118

Earlier quoted context omitted.

> This was an entirely foreseeable consequence I disagree. I think it was hard to know that many years ago (10+?) how things would turn out. Especially not " entirely foreseeable." There's a cognitive bias called "hindsight biasy", namely "the common tendency for people to perceive past events as having been more predictable than they actually were", https://en.m.wikipedia.org/wiki/Hindsight_bias I agree with you abo…

You are right: none of it was foreseeable, but rather, an expected outcome. In case of success, which Elastic has certainly achieved with ElasticSearch, it is fully expected that other companies will jump in on the bandwagon and try to profit off of it too! And as a company, you hope for success, or rather, that to play out, but just that you'd be the go-to for earning the most off the product you created. While not…

> Where it gets complicated is that nobody expects to earn orders of magnitude less from a product they created than others relying on it.

And this is where the problem basically is. The core philosophy of open source licensing is that the creators who use it don't particularly care beyond compliance with the terms of the licenses (eg. Source distribution for copy left licenses)

If it turns out you *do* in fact care, then Open Source licenses are not a good fit for you. If you still go ahead release under Open Source and then change later, don't be surprised to be called out for bait and switch manipulation.

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

#119
post #74

Earlier quoted context omitted.

Elastic's main selling point is not so much the full text search. The search is what it does but most of it's value is centered in the management/scaling/monitoring of full text search over many machines. I love Postgres but it's "clustering" story is definitely not as user friendly.

Is there a real scaling? Like increasing node count on indexing latency or CPU metrics?

Yes. You can scale ES to fairly massive data volumes. Postgres is a very different system with different design constraints.

There are plenty of peta-scale ES clusters in the wild

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

#120

Earlier quoted context omitted.

>If they don't like it, they shouldn't have licensed their software under a free software license They or anyone else are also free to relicense their project, there's nothing wrong with it at all and anything under the old license is still what it was before. It seems kinda strange to demand that someone operate under some license in perpetuity, there is no such rule. Licensing questions don't stop after the incepti…

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 received money for the engineering work but now had the burden of supporting their fork. The functionality code itself was not a problem, but the interfaces to the remaining kernel were a source of churn and pain.

Red Hat did the opposite. They told their customers that they can have whatever is in the upstream Kernel and they will help them upstream the necessary changes. That took markedly longer but the long term maintenance was much less effort because the in-tree code would be updated whenever an API/interface changed.

Canonical also had a tendency to happily fork of whatever project they needed to ship a fancy thing on time (think Netbook UI, think Unity etc.) and then get hit by the long term maintenance burden once upstream diverged.

Both SuSE and Canonical always found themselves in the unenviable position of having to constantly update their code and potentially seeing a competing but conflicting solution being merged upstream.

Carrying a few bugfixes or feature improvements in a local branch of a library is easy at first. But you're essentially creating technical debt which you'll need to pay off on every upstream change, every security fix etc. Most companies see value in developing features for their main application, not in maintaining internal forks of open source libraries.

Post reply on HN