OTel Isn't Going Well (And I Made A Spreadsheet About It)
In a blog post titled "OTel Isn't Going Well (And I Made A Spreadsheet About It)", the author reflects on persistent complaints from teams about OpenTelemetry's perceived incompleteness. The author notes that vendor SDKs are "idiot-proof" and easy to adopt, while OpenTelemetry presents many "experimental" stamps and multiple ways to accomplish tasks. The author acknowledges the project's goal of being vendor-agnostic, which is a significant achievement given the lucrative and contentious observability ecosystem. However, concerns have grown over time: conversations in the semantic-conventions repo drag on, language support varies dramatically (with Golang and .NET as first-class citizens while others lag), and the transition from auto-instrumentation to manual instrumentation is steep. The author began asking probing questions before recommending OTel to smaller teams. To generate data on whether the community's perception of slow progress is accurate, the author created a spreadsheet. The initial hypothesis was that the project bit off more than it could chew, with insufficient maintainers and budget. The analysis reveals that while that is part of the problem, there is "something else going on." The post cuts off mid-sentence, but the implication is that the author identifies a different underlying issue.
The analysis suggests OpenTelemetry's complexity and inconsistent language support may hinder adoption for smaller teams.