Introducing: A search & relevancy assessment from engineers, not theorists. Learn more
Jan 22, 2021
Nick Zadrozny
•
Letters
•
9
min read
Announcing a major change in the industry: Elastic is ending the open source licensing for future versions and AWS announces its forks of Elasticsearch and Kibana.
Last week, Elastic announced that future releases of Elasticsearch and Kibana will be changing their licensing. The current 7.10 release will be the last under the open source Apache 2.0 license. Future versions of Elasticsearch and Kibana will be dual-licensed under the $1’source-available’ Elastic license and Server Side Public License (SSPL).On Thursday, AWS announced it will maintain its own fork of Elasticsearch.Our customers naturally have questions about what comes next. After a week of study, and consulting with industry experts, we’re now sharing our understanding of what possibilities exist to ensure continuity of high quality service for our customers.It’s worth emphasizing: nothing changes immediately, nothing changes retroactively. All Bonsai clusters are running on Apache 2.0 licensed releases, and will be supported indefinitely, according to our normal support schedule.
While there are plenty of subtle combinations, we have identified four paths moving forward.
Insomuch as a market of providers exists around Elasticsearch, and insomuch as that market can credit its existence to Elasticsearch, Elastic has taken the position that providers selling Elasticsearch as a service should exist in a more ‘collaborative’ relationship with them.The SSPL identifies such commercial providers. It doesn’t exclude them from offering a paid service, but it does provide a unique copyleft-style stipulation. Providers of a paid service are required under the SSPL to release their entire management stack under the terms of the SSPL.This is a bold requirement, and I am not aware of any company who has decided to go this route under the SSPL. It’s plausible that many companies would find this kind of stipulation to be completely infeasible.For a small team like ours, who places much more value on the humans within the service than the code that supports them, it’s not entirely impossible.It’s true that we have good and innovative technology. Our customers certainly would not enjoy our service if our technology was bad—or we would find it unprofitable to support. But our customers don’t choose us because of our technology. They choose us because of our people, and our values. Because we are committed to their availability and performance, and because we make ourselves available to give incredible advice and guidance.If we went the SSPL route, we may well be the first company to do so. It’s a novel situation and a novel license whose language is not without problems. We’re engaged with experts in the relevant IP law as we consider this path.Complying with the SSPL would be a gesture to take Elastic at face value, and continue participating in an ecosystem that they’ve helped create, within terms they find agreeable. However, given that the license’s language is problematic, we think this is an unlikely direction for us.
As a prominant alternative in their FAQ, Elastic invites providers to reach out to negotiate custom license terms.This seems like a completely sound and viable business decision, especially when customers strongly care both about future access to the latest releases of the mainline Elasticsearch product, and also having access to more diverse and competitive service providers.While researching the eventual decisions of MongoDB providers in 2018 and 2019, I could only find examples of companies coming to an agreement with MongoDB.We’ve long been open to the idea of working more closely with Elastic. In fact, Bonsai was a member of Elastic’s own nascent partner program back in 2014 and 2015. With circumstances changing in the market, we’re open to the possibility of new opportunities.Toward that end, we have been in touch with Elastic to discuss and understand their goals, and explore possible licensing terms.
One of the core premises of open source is that, once opened, a project cannot be closed again. Any company or entity who decides to take their own proprietary path leaves the community with a choice: to follow that path, or to go their own.It seems eminently likely — and eminently reasonable — that certain businesses within the larger Elasticsearch ecosystem will remain committed to the ideal of preserving and maintaining an open source alternative.It is certainly true that Elastic employs a large number of core Elasticsearch engineers who can continue contributing bug fixes and new features. However, in our experience, current versions of Elasticsearch are quite mature. Even a relatively feature-frozen fork, focused on bug-fixes and security patches, can still be incredibly useful and competitive into the future. It would take a helluva lot of work, or a revolutionary idea, or both, for a brand new project to overtake what is available in Elasticsearch 7.10.In this section we’re intentionally focusing on a community-led effort. That’s because sophisticated open-source consumers have long paid attention to governance. This is an important aspect of open source that is not reflected in the license itself.Elastic and AWS have provided a fresh and poignant case study for the community on governance. When a project is controlled exclusively by a single commercial interest, then the market challenges and struggles and forces that entity faces become consequences that its community of users and contributers have to reconcile with.A community-led effort to rename, maintain, and enhance the Apache 2.0 branch of Elasticsearch would be in the interests of companies’ who value a more diverse selection of Elasticsearch service providers. It would also go a long way to reassuring a wider industry about the continued viability of open source.
AWS has since announced their intent to maintain an Apache 2.0 licensed fork of Elasticsearch. This is good news for customers of AWS’s managed Elasticsearch service who would like an assurance of continued future viability of that service. In those terms, it seemed clear from the beginning that AWS would likely pursue their own open source fork.With this project officially now available, we will be giving it serious consideration. Particularly if there is some opportunity created here for meaningful partnership with a broader community, alleviating some of the concerns of using a project that’s controlled by a single entity.
New licenses will apply to new releases, and it is a rare deployment that absolutely needs to be on the bleeding edge. Licensing changes here only have urgency insomuch as your app needs new features or specific bugs fixed. In practice, urgent bug-fix releases are, thankfully, increasingly rare in a mature open source technology.Indeed, rather than rushing to newer versions, many of our customers find value from the stability of long-term support on older versions, which is a feature that our Business and Enterprise clusters enjoy. While a majority of Bonsai clusters are deployed on Elasticsearch 7.x, we have a healthy mix of clusters deployed onto versions as far back as 1.7.5.The Elasticsearch codebase has been around a long time now, and after nearly a decade supporting it, we are quite comfortable with the level of maturity and stability offered in current versions. We feel comfortable that this affords us and our customers plenty of time to thoughtfully consider and navigate the best path for supporting future releases.
We don’t really need to make the case here that Elasticsearch is an incredibly valuable and innovative piece of software.However, that value doesn’t exist in a vacuum. There’s a lot of work that happens between the search engine at the bottom of the stack and the end-user perusing the results of their query at the top. Within an ecosystem, the diversity of business and end-user needs are what create the opportunities for creative solutions and a diverse marketplace to arise and flourish.At Bonsai we’re clear that we didn’t invent the search engine — indeed, we have deliberately resisted building our own! Rather, we focus on providing high quality management and scaling, encompassed within our “Evergreen” promise: that our customers’ clusters are never anything but healthy and fast; if something is wrong, it’s our responsibility to fix.We started offering our managed Elasticsearch services in early 2012, before Elastic, Inc. even existed. Our best and only understanding of our responsibilities at the time was the project’s Apache 2.0 license, and the emergence of a thriving ecosystem around it. We dove into the deep-end of scaling and supporting Elasticsearch through its at-times troubled adolescence. And as Elastic the company grew, acquiring another startup to form their Elastic Cloud platform, and as AWS made their entry, we didn’t worry too much. We remained committed to supporting our customers as our first-to-market position evolved into a niche of quiet specialists.
At Bonsai our stakeholders are our customers and our team. We remain focused on our customers and providing them the most productive tools and software available so they can stay focused on the work of delivering great search experiences. Tools and licenses and communities shift and evolve, but our commitments will not change.Whether you’re a customer, or a member of the community, I would love to hear from you! Drop me a line any time at nick@bonsai.io.
Schedule a free consultation to see how we can create a customized plan to meet your search needs.
