OpenTelemetry's slow releases traced to maintainer scarcity and rigid stability rules

The author of matduggan.com, who works moving engineering teams off vendor specific observability SDKs and onto OpenTelemetry, set out to test a complaint he hears constantly: that OpenTelemetry always feels unfinished. To move past anecdote, he compared 24 months of public git activity across OpenTelemetry's language SDKs against two other CNCF projects, Envoy and Prometheus, using a Python script he has used before to gauge open source project health, which he flags himself as 'probably not the best.' Envoy showed a healthy spread of authors, mergers and issue closers. OpenTelemetry's PHP SDK did not: over the same period its work concentrated on just 2 people, which the author calls 'not a healthy open-source project,' and he says Ruby shows 'the same story.' Go, .NET and Python looked comparatively stronger, though the retrieved text gives no contributor or PR counts for them, only qualitative comparisons such as 'healthier' and 'no slouch.'

He then walks through how a feature actually moves through OpenTelemetry: an OpenTelemetry Enhancement Proposal, then a Specification entry, then Semantic Conventions, where he says most of the long arguments live and where a design becomes close to a permanent commitment, then implementation across each language SDK, then Contrib and instrumentation packages, then the Collector and the OTLP wire protocol, each with its own separate stability lifecycle. His diagnosis is a three way collision: a binary stability gate, where a feature marked stable can never be changed again, combined with a thin maintainer bench and a scope spanning dozens of languages and hundreds of libraries. That combination gives contributors an incentive to argue over a feature at length before it locks in, since there is no way to revise it afterward.

He expected the semantic-conventions repository, widely suspected as the bottleneck, to be the source of the slowdown, and found some genuinely slow pull requests there. But he also found that delay does not carry over into the SDK and API layer; checking Python's slowest pull requests, he traced their delay instead to an 'Approve Public API' check that requires sign off from a second maintainer, which loops back to the same root cause: too few maintainers.

His proposed fix is a time bound Beta stability tier sitting between Experimental and Stable. A feature reaching it would be guaranteed to stay available for at least 12 months before removal or promotion to Stable, and would be exposed to end users in a way Experimental features are not, since he estimates '99% of us have no idea when an experimental feature is added.' He notes OpenTelemetry already has a Beta label, but it is applied inconsistently: it exists for some SDKs, such as Rust, but apparently cannot apply to components such as Profiles, a distinction he says he could not fully map. The retrieved article text ends mid sentence inside the explanation of the existing 'Development' stability label, so any material past that point is not covered here.

Key facts

Comparing 24 months of public git activity, the author found OpenTelemetry's PHP SDK work concentrated on just 2 people, calling it 'not a healthy open-source project,' and says Ruby shows 'the same story.'
Over the same 24 month window, fellow CNCF project Envoy showed a healthy spread of authors, mergers and issue closers, while OpenTelemetry's Go and .NET SDKs looked comparatively healthier than its PHP and Ruby SDKs.
The author traces the slowdown to a three way collision: a binary stability gate where a shipped 'stable' feature can never change, a thin maintainer bench, and a scope spanning dozens of languages and hundreds of libraries.
Checking the semantic-conventions repository, the suspected bottleneck, he found its slow pull requests do not 'trickle into the SDK/API space'; the real SDK level slowdown instead traces to an 'Approve Public API' check requiring a second maintainer's sign off.
His proposed fix is a time bound Beta stability tier between Experimental and Stable, guaranteed to last at least 12 months before removal or promotion, since he estimates '99% of us have no idea when an experimental feature is added.'

Why it matters

OpenTelemetry is meant to be the vendor neutral standard for observability, the alternative to locking a codebase into one vendor's proprietary SDK. The complaint the author hears constantly while moving teams onto it, that it always feels unfinished, has mostly stayed anecdotal. This piece turns it into a testable claim by comparing OpenTelemetry's own git activity against fellow CNCF projects Envoy and Prometheus, then tracing the full workflow a feature has to survive between proposal and stable release. That matters for anyone deciding whether to commit production observability to OpenTelemetry now or wait, and it matters for the project itself: the diagnosis points at a structural bottleneck, a stability gate combined with a thin maintainer bench, rather than simple underfunding or vendor politics.

Who it affects

Engineering teams evaluating or already running OpenTelemetry, especially smaller teams the author says lack 'the time, budget, or emotional bandwidth' for its rough edges. The finding lands hardest on teams using the PHP and Ruby SDKs, which his data shows concentrated on as few as 2 active contributors; the Go, Python and .NET SDKs come off comparatively healthier in his comparison. It also affects OpenTelemetry's own maintainers and the CNCF, since the piece argues the bottleneck sits in process and staffing rather than in any single vendor's influence over the project.

How to use it

The practical takeaway for teams choosing an SDK is to expect meaningfully different maturity by language, matching the author's ranking of Go and .NET as strongest, Python close behind, and PHP and Ruby as thin. Treat anything marked 'experimental' as something most users will never knowingly touch, given the author's own estimate that 99% of users have no idea when such a feature ships, so budget extra caution before relying on it in production. His proposed remedy, a Beta tier guaranteed to persist at least 12 months before removal or promotion to stable, is not implemented; OpenTelemetry currently uses a Beta label only for some SDKs, such as Rust, and not for components such as Profiles, a split the author says even he could not fully map.

How solid is it

This is one practitioner's independent analysis, built on 'a hacky Python script I've used before for measuring the health of open-source projects,' which he flags himself as 'probably not the best' and invites readers to pick apart against the raw data he says he links separately. The comparison to Envoy and the PHP and Ruby maintainer concentration are the piece's most concrete evidence; for Golang, Python and .NET the retrieved text offers only qualitative language such as 'healthier' and 'no slouch,' with no contributor or pull request counts given. The retrieved article text itself cuts off mid sentence inside the explanation of the proposed 'Development' stability label, so any conclusions past that point are not covered here.

Risks and caveats

The analysis reflects public git activity and the author's own reading of it, not a statement from OpenTelemetry's governance or the CNCF. His own methodology caveat, that the measurement script may itself have flaws, is worth taking at face value rather than treating the maintainer counts as settled figures. The piece also complicates the obvious narrative: slow discussion in the semantic-conventions repository, the place most suspected as the source of delay, turns out not to propagate into SDK level slowdowns, which the author instead attributes to a public API review requirement, itself a symptom of too few maintainers rather than a separate cause.

“This is not a healthy open-source project and they clearly don't have enough people to cover the kind of scope OTel needs to cover.”

— the author, matduggan.com