OpenTelemetry has been in production for years, but the project still hasn’t graduated from the Cloud Native Computing Foundation. According to The Register’s coverage of GrafanaCon in Barcelona, project founder Ted Young told the audience that graduation requires everything important in the OpenTelemetry ecosystem to reach 1.0 — and that the scale of remaining instrumentation work may require AI coding techniques to get there.
Why boring is hard
Young framed the goal in deliberately unexciting terms. The aim for the next year, he said, is to make OpenTelemetry as “boring” as possible. His argument: in observability, boring is a success state. “The opposite of boring isn’t interesting, it’s frustrating,” he told the audience. The project has reached stable, unified coverage for tracing, metrics, and logs. What remains is a cleanup and formalization problem, not a design problem.
The concrete barrier to graduation is that some organizations have security policies that ban software marked beta. That makes status labels a practical deployment blocker. Young said: “The final boss of the stabilization effort actually isn’t the collector or the SDKs or any other core components. It’s the instrumentation.”
Instrumentation is where the surface area becomes large. OpenTelemetry supports multiple languages, and many instrumentation packages were contributed to the project rather than built by a core team. The path to 1.0 runs through two stages. In stage one, packages that are already functionally stable can be marked 1.0, though the report notes “the data could be better.” Stage two is harder: it requires lifting data quality across all packages to the latest version of the semantic conventions — the shared definitions that determine how telemetry data is structured — once those conventions reach their next major version.
The automation problem
The scale of stage two is what prompted Young to raise AI tooling. “We’re going to need to invent new tools and potentially apply new coding techniques in order to handle the scale of instrumenting all the software in the planet,” he told the GrafanaCon audience.
The approach under consideration uses Weaver and the semantic conventions tooling group’s outputs to automate library updates when the conventions change. The intent is to shift maintainer work away from writing code and toward reviewing it. Young told The Register directly that he wants this tackled within the year.
The community research conducted for the graduation process also surfaced a finding that the project had been overly cautious: including data stability in version numbers had confused users who simply wanted to know whether code was safe to run in production.
The AI slop problem
The same conversation included an irony Young did not avoid. While the project is looking at AI coding to solve its scale problem, the volume of AI-generated pull requests has already increased the burden on OpenTelemetry maintainers. “You’re just wasting my time,” Young said of AI-generated submissions that contributors may believe are productive. The volume of low-quality contributions has pushed maintainers toward a moderation posture that Young compared to Discord moderation — filtering and rejecting at scale rather than collaborating on substantive improvements.
Young’s position, as reported, is that the instrumentation long tail is too large to close through manual effort alone, and that automation is necessary to make graduation achievable on any near-term timeline. Whether the tooling can be built and deployed fast enough to matter this year remains open.