Seven Years of OpenTelemetry: From Two Competing Projects to the Observability Standard

By Hector Hernandez Guzman

Seven years of OpenTelemetry: from the 2019 merger to CNCF graduation in 2026

OpenTelemetry was announced in May 2019. Seven years later, it graduated from the CNCF as the de facto standard for collecting telemetry:

More than 12,000 contributors from over 2,800 companies
More than 1.36 billion JavaScript API downloads and 1.3 billion Python API downloads in the year before graduation
Stable tracing and metrics implementations across major language ecosystems
A vendor-neutral protocol and Collector used by commercial and open-source platforms

The practical change matters more than the numbers. Libraries can emit telemetry once, applications can choose where to send it, and organizations can change backends without replacing instrumentation throughout their code.

That portability was not inevitable. It required competing communities to agree on common APIs, data models, and protocols, then prove those decisions across languages with very different conventions.

I joined the Python SIG in September 2019. My work later expanded into JavaScript, Node.js, browser observability, and supported Azure Monitor products. This is how the project evolved and how my role changed with it.

2019: The Merger

OpenTelemetry was announced on May 21, 2019 as a merger between OpenTracing and OpenCensus.

OpenTracing offered a vendor-neutral tracing API. OpenCensus, originating at Google, provided libraries for traces and metrics. Both had real adoption, but developers, framework authors, and vendors still had to choose between them.

The merger replaced that competition with a shared goal: telemetry should be built into software through open standards rather than added later through proprietary integrations. The new project entered the CNCF Sandbox with a broad scope that included common APIs, language SDKs, semantic conventions, a wire protocol, a Collector, and migration paths from both predecessors.

I joined four months after the announcement. My first contribution added explicit start and end timestamps to spans. I then worked on early database instrumentations for PyMongo, MySQL, and psycopg2.

At that stage, implementation helped define the standard. Decisions about span names, attributes, and error handling had to work across different libraries and eventually across every OpenTelemetry language.

The connection between specification and implementation was immediate: code revealed where an idea was ambiguous, while the specification prevented each language from inventing an incompatible answer.

2020: Building the Foundation

During 2020, the language SIGs built tracing APIs and SDKs, instrumentation libraries, exporters, context propagation, and resource models. OTLP and the Collector evolved alongside them.

The architecture separated telemetry generation from processing and storage. Applications use OpenTelemetry APIs and SDKs. OTLP provides a standard representation and transport. The Collector can receive, enrich, sample, route, and export the data to one or more backends.

OpenTelemetry architecture: applications use APIs and SDKs, send OTLP through the Collector, and remain independent of observability backends

My work expanded from the API into an early Prometheus metrics exporter and trace and metrics exporters for the Collector. Some initially used OpenCensus-compatible components while native OpenTelemetry support matured.

That experience shaped work I later did in Microsoft SDKs. Compatibility layers can solve an immediate migration problem, but only if their boundaries remain replaceable when the native implementation is ready.

I was added as a Python Approver in January 2020. Reviewing other contributions gave me a broader view of how API, SDK, and compatibility decisions affected the whole ecosystem.

2021: Tracing Reaches 1.0

On February 10, 2021, the OpenTelemetry specification reached version 1.0, stabilizing the tracing API, tracing SDK, Context, and Baggage. The Python tracing implementation reached 1.0 alongside other major languages.

This changed the adoption conversation. Teams could now depend on core tracing interfaces without expecting them to change underneath production applications.

OpenTelemetry became a CNCF incubating project in August. It already had APIs and SDKs in 11 languages, more than 3,000 contributors, over 20,000 pull requests, and production use across vendors and end-user organizations.

My daily focus was shifting toward Azure Monitor’s OpenTelemetry products. The stable tracing contract gave us a dependable base, while product work exposed practical questions around migration, version compatibility, and shipping experimental components in supported distributions.

Version 1.0 did not finish the project. It established the contract that allowed the next signals and production products to evolve without destabilizing core tracing.

2022: Metrics Complete the Original Model

In 2022, OpenTelemetry announced release candidates for its metrics specification, APIs, and SDKs. Java, .NET, and Python shipped first, followed shortly by JavaScript.

Metrics brought language APIs, SDK aggregation and views, OTLP support, Collector components, and Prometheus interoperability into one model. Traces and metrics could now describe a service using the same resource identity and semantic conventions while remaining optimized for different uses.

OpenTracing was formally archived by the CNCF. Its mission had moved into OpenTelemetry.

This milestone also brought me into the JavaScript SIG. My first JavaScript contribution added HTTP client and server duration metrics to the Node.js HTTP instrumentation. I was also leading the Azure Monitor OpenTelemetry Distro for Node.js. Rather than maintain a Microsoft-specific implementation, we improved the community instrumentation that every vendor could use.

Working across Python and JavaScript made the value of the specification concrete. Each implementation should feel natural to its ecosystem, but the telemetry it produces still needs to be interoperable.

2023: The Predecessors Wind Down

Most OpenCensus repositories were archived in July 2023. Four years after the merger, the predecessor era had largely ended.

Logs were a different story. Each language already had an established logging ecosystem, so OpenTelemetry could not simply replace it. The project had to bridge existing frameworks into a common data model while preserving trace context and resource identity. Maturity continued to vary by language.

That unevenness remains visible today. As of October 2026, Logs is still in development in JavaScript and Python, a release candidate in Go, and stable in several other languages.

OpenTelemetry signal maturity in October 2026: traces and metrics are mature while logs vary by language

I worked on Logs API integration and instrumentation for libraries such as Winston and Bunyan. The challenge was not only exporting records; it was avoiding duplicate telemetry, preserving context, and fitting established application behavior.

I became an OpenTelemetry JavaScript Approver in May 2023. My role had shifted from implementing isolated features to reviewing compatibility, release risk, and consistency across a growing API surface.

2024: Operational Maturity

By 2024, OpenTelemetry’s survival was no longer in doubt. Security and reliability became the larger concerns.

An independent security audit covered the Collector and the Go, Java, C#, and Python SDKs. It identified one CVE, remediated before publication, and five hardening recommendations. The audit also fulfilled a requirement for CNCF graduation.

The Collector illustrated another maturity challenge: its components evolve independently. Some are stable while others remain experimental or in development, so adopting the Collector still requires evaluating the exact components in a deployment.

In Azure Monitor, the OpenTelemetry Distro was becoming the strategic direction for Node.js observability. Customers needed more than traces: live and standard metrics, logs, auto-instrumentation, diagnostics, and a migration path from Application Insights. That product work revealed gaps that specifications and isolated examples could not.

2025: Learning From Production

By 2025, the community was solving problems visible only after years of production use: evolving semantic conventions without breaking dashboards, improving sampling across distributed systems, simplifying deployment, and clarifying maturity independently for SDKs, instrumentation, and Collector components.

One example was consistent probability sampling. OpenTelemetry made progress using W3C Trace Context Level 2 and a standard sampling threshold in tracestate, enabling more consistent decisions and reliable count estimation across services.

I returned to direct Python contributions through HTTP client metrics and Logs API/SDK cleanup, and I rejoined the Python Approver group in December.

Working on upstream code and downstream products made me more sensitive to changes that looked clean inside one package but created migration or support problems for distributions and customers.

I also became active in the Web/Browser SIG. Browser observability remains less mature than server-side tracing, with open questions about standardization, performance, and privacy.

2026: CNCF Graduation

OpenTelemetry graduated from the CNCF on May 21, 2026.

Graduation recognizes production adoption, neutral governance, community health, security, API stability, documentation, and technical maturity. At that point, OpenTelemetry had more than 12,000 contributors from over 2,800 companies and the second-highest project velocity in the CNCF ecosystem.

My own scope had grown from individual Python packages to technical ownership across JavaScript, Web, Node.js, and Python observability SDKs. I also became a component owner for the LangChain and OpenAI instrumentations in OpenTelemetry JavaScript.

GenAI observability now faces a familiar problem: frameworks and vendors produce different telemetry for similar operations. OpenTelemetry began by resolving exactly that kind of fragmentation. The same preference for convergence should guide its next phase.

Why OpenTelemetry Worked

OpenTelemetry succeeded because several design choices reinforced one another:

It focused on shared infrastructure. Vendors can compete on storage, analysis, and visualization instead of maintaining incompatible instrumentation libraries.
Migration was part of the design. Bridges and compatibility paths let OpenTracing and OpenCensus users move gradually.
Specifications were tested in code. Implementations expose weaknesses in the specification, while the specification keeps those implementations interoperable.
Each language remained idiomatic. OpenTelemetry standardizes concepts and output without forcing every ecosystem into the same programming model.
Governance remained neutral. Cloud providers, observability vendors, end users, and independent contributors all improve the same standard.

These choices created more than a collection of APIs and SDKs. They created coordination infrastructure for the observability industry.

What Comes Next

The work rarely stays inside one repository. A specification decision affects every language. A semantic convention affects queries, dashboards, alerts, and backends. A migration decision can determine whether customers adopt the standard at all.

Seven years across upstream projects, Microsoft distributions, and customer migrations taught me to look for those connections earlier. In 2019, open and portable instrumentation was an aspiration. Today, many developers treat it as the default.

The next challenges include browser and mobile observability, GenAI and agentic conventions, schema governance, zero-code deployment, and continued stabilization across languages and Collector components.

OpenTelemetry resolved the original split between OpenTracing and OpenCensus. The next phase is less dramatic and probably harder: making the standard easier to operate, govern, and extend across workloads that barely existed in 2019.

References

Connect with me: Website | GitHub | LinkedIn | Medium