Conflict of interest between open source Elasticsearch and closed source Swifttype?

[softwaredoug (Doug Turnbull)]

First congrats on the acquisition!

Second, I wonder how this will work in practice? Are there conflicts of interest? Could such conflicts of interest threaten the health of the Elasticsearch project?

Imagine a search feature. If I put my open source hat on, I want that search feature to be as usable as possible in the open source Elasticsearch. I want to advocate for usability -- better than the proprietary options! For example, I'm personally passionate about building more in the Elasticsearch ecosystem, such as our LTR plugin and building tools that make that easier.

However, if you own a search product, wouldn't you rather put that feature in your closed source product? Because that's what makes you money?

Since Elastic controls all contributions to Elasticsearch, this largely puts Elastic in the drivers seat to resolve this conflict of interest. Which is concerning as Elastic makes $ from Swifttype.

Perhaps I'm not seeing the vision here, so I'll ask the question what the ongoing vision will be for Elasticsearch vs Swifttype? Maybe it's not a fair comparison, because people will gravitate towards plug-and-play, bottom of the market, with Swifttype and harder custom work will continue to be done in Elasticsearch? (But still we should be making Elasticsearch plug and play for the right use cases!)

Thanks
-Doug

[kimchy (Shay Banon)]

Thank you for sharing your concerns. Open, transparent communication (where possible) is a core tenet of the project and Elastic as an organization.

Put simply, joining forces with the Swiftype team has no bearing on our position regarding open source, its import, or the way in which we build Elasticsearch, Kibana, Logstash, Beats, etc.

In fact, this is a similar concern as was expressed when we first announced the set of features that make up X-Pack. The fact that we built and offer security as a commercial feature has not prevented others from doing so, and that is part of the beauty of an ecosystem around an open source offering. This concern came up more recently, when we acquired Opbeat for APM. Like Swiftype, they were a SaaS company and we’ve open sourced the agents, server, and worked to enable users to get all the capabilities of Elasticsearch and Kibana. (It’s an aside, but you can learn more in the APM alpha blog post).

Or, consider the process of ingesting data into Elasticsearch. Yes, we create Logstash and Beats (and there are some ‘closed source’ features) but this hasn’t prevented others from building tools to ship data to ES. We didn’t steal features that enable ingestion into Elasticsearch and lock them down to only our offerings.

Elasticsearch, as an open source product, will continue to be core to our business and development — we have no plans to reduce investment, and many plans to continue optimizing and adding appropriate features. It is in our best interest to ensure the most useful products possible, available for the entirety of our community. This is the core of our business...someone downloads the Elastic Stack and is able to solve problems quickly. Keep in mind that we now (with Swiftype) offer a SaaS search solution (for site or enterprise search) and this is a different kind of user, kind of customer than those who may download and configure portions of the Elastic Stack on their own.

When it comes to 'end-to-end' offerings or 'solutions' it makes sense — in some cases — for them to be packaged and sold so that we can continue to innovate.

Imagine a search feature. If we limit its reach (when applicable to a broad base of users), then we do our users a disservice.

Swiftype is a cloud-based search platform that lets you add the power of Elasticsearch to your workflow quickly. Elasticsearch powers that workflow and we must, and will, continue to invest and innovate in the core.

And yes, I acknowledge that I am asking you to trust us. But I do believe that we have done a good job (there is always room to improve) at fostering an ecosystem around our open source offerings. If we fail in this area...we fail in the long-term.