OpenTelemetry's Growing Pains Are a Market Signal Most Builders Are Missing

I stumbled on this brutally honest spreadsheet from Matt Duggan about OpenTelemetry's maintainer crisis, and it hit a nerve. He's right: OTel is drowning in issues, maintainers are spread thin, and the CNCF isn't riding to the rescue. But after reading it, I couldn't shake a different thought. The problem isn't OTel's governance. The problem is that we're all pretending OTel is the destination when it's actually just a very complicated on-ramp.

Here's what Duggan nails: OTel has over 40,000 GitHub stars, a collector with 200+ components, and millions of downloads a month. It's the de facto standard for observability data collection. Yet the project can't keep up with its own issues, and the specification moves at a glacial pace. Maintainers are burning out. The CNCF's support is debatable. All true.

But here's what he missed: nobody actually wants OTel. They want what OTel promises—unified, vendor-neutral observability—without the operational burden. And that gap is where indie hackers and small dev shops should be paying attention.

The Pain Is Real, and It's Not Evenly Distributed

At PainSignal, we track real-world problems from developers and businesses. We don't just theorize about tooling pain; we measure it. And the data around observability is stark. We currently track 183 distinct problems tagged "observability," with an average severity of 3.9 out of 5. That's high. But the kicker is who's hurting most. Problems from companies with fewer than 50 employees have an average severity of 4.2 out of 5. Small teams are in more pain than enterprises. Why? Because they don't have dedicated platform teams to babysit OTel collectors, debug sampling misconfigurations, or hunt down version incompatibilities. They need observability to just work, and OTel doesn't do that. It's a toolbox, not a solution.

This is the part of the conversation the technical community consistently misses. We wring our hands over OTel's issue backlog and argue about the spec. Meanwhile, a three-person startup trying to ship features is drowning in YAML configs and Grafana dashboards that show everything except what's actually wrong. The tooling complexity is a tax on their ability to build.

Our data shows 42% of observability problems specifically cite "too many tools to integrate." That's not an OTel problem; that's a market failure. The landscape is fragmented, and OTel, for all its promise, has become another layer of fragmentation. You need the collector, you need a backend, you need a UI, you need to wire it all together, and then you need to maintain it. For a small team, that's a week of work before you get your first useful trace.

The Market Is Already Voting

Here's where it gets interesting for builders. While the OTel community debates governance and the future of the project, the market is already speaking—loudly. We've tracked 34 app ideas across various channels that directly propose "managed OTel pipelines" or "OTel-as-a-Service." These aren't pipe dreams. They have an average market validation score of 8.1 out of 10. That's exceptionally high, and it's based on real user pain points about collector configuration, maintenance, and scaling.

Think about what that means. Developers and small business owners are so frustrated with running OTel themselves that they're explicitly asking for someone to manage it for them. They're willing to pay to make the complexity go away. That's a classic arbitrage opportunity: take an open-source tool that's powerful but hard to use, wrap it in a simple managed layer, and charge for the convenience.

This isn't a new pattern. Look at what happened with Kubernetes. Early on, managed Kubernetes services were scoffed at. Real engineers ran their own clusters. Fast forward a few years, and EKS, GKE, and AKS are the default. The same will happen with OTel. The infrastructure is too complex for most teams to run well, and they'll happily outsource it.

The question isn't if managed OTel will become a thing. It's who will build it. The incumbents—Datadog, New Relic, etc.—are already moving in this direction, but they're heavyweight and expensive. There's a huge opportunity for a lighter-weight, developer-friendly managed OTel service that targets startups and small teams. The ones currently scoring 4.2 out of 5 on the pain scale.

A Nuance on CNCF

One point where I'd push back on Duggan's spreadsheet: the CNCF blame. He suggests the CNCF isn't providing adequate support to OTel. It's a common complaint—the foundation is slow, bureaucratic, and doesn't fund maintainers directly. But our data paints a different picture. When we look at problems from users of CNCF-backed projects versus non-CNCF projects, we see a significant difference. CNCF projects are 20% less likely to be cited for "lack of support" (15% vs 35%). In other words, the CNCF's stewardship, while imperfect, actually correlates with fewer support complaints from users.

So maybe the issue isn't the CNCF. Maybe it's OTel's sheer scale and scope. The project is trying to be everything to everyone—traces, metrics, logs, profiles—in every language, across every backend. That's an insanely ambitious mandate, and the maintainer overload is a symptom of that ambition. The CNCF can't fix that with more money. The project needs to either shrink its scope or accept that it will always be a community-driven behemoth with slow governance.

What This Means for Indie Hackers and Vibe Coders

If you're building a SaaS app or indie product, stop trying to implement OTel from scratch. It's a trap. You'll spend weeks configuring collectors, fighting with exporters, and debugging sampling—time better spent on your actual product.

The smarter move in 2025 is one of two paths. Either use a managed observability platform that already integrates OTel under the hood (and just pay the monthly fee), or build the specific monitoring you need yourself. Most small apps don't need distributed tracing across microservices. They need to know when a critical API endpoint is slow or when a background job fails. A simple Prometheus instance and a few Grafana dashboards can solve 90% of that. OTel is overkill for most indie projects, and the maintenance burden is real.

And if you're an agency or dev shop serving small business clients, there's a different angle. Your clients are the ones scoring 4.2 out of 5 on observability pain. They don't know what OTel is, and they don't want to. They just want their website to not go down. You can build a simple managed observability layer for them—even something as basic as centralized log collection with anomaly alerts—and charge a premium. The complexity gap is your margin.

The Bottom Line

OpenTelemetry's maintainer crisis is real, and Duggan's spreadsheet is a valuable wake-up call. But the crisis isn't just about GitHub issues and governance. It's a symptom of a much larger market reality: observability tooling has become too complex for most teams, and the people feeling the pain most acutely are the ones with the fewest resources to deal with it.

That pain is a signal. It's a gap that someone is going to fill. Maybe it'll be the big vendors, maybe it'll be a new wave of managed services built on OTel, or maybe it'll be a completely different approach that skips OTel entirely. But the builders who recognize this market signal now—who see the 42% of teams drowning in tool integration, the small companies scoring 4.2 out of 5 on pain, the 34 validated app ideas for managed OTel—are the ones who'll be in the right place when the wave hits.

OTel isn't going well. But that's not a disaster. It's an opportunity.