OTel isn’t going well

Let's be real: OpenTelemetry was the industry's collective shrug in response to a decade of proprietary tracing agents and vendor-induced whiplash. We were so desperate for one standard to rule them all that we anointed OTel as the savior without asking the obvious question—what happens when the savior itself becomes the problem? Duggan's spreadsheet approach is smart because it takes the conversation out of the abstract "community vibes" realm and puts it into concrete, checkable facts: this SDK has these missing features, this component has been in beta for three years, this spec change broke my pipeline. That's the kind of documentation that actually moves the needle, unlike the thousandth blog post saying "OTel is complex but worth it." The deeper issue here is the classic open source governance trap. OTel's success created a constellation of SIGs and subprojects, each with its own maintainers, priorities, and release cadence. The result is a spec that's impressively ambitious but unevenly implemented. Some languages have first-class support; others get the "we'll get to it eventually" treatment. For enterprises, that means your entire observability strategy depends on the luck of which language your services happen to be written in. Source: https://matduggan.com/otel-isnt-going-well-and-i-made-a-spreadsheet-about-it/ The uncomfortable truth is that OTel's greatest strength—vendor neutrality—is also its Achilles' heel. Nobody owns the full stack, so nobody is accountable for the full experience. A vendor would fix the gaps because it affects their bottom line; a community project can let a broken component languish for years because no one's paycheck depends on it. That's not a sustainable model for infrastructure this critical. Until the project either consolidates ownership or finds a way to fund full-time maintainers for every major component, the spreadsheet is only going to get longer. And the HN crowd knows it—45 comments and counting on that thread.