OTel isn’t going well

August 12, 2026 | 14 min read | Category: opentelemetry

For several years, I've encountered a recurring grievance whenever I attempt to migrate a development team from a vendor-locked SDK to OpenTelemetry (OTel). The sentiment is almost always some version of:

"Why does it feel like this project is still under construction?"

To put it bluntly, vendor-specific observability SDKs are designed to be idiot-proof. You install the package, the dashboards populate automatically, the integration is handled behind the scenes, and you can focus on your actual work.

OpenTelemetry, however, is a different beast. It greets new users with a barrage of experimental labels and offers roughly half a dozen different paths to achieve the same objective.

---

The Noble Goal vs. The Harsh Reality

In fairness to the OTel team, this friction wasn't the intended design. I have immense respect for their commitment to building a truly vendor-agnostic ecosystem. Creating a system that genuinely doesn't care where the data ends up is a monumental task, especially considering:

1. The observability market is incredibly lucrative and aggressive.
2. The project's maintainers are often employed by the very vendors competing in that market.

Despite this, OTel has managed to avoid showing blatant favoritism toward any single vendor—a feat that is nothing short of impressive.

However, this neutrality comes at a cost:

• Endless Debates: Discussions in the semantic-conventions repository can drag on indefinitely.
• Language Inequality: While $\text{Golang}$ and $\text{.NET}$ were treated as first-class citizens from the start, other languages have lagged behind by years.
• The "Instrumentation Cliff": Auto-instrumentation feels like magic until it doesn't. The gap between "it just works" and "I need to manually instrument this" is a steep drop-off that requires a warning label.

Because of this, I've started vetting smaller teams more rigorously before recommending OTel; if they lack the budget, time, or emotional resilience, the project might be too much for them.

---

The "Three-Way Crash"

There is a pervasive feeling that "something is wrong in OTel-land." Is this just a perception of slow progress, or a systemic failure? While it looks like a classic case of an open-source project biting off more than it can chew, the reality is a three-way crash of conflicting pressures.

The logic follows a specific tension: because the project demands high stability, and because once a feature is marked "stable" it is essentially locked in forever, maintainers are incentivized to argue over every possible edge case. When you combine this stability gate with a limited number of maintainers and a staggering scope of languages, you get a bottleneck.

Mathematically, we could view the "Project Friction" ($F$) as: $F = \frac{\text{Scope} \times \text{Stability Constraints}}{\text{Maintainer Capacity}}$

---

Understanding the OTel Architecture

OTel attempts to support a dizzying array of frameworks and languages. To manage this, they divide the workload into two primary categories:

Example: Python Implementation

• opentelemetry-python (Core): Handles the API, SDK, OTLP exporter, resource detection, and context propagation.
• opentelemetry-python-contrib (Contrib): Contains specific instrumentation for Flask, Django, requests, psycopg2, Redis, Kafka, boto3, etc.

You want everything in one package $\rightarrow$ No. You only install what you need (e.g., pip install opentelemetry-instrumentation-flask) to avoid bloating your dependencies.

The Collector Problem: On the backend, you have the otel-collector. To get a specific configuration, you often have to use the OpenTelemetry Collector Builder to create a custom binary, which adds yet another layer of operational complexity for a team to manage.

---

The Lifecycle of a Feature

Based on my research into the OpenTelemetry Enhancement Proposals (OTEP), the workflow generally looks like this:

1. OTEP Submission: A proposal is drafted and accepted.
2. Specification: The proposal moves to the Specification directory. This is where the "permanent commitment" happens and where the longest arguments occur.
3. SDK Implementation: Individual language SDKs implement the API surface defined in the spec.

Note on Versioning: While there was an early desire to avoid 2.0 breaking changes at all costs, that sentiment has shifted. Some SDKs have already undergone breaking changes, which is a pragmatic and positive move.

Stability Matrix:

• OTLP (Wire Protocol): Has its own distinct stability lifecycle.
• Collector Components: Stability is documented in individual READMEs and is, frankly, inconsistent.

---

Lingering Questions & Testing

There are still several "black boxes" in the process:

• How long does the transition from $\text{OTEP} \rightarrow \text{Specification}$ actually take? (Git history shows no predictable cycle).
• How do the various stability commitments interact?
• Is there a "dropout" mechanism where a language is deemed out of scope if it lags too far behind?

Measuring Health

To quantify these feelings, I attempted to compare OTel against other CNCF projects using a custom Python script to measure "open-source health."

Visual Data Points:

Language-Specific Health Snapshots:

• PHP:
• Ruby:
• Go:
• Dotnet: