Ripping out a vendor's instrumentation libraries is a real line item, and it usually lands on the engineering team, not on whoever approved the switch. Under the old arrangement each observability vendor shipped its own instrumentation libraries, so leaving one meant going back into your code, pulling those libraries out and dropping the next vendor's in [9]. The useful part of graduated status is the paperwork it produces against exactly that argument: documented governance with defined roles for election and retirement, an independent security audit whose critical findings were remediated, stable and versioned APIs that hold backwards compatibility, plus architecture and operator documentation and production use at organisations including GitHub and Farfetch [2][3].
That list satisfies a risk register, but it stops short of a migration plan. What gets said in the review is "the standard is safe now"; what happens next is a code change in every service you own, because OTel's portability comes from its APIs and language implementations sitting in your application, with the Collector downstream [11].
The participation numbers are worth reading carefully rather than quoting. The CNCF puts OTel at over 12,000 contributions from over 2,800 companies, alongside hundreds of maintainers across the language-specific SIGs [4], which averages out to roughly 4.3 contributions per company [13]. Breadth is what that measures. Depth sits with the maintainers of the SIG for whichever language your services are written in, a figure the published data doesn't break out.
The signal picture is uneven in a way the post itself shows. Traces, logs and metrics have reached general availability; profiling is described as a signal that was added, with no GA language attached to it [6][16]. Meanwhile the history section identifies the original defect as three signals treated separately with no easy way to correlate them, which is what left the observability story incomplete [10]. If continuous profiling is load-bearing for you, graduation did not move your problem, and the copy of the announcement we were supplied cuts off mid-sentence before any roadmap section [19].
Timelines argue for patience. OpenCensus and OpenTracing merged into OpenTelemetry in May 2019 and the project graduated in May 2026, seven years later [7][1][14]. OpenTracing was archived in January 2022 and OpenCensus not until July 2023, about four years and two months after the merge that was supposed to replace them both [8][15]. A standard being declared and a predecessor actually being switched off are separated by years, and the same lag applies to the proprietary agents currently running on your hosts.
So the forcing function is a two-column sheet, one row per signal you actually depend on. Column one: is this signal GA in OpenTelemetry, or does it only exist in your current vendor's agent [6]? Column two: is the reason you have not moved a governance reason or an engineering reason? Graduation closed the first column of objections and did nothing to the second. Rows where both columns are red are the honest scope of your migration, and rows where only the second is red are a scheduling conversation you can no longer blame the project for.
