Amazon has recently announced the general availability of OpenSearch 1.0, the Apache 2.0-licensed fork of Elasticsearch that was created after Elastic changed their license.
OpenSearch provides compatibility with Elasticsearch 7.10.2, the version from which it was derived. The GA version adds a few enhancements since the beta, including support for the ARM64 architecture, artifacts for embedding of OpenSearch and OpenSearch Dashboards into existing products and services and data stream support for OpenSearch Dashboards.
Amazon started and maintains the fork but it is not the only company participating in the project. With the GA announcement, Kyle Davis, senior developer advocate at AWS, started a thread on Twitter that includes the press releases and comments from the companies that participated in the project, including Bitergia, Logz and Bonsai.
Sumant Dubey, director of engineering at MontyCloud, added:
OpenSearch - AWS led, community-driven, search and analytics solution derived from ElasticSearch is in GA now. Importantly, the team states -"You can now use OpenSearch with confidence that it's free of proprietary code and references."
In a "What is OpenSearch?" page, Elastic argues that Amazon Elasticsearch, AWS managed service, will not deliver current or future releases of Elasticsearch and migrations will become more difficult:
Amazon Elasticsearch Service is based on an old version of Elasticsearch (...) Customers choosing to stay on Amazon's service will no longer benefit from patches and performance enhancements delivered into Elasticsearch and Kibana. In addition, Elasticsearch deployments on customer premises and on other clouds will no longer be the same as Amazon's service.
Elastic highlights as well that the open source OpenSearch project and the Amazon managed service have major differences:
Today, the Amazon service includes several proprietary features that are not available in open source. These include recent announcements like AWS UltraWarm and Auto-Tune, which are proprietary features not available in the forked open source projects. We expect this to be the case moving forward as well, and that the Amazon service will not be the same as the OpenSearch project.
In a separate article, the developers at Amazon behind the OpenSearch project explain why they forked as well the clients:
Many developers who use Elasticsearch and OpenSearch in their applications also make use of the open source client libraries maintained by Elastic (...) Over the past few weeks, Elastic added new logic to several of these clients that rejects connections to OpenSearch clusters or to clusters running open source distributions of Elasticsearch 7, even those provided by Elastic themselves.
User Buckwhal on Reddit suggests that stability is more important than new features for the new project to succeed:
What I want to see is lots of stability and performance fixes. Make patches easy. The fork that hits the "boring and stable" mark first will be the one I use. Think of it this way. If Postgres split into two forks, one started adding junk features, the other focused on reliability and maturity, which would you choose? Pace of development has to mean more than just feature creep - it has to mean maturity.
Both OpenSearch and OpenSearch-Dashboards, the open source visualization dashboards for OpenSearch, are available on GitHub, including the project roadmap. The GA packages can be downloaded from the OpenSearch site.