You’ve probably felt it. That sinking feeling when you realize the ‘open standard’ everyone promised would save you from vendor lock-in is actually making your code messier, your performance worse, and your team more miserable. You’re not alone. OpenTelemetry (OTel) has become the de facto standard for observability, but it’s a standard that’s failing the people who use it every day.
One engineer put it bluntly: ‘I wish OTel was never there. It is a badly designed abstraction and due to OTel the code gets very very messy and bad.’ Another added: ‘Every major vendor is still in some weird alpha/beta support for OTel even after all this time.’ These aren’t isolated complaints. They’re the sound of a community trapped between a rock and a hard place.
The open standard that was supposed to set you free has become a cage of its own making. Most criticism focuses on vendor lock-in as the alternative. The narrative goes: ‘OTel might be rough, but at least it’s not proprietary.’ That’s a dangerous lie. The real problem is that OTel’s abstraction is fundamentally broken — not just a rough edge, but a core design failure that makes instrumentation messy, performance-heavy, and ultimately self-defeating.
Let’s be clear: Neutrality is death. I’m taking a side: OTel, as it stands today, is a net negative for observability. The paradox is this: you need an open standard to avoid being locked into a single vendor, but the standard itself is so poorly designed that it undermines the very value it promises to deliver. You end up with a choice between two bad options — expensive vendor lock-in with decent performance, or a free, open standard that makes your codebase a nightmare and your latency spike.
I’ve seen this firsthand. A team spent months instrumenting their microservices with OTel. They followed the docs, used the auto-instrumentation agents, and carefully configured exporters. The result? A 20% increase in p99 latency, a tangled mess of manual spans, and a constant stream of configuration errors. When they tried to switch to a proprietary agent, the migration was almost as painful as the original setup. They were stuck.
This isn’t about ‘learning curves’ or ‘growing pains.’ When an abstraction is so leaky that it requires you to understand the underlying implementation to use it correctly, it’s not an abstraction — it’s a tax. OTel’s design forces you to make trade-offs that shouldn’t exist. Want to avoid vendor lock-in? Great, but you’ll have to live with a performance hit that makes your application slower. Want to optimize? Fine, but you’ll end up writing vendor-specific code anyway, defeating the purpose.
The twist is this: the industry has been sold a story that OTel is the inevitable future. But the future doesn’t have to be broken. We need to stop pretending that ‘better than vendor lock-in’ is the same as ‘good enough.’ Stop settling for a standard that makes your code worse and your life harder. Demand better.
So what do you do? Either accept the mess, or push for a better standard. But don’t pretend OTel is fine. It’s not. The sooner we admit that, the sooner we can fix it.
FAQ
Q: Isn't OTel still better than being locked into a single vendor?
A: Not if the abstraction costs you more in complexity and performance than the lock-in would. The trade-off is not clean. In many cases, the hidden costs of OTel — messy code, degraded performance, and endless configuration — outweigh the theoretical benefit of avoiding vendor lock-in. You're trading one problem for another.
Q: What should teams do now?
A: Evaluate your specific needs honestly. If you require deep, custom instrumentation and can tolerate the performance hit, OTel might still be the best option — but only if you're prepared to invest heavily in workarounds and maintenance. Otherwise, consider proprietary solutions that offer better performance and simpler APIs, even if they lock you in. The key is to make a conscious choice, not default to OTel because everyone says it's the standard.
Q: Could OTel actually be a good thing despite its flaws?
A: Yes, because it's the only game in town and forces some standardization across the observability ecosystem. But that doesn't excuse its design failures. We need to demand better from the OpenTelemetry project — not settle for a broken abstraction. The community should push for a redesign that prioritizes performance and developer experience, not just openness.