I’ve helped launch many projects in my career: products, open-source efforts, and even a few startups. Invariably, I look forward to launches. After all, they’re motivating and they’re fun.
But of all of the launches I’ve been a part of, the recent announcement of OpenTelemetryOpenTelemetry at KubeCon EMEA has felt the most satisfying, and I’ve been pondering the obvious question: why? It’s not the technology itself, nor is it the coverage we’ve received. And it certainly isn’t about the economics: neither myself nor my company profits off of OpenTelemetry directly, and inasmuch as it helps improve the quality of data in our market, it benefits our competitors as much as it benefits us. Having mulled it over for a few days, though, I have come up with a few ideas.
First of all, the OpenTelemetry launch really needed to happen – but almost didn’t. If we step back just nine short months, OpenCensus and OpenTracing were both exciting, widely-adopted projects that also happened to be diverging quickly. This divergence inadvertently created plentiful confusion, uncertainty, and even strife in the larger ecosystem. And as the divergence, uncertainty, and strife accelerated with every passing GitHub commit, the sunk cost and the actual effort required to merge the projects grew along with it. If I can speculate, I’d say that the overall sentiment – across both projects, to be clear – was some version of “it’s a shame that there are two projects,” but we had nearly given up hope of a resolution. Technically it all seemed pretty doable, but the larger alignment and organizational issues were incredibly daunting.
And that brings me to the second reason that OpenTelemetry has been so satisfying: to get to this point, we’ve gotten to solve some really challenging “people problems.” When someone cites “people problems,” often they’re just trying to find a nice way to explain that “someone is being a jerk.” That wasn’t the issue here at all, and nobody was being unreasonable. And frankly, unreasonable people have never worried me – I just try to ignore them and move on. :)
No, the “people problems ” here were of the most rewarding variety: we started with two groups of smart, respectful, motivated individuals who happened to be way out of alignment, and we needed to fix that. In order to get there, both projects had to make peace with a great deal of short-term opportunity cost, create and cultivate trust where there had previously been very little, and make sure that the robust communities built around OpenCensus and OpenTracing stayed informed and appreciated. And if even a single leader in OpenTracing or OpenCensus had vetoed this effort, it would have dissolved.
Now that we’re on the other side of the announcement at KubeCon EMEAthe announcement at KubeCon EMEA, I’m realizing there’s one final thing that makes this feel so satisfying: I just got a whole bunch of incredible new teammates. Everyone from the OpenCensus camp has been responsive, collaborative, patient, and technically excellent, and I consider myself fortunate for the opportunity to work with them. To quote Pritam Shah, an engineering manager at Google who’s been involved with OpenCensus for a while now, we are all “better together” after the OpenTelemetry merger.
This would be an appropriate time to mention that we really have our work cut out for uswe really have our work cut out for us! On an optimistic note, though, it was incredibly encouraging to be at KubeCon in Barcelona this past week… I lost count of the number of people who stopped me to say how glad they were about the OpenTelemetry news, and further how they’d like to help. It’s a unique time to contribute to the project: we are laying the foundations across many languages, and also building out some novel and reusable observabilityobservability infrastructure. If you’d like to get involved, it’s as simple as reaching out via this formthis form.
As we continue to build out the project – both the technology and the people – I’m looking forward to many more satisfying launches to come as we make high-quality telemetry data a built-in feature of cloud-native software. It’s going to be fun!
May 23, 2019
4 min read
About the author
Ben SigelmanRead moreRead more
Explore more articles
From Day 0 to Day 2: Reducing the anxiety of scaling up cloud-native deploymentsJason English | Mar 7, 2023
The global cloud-native development community is facing a reckoning. There are too many tools, too much telemetry data, and not enough skilled people to make sense of it all. See how you can.Learn moreLearn more
OpenTelemetry Collector in Kubernetes: Get started with autoscalingMoh Osman | Jan 6, 2023
Learn how to leverage a Horizontal Pod Autoscaler alongside the OpenTelemetry Collector in Kubernetes. This will enable a cluster to handle varying telemetry workloads as the collector pool aligns to demand.Learn moreLearn more
Observability-Landscape-as-Code in PracticeAdriana Villela, Ana Margarita Medina | Oct 25, 2022
Learn how to put Observability-Landscape-as-Code in this hands-on tutorial. In it, you'll use Terraform to create a Kubernetes cluster, configure and deploy the OTel Demo App to send Traces and Metrics to Lightstep, and create dashboards in Lightstep.Learn moreLearn more
Lightstep sounds like a lovely idea
Monitoring and observability for the world’s most reliable systems