OpenTelemetry Is Stuck: A Spreadsheet Shows Why
OTel isn't going well (and I made a spreadsheet about it)
OpenTelemetry, the vendor-neutral observability standard, is struggling. A data-driven analysis of CNCF projects reveals that most language SDKs rely on just one or two maintainers, while the semantic-conventions repo drags on with PRs taking months. The root cause: a binary stability gate that makes every feature a permanent commitment, combined with a massive scope and too few paid maintainers. The result is a project frozen by its own caution, where progress is slow and burnout is real.
The issue is more a classic case of "someone has to pay the maintainers".
- bilalq
OTel is so frustrating. If it wasn't shaping to be the clear winner in the space, I wouldn't complain about it as much. But today:
1. Every major vendor is still in some weird alpha/beta support for OTel even after all this time.
2. The performance hit is substantial and makes you question what the point of performance instrumentation is if you need twice as much compute/RAM to run the same workload now.
3. Serverless runtimes pay a heavy penalty for cold starts with OTel.
4. You're basically forced to run both gateway collectors and edge collectors for any realistic usage.
5. You still need to configure destination exporters in unique ways. This leaves you questioning what the value of OTel was.
6. Vendors that go beyond the scope of what OTel covers still need their own bespoke instrumentation. What was the point of any of this then?
- brikym
I've never found instrumentation to be a huge issue. Sure it takes more effort but you get a lot more value once you understand _business_ events.
- hn_acker
(TFA author is not me.)