Hey everyone!
First of all, thank you for the amazing work on Zammad! It’s a fantastic tool and we really enjoy using it.
We’ve been running into some issues with current OpenSearch versions and Zammad. We know it’s technically not supported yet, but we are actually considering building that support ourselves (to have it alongside Elasticsearch).
Before we get started, I wanted to check in: What is your long-term strategy regarding OpenSearch? Also, if we were to provide a PR for this, would it be something you’d be interested in merging, or are there specific reasons to stick exclusively to Elasticsearch for now?
Would love to hear your perspective!
Cheers
Thomas
We currently don’t have a long-term strategy for OpenSearch. However, we plan to use vector search from ES. From my basic research, I understand that it works differently in OpenSearch and ES. But I am not a developer.
This could cause problems in the future if the vector search works completely differently in OpenSearch than in ElasticSearch. Could you please explain why you chose OpenSearch over ElasticSearch? And why might other community members want to do that?
Hi Gerrit
Thanks for the quick and transparent feedback!
As far as I can see: Yes, there are differences in Vector Search.
Regarding the implementation: Yes, I think they are not identical between Elasticsearch and OpenSearch. They differ in their mapping definitions (dense_vector vs. knn_vector) and the JSON structure of the search queries.
If you plan to use that, I think some kind of abstraction layer would have to handle this. To be honest: This will be some code to handle it, yes.
To answer your questions about why we (and potentially many others) prefer OpenSearch:
-
License
Since Elastic changed its license to the SSPL (Server Side Public License), it is no longer considered “Open Source” by many organizations and Linux distributions (like Debian or Fedora). OpenSearch is Apache 2.0 licensed, which is a hard requirement for many enterprise environments and public sector projects that avoid “source-available” software. (There has been a long discussion and fight on this issue: OpenSearch (software) - Wikipedia
At the end: OpenSearch is a fork of ElasticSearch that occured due to licensing issues.
-
Managed Services & Cloud Infrastructure
Since Elastic moved to the SSPL, the licensing landscape has changed significantly. The SSPL is a strong copyleft license that specifically targets anyone offering the software as a service. It mandates that if you provide the functionality of Elasticsearch to users as a service, you must release the source code of your entire management and infrastructure stack under the SSPL as well.
For many service providers, hosting companies, and even internal platform teams, this creates a significant legal risk and a “copyleft trap” they want to avoid. This is a major reason a shift toward OpenSearch happens (as far as we can see). Supporting both would broaden Zammad’s adoption in environments either cloud-based or on premise.
wdyt? 
Best regards,
Thomas
I believe OpenSearch was supported prior Zammad 7. But I’m unable to find any leftovers in the Systemadministrator Documentation. Has something changes here…?
Nevermind, after looking it up it seems to be Elasticsearch-OSS which seems to be discountinued.
OpenSearch 1 and 2 include a compatibility mode (override_main_response_version) that allows the engine to mimic an Elasticsearch version response to prevent version check failures. This is exactly where the crash occurs: zammad/lib/ai/vectordb.rb at 5bb84828f87294d127078f729cddff5c99eeace3 · zammad/zammad · GitHub
However, this configuration will be removed in OpenSearch 3.