What do organisations gain from standardising on OpenTelemetry rather than a vendor's agent?

Question

Accepted Answer

Technically: no vendor lock-in, uniform instrumentation, support for many programming languages and less integration effort. Organisationally: one standard across teams, better data quality and faster adoption of observability.
Technical side. Instrumentation is the expensive, long-lived part of an observability programme — it lives in your source code, in every service, forever. Making that part vendor-neutral means the back end becomes a swappable component: you can change platform, run two in parallel during a migration, or route different signals to different destinations, without touching the applications. Broad language support matters for the same reason — a polyglot estate otherwise needs one vendor agent per language.
Organisational side. When every team emits the same signal names, attributes and formats, data from different services is comparable, so a shared dashboard or a cross-service trace actually works. That uniformity is what "better data quality" means here, and it is why new teams can adopt observability quickly: the conventions and tooling already exist rather than being reinvented per team.
In one sentence: OpenTelemetry is an open standard that connects otherwise incompatible systems — which is the same reason organisations standardise on any protocol.
Go deeper:

OpenTelemetry semantic conventions — the agreed attribute names that make data from different teams comparable.
 Chris Aniszczyk (CNCF) — OpenTelemetry Is the Kubernetes of Observability — the vendor-neutrality argument from the foundation that hosts the project.