Opening the code of our X-Pack features

This is incredibly user-hostile, and if you read this expecting this is an open-source release, consider yourself clickbaited.<p>Want to contribute to the open-source version of Elasticsearch? Want to ensure you&#x27;re running an open-source database without running a custom EULA past your legal department?<p>Well, make sure that after 6.3 is released, you don&#x27;t accidentally download the default distribution, or browse the official Github repository, or clone from Github, as all of those will have components subject to an as-yet-unreleased, non-OSI-approved EULA (see the final paragraph in <a href="https:&#x2F;&#x2F;www.elastic.co&#x2F;products&#x2F;x-pack&#x2F;open" rel="nofollow">https:&#x2F;&#x2F;www.elastic.co&#x2F;products&#x2F;x-pack&#x2F;open</a>), which may have clauses that trigger liability to Elastic if you accidentally flip a switch or look at the wrong thing. (I am not a lawyer, this is not legal advice, but I shouldn&#x27;t have to be to know if I can use software freely, and I can only guess worst-case scenarios because the terms aren&#x27;t released.)<p>If Elastic were truly committed to transparency, they would release the terms of their new EULA immediately, provide a way to access the head of the open-source portion of the repository without accepting the EULA, and make it clear what the pricing ramifications are if one opts into certain flags or reads certain files in a commercial capacity. (Pricing requires a custom quote, but a quick Google search suggests that the lowest tier in which REST and node-to-node communications are encrypted begins in the tens of thousands of dollars - not the kind of thing you want to take lightly.)<p>Now more than ever, it&#x27;s important that projects like <a href="https:&#x2F;&#x2F;github.com&#x2F;floragunncom&#x2F;search-guard" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;floragunncom&#x2F;search-guard</a> , a free and open-source (Apache 2.0) alternative to some of these X-Pack components, are supported, and that the word is spread around them. (EDIT: Yes, they have commercial components, but those are in a separate repository, so you avoid any entanglements. Why isn&#x27;t Elastic doing the same?)<p>And hopefully, if Elastic doesn&#x27;t maintain a fully-OSS repo, someone will create and maintain a friendly fully-OSS fork that can be combined with third-party software to carry on the legacy of this otherwise excellent database in the right way.

Yeah so has anyone actually tried to get ElasticSearch up and running lately? I just tried and had a terrible time, despite the fact that I was using ElasticSearch + Kibana, and it was dockerized, and it was on Kubernetes (there&#x27;s more complexity, yes, but all those tools make deployment simpler once you understand them, not harder -- writing a pod resource config to get a thing running means I don&#x27;t have to run around my system changing settings, I just put all of it in one place). XPack was just another stumbling block while trying to get everything running.<p>The combination of lack of documentation, inconsistent&#x2F;changed configuration (ENV vs YAML vs values that just don&#x27;t exist anymore), breaking changes between versions that rendered Kibana completely useless, and the recent (?) removal of plugins that expose web APIs (so I couldn&#x27;t use something like elastic-head. This is all in Kubernetes btw -- maybe it&#x27;s just that I wasn&#x27;t smart enough to get it done, but it&#x27;s so easy to write functional (if not well-configured) configurations for other databases, I was at a loss for words when nothing I tried worked right.<p>I got so angry trying to set up ElasticSearch that making a F&#x2F;OSS competitor is now #2 on my list of projects-to-do-next. I&#x27;m sure the thought is naive but I need to find out for myself that there&#x27;s no easier way.<p>Imagine if the team behind Prometheus had focused on search instead of metrics? That&#x27;s the kind of tool I want to use. A tool as focused, easy to start, clearly documented, and straightforward as prometheus.

Background: They introduced X-Pack by bundling it with the default distribution as a time-limited trial without explicitly stating that it is just a demo. People who did the update were bitten weeks later when it just stopped working because the demo license had expired. [Documentation of this was ridiculously bad and I only learned through this post that there apparently was some way to get a free license (maintaining an instance for a 501(c)(3), I just assume we&#x27;d have qualified).]<p>This looks like an attempt at fixing their karma balance, but until I&#x27;ve reviewed the EULA I am pessimistic about the value of &quot;allowing for some derivative works&quot;. And I don&#x27;t really get the &quot;allowing for some [..] contribution&quot;. &lt;zyn&gt;Is a patch that improves performance by 10% welcome but I&#x27;ll have to pay them to make them accept a patch that improves performance by 100%?&lt;&#x2F;zyn&gt;

The important part is near the bottom, free components of X-Pack will no longer require the cumbersome registration process. Also of some concern is that extra care will be required to find a version of the software that is Apache 2.0 licensed as the proprietary licensed X-Pack components will be included by default in the code base instead of as a separate install.<p>---<p>&quot;Also, X-Pack features will now be bundled into the default distribution. All free features are included and enabled by default and will never ‘expire’, and commercial features are opt-in via a trial license. The license for free features never expires,you no longer need to register to use these capabilities. In addition to this, an Apache 2.0-only distribution will be created for download.&quot;

Here we have a company that is simply opening up visibility of the code of their commercial offering, which will enhance customer relationships vs. keeping the code black box —— and it&#x27;s observed as user-hostile?<p>Open core isn&#x27;t evil. Companies need to make money, and shouldn&#x27;t have to choose between fully-open-source vs. closed-source.<p>Fully-open-source companies have a really hard time of building a good company, because despite the great work they put out into the world, other enterprising cloud companies can build closed-source cloud services around it. For example, I&#x27;ve paid Compose.io and other companies real money around MongoDB, and never a cent to MongoDB the company. Same goes w&#x2F; Docker, who has struggled to build a great business because they open-sourced so much of their value.<p>So yeah, Elastic is trying to make it more likely that you&#x27;ll choose to buy a license, because the health of their business depends on getting paid customers.

Eleven uses of the word free, all used in the gratis, not libre, sense of the word.<p>&#x27;Open&#x27; is in the same category for me now as &#x27;cloud&#x27; -- too nebulous, too little consensus on what it actually means, often used in a &#x27;don&#x27;t worry about the details&#x27; hand-wavy way.

This thing of having the source &quot;out there&quot; (but not OSS) worries me and is very confusing for users because it creates dangerous grey areas.<p>If you think like me, check out the <i></i>actually<i></i> FOSS(GPLv3) alternative to X-Pack security I created:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;sscarduzio&#x2F;elasticsearch-readonlyrest-plugin" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;sscarduzio&#x2F;elasticsearch-readonlyrest-plu...</a>

Their licence is still proprietary, though. At the least people with a technical curiosity in X-Pack will be able to install it. Technically it&#x27;s illegal, but Elastic probably doesn&#x27;t care until the moment they start gaining momentum.

I&#x27;m a cynical es admin, but I&#x27;m pretty sure this is just a polite way of saying &quot;you&#x27;re still gonna need support&quot; more than it is &quot;it&#x27;s good to go, run it yourself!&quot;<p>Between ES and RMQ, I find myself running software written before the cloud was big, but trying to be the drivers of the cloud -- those two pieces consume more resources, both physical and operational then the rest of our stack three times replicated, combined.

Dear Elastic people reading this thread: We hope you wont do evil with your licence.<p>If you don&#x27;t do evil (e.g. write anything that could mess other people IP when working with Elasticsearch, prevent compatibility with other products, scare people from even looking at these codes or at the whole repository ) it will be.. a setep in the right direction.<p>If you do evil it will cost you dearly in the end, with FUD about companies should be enormously weary of having anyone even look at those repositories.<p>Hope we&#x27;ll continue to cheer and celebrate your achievements.

Saw this in my inbox yesterday and was excited... until I read it. Nothing changed. Ultimately Elastic is still looking for a revenue model <i>beyond consulting</i> that makes sense.<p>Our company needed to build a bunch of this ourselves, simply because of the bundling cost. At the end of the day many, many organizations would love the ability to PURCHASE A SINGLE PLUGIN not all of x-pack. Ignoring the cost - the reality is that x-pack is useful in large enterprise, and a reasonably tiered model to develop against would help startups get going, and tie us in for the long-term. Instead, we built our own.<p>The sheer number of times I&#x27;ve had direct conversations with people at Elastic (from CEO down) about this makes me cringe. We rely on Elastic. We currently have our own ecosystem around it. We&#x27;re also going to (over time), probably have to open source bits and pieces, so that others don&#x27;t have the same pain.

Being honest X-PACK is just a pain for the small developer, it should be opt-in by default and only installed by the user not the other way around, I would probably be using some parts of it like that.<p>I used to love Elastic even have a couple of small pull requests merged. I&#x27;ve felt bad for using such an awesome software for free and not giving back. But X-PACK changed that, I am now a bit afraid of putting my trust in the software and the first thing I do is uninstall X-PACK when I get my hands in an elastic cluster or github repo that carries it.