How do their APIs compare?

Based on what's in the retrieved data, I have direct evidence about OpenSearch's API stability/versioning conventions, but only indirect/thin evidence about Quickwit's APIs (mostly protocol surface mentions like the Elasticsearch-compatible API and REST endpoints in the changelog). Let me lay out what's actually supported, and flag where I'd need to search further for a fuller comparison.

OpenSearch: formal API classification system

OpenSearch has an explicit, annotation-driven backward-compatibility framework described in the Developer Guide:

• @PublicApi (or documented as @opensearch.api) — marks Developer API components (interfaces, foundational classes like REST Action Handlers, Plugin/Extension frameworks) that external implementations may extend, and which carry backwards-compatibility guarantees [DEVELOPER_GUIDE.md:L597-L602].
• @InternalApi (or @opensearch.internal) — or simply the absence of any annotation — signals a component should not be extended externally and offers no compatibility guarantee, i.e., it "may change at any time" [DEVELOPER_GUIDE.md:L601-L603].
• @ExperimentalApi (or @opensearch.experimental) — for APIs intended to eventually be public but not yet stabilized; these "may change at any time (major, minor or even patch releases)" [DEVELOPER_GUIDE.md:L605-L608].
• @DeprecatedApi — layered onto @PublicApi classes/methods that are being changed or removed across major versions [DEVELOPER_GUIDE.md:L603-L604].

Separately, OpenSearch distinguishes a User API layer — the Query DSL, field mappings, and endpoints like _search/_cat — which is committed to semantic versioning, requiring Version checks (e.g. Version.onOrAfter, Version.before, implemented in [buildSrc/src/main/java/org/opensearch/gradle/Version.java:L127-L141]) for any user-facing change across minor versions, plus a >breaking PR label and deprecation-log entries via DeprecationLogger [DEVELOPER_GUIDE.md:L610-L616].

OpenSearch also runs automated API compatibility checks using japicmp as a Gradle task, comparable against the latest released version or a specific version via a system property [DEVELOPER_GUIDE.md:L629-L646].

Quickwit: what's visible in the data

The retrieved Quickwit material doesn't include an equivalent formal API-stability policy document. What is visible:

• Quickwit exposes an Elasticsearch-compatible REST API with scroll, search_after, multi-index search, _field_caps, and various query types (exists, multi-match, match phrase prefix, etc.), plus OTLP-over-HTTP and Jaeger REST endpoints for tracing — all listed as changelog additions rather than a stability contract [CHANGELOG.md:L280-L288].
• The CLAUDE.md dev guidance emphasizes testing through the real API surface (HTTP/gRPC server, REST layer) rather than bypassing it [CLAUDE.md:L93-L98], which is a testing-practice note, not an API compatibility guarantee.
• The quickwit-actors crate explicitly states its API "may change in the future" [quickwit/quickwit-actors/README.md:L1-L5] — an internal-crate disclaimer, not a public API policy.
• quickwit-aws's error module shows internal retry-classification logic (is_retryable) [quickwit/quickwit-aws/src/error.rs:L76-L85] — implementation detail, not API surface.

Comparison summary

• OpenSearch has a codified, three-tier API compatibility model (Data/Developer API/User API) with annotations enforced in source and automated checks (japicmp), reflecting its maturity as a long-supported distributed system with external plugin/extension ecosystems.
• The Quickwit data retrieved here shows feature-level API surface (Elasticsearch-compatible endpoints, OTLP, Jaeger) and per-crate disclaimers (e.g., quickwit-actors) rather than a documented cross-cutting versioning/stability policy — I don't have direct evidence one way or another about whether Quickw