Summary

  • In their May 2019 merger account, the leaders of OpenTracing and OpenCensus said the main problem was that developers faced two similar but incompatible instrumentation efforts. They prioritized backward-compatibility bridges and planned read-only status for the older projects before the end of that year.
  • In May 2023, OpenTelemetry announced a plan to archive most OpenCensus repositories on July 31 after reporting parity in seven languages. The announcement preserved an exception for opencensus-python and described bridges as a way to migrate applications incrementally.

Two projects were costing everyone the same integration work

A distributed service is hard to inspect from the outside. Libraries must record traces, metrics or logs and pass that information along. If every application and dependency chooses a different instrumentation API, the work of making a service observable spreads across developers, library maintainers and tool builders. OpenTracing and OpenCensus had both tried to share that cost. They had made different architectural choices and were similar enough to compete for the same integration effort.

The unusual point in the 2019 account by Ben Sigelman and Morgan McLean is how directly they named the waste. The biggest problem with either project, they wrote, was that there were two. A library maintainer could add one instrumentation path, add both, or wait for the argument to end. An operator who wanted traces across a whole service could not make that choice separately for every dependency. The cost of a duplicate standard was paid in code that had to meet at runtime, not merely in two logos on conference slides.

The May 2019 answer was a joint project under the CNCF sandbox. The initial governance and technical committees included people from Google, LightStep, Microsoft and Uber. This gave the merger a place to make future decisions. It did not give a deployed application a new dependency graph overnight. The founders called OpenTelemetry the next major version of both predecessors. That phrase set the direction of new work, while also admitting that the old code had users who needed a migration path.

The bridge was part of the merger, not a late apology

The founders listed backwards compatibility through software bridges as a priority from the start. A bridge lets existing OpenTracing or OpenCensus instrumentation coexist with the new project while applications change in stages. Their second priority was to shorten the period in which three projects would be developed at once. They planned to put the older two into read-only mode before the end of 2019. This was a target in a merger announcement, not a timestamp for every installed library to vanish.

Read-only source code and a running service live on different clocks. An application may carry instrumentation through its own modules, its dependencies and an exporter. A maintainer can choose one project for future development, but an operator still needs data to flow during upgrades. The official bridge plan is evidence that the project leaders understood that gap. They were trying to move two communities into one home without making every user choose a single cutover night.

The CNCF's August 2021 incubation announcement shows the new home taking shape: APIs and SDKs in 11 languages and protocol support for metrics and tracing. It also said OpenTracing would be formally archived and both predecessor projects further deprecated. Two years after the merger, the foundation was still describing retirement as work to be completed. The announcement's status matters more than a triumphant claim that consolidation was finished.

In 2023, the exit acquired an inventory

The OpenTelemetry project's May 2023 OpenCensus notice moved from intention to a named maintenance boundary. It reported OpenCensus feature parity in C++, .NET, Go, Java, JavaScript, PHP and Python. It planned to archive almost all OpenCensus GitHub repositories on July 31, 2023, but singled out opencensus-python as an exception because parts of that repository were still recommended for production use. A clean merger chart could not erase that exception.

The same notice described compatibility bridges for Go, Java, JavaScript and Python; it also said some shims were still forthcoming. The aim was an incremental route: use bridges so existing instrumentation can send data through OpenTelemetry exporters, then remove the older libraries from applications in stages. This was not a claim that every signal and data model would remain byte-for-byte identical. The project warned that migration resembled a major version change and could alter telemetry.

Archiving had operational teeth. The 2023 notice said the archived OpenCensus project would receive no new features or security fixes after July 31, while its source and existing packages would remain downloadable. The code could stay in an application after the maintenance team had left. That is why the bridge and the exception were more than housekeeping: they told users which path still had owners and which old path was becoming their own responsibility.

A committee can merge before its users do

OpenTelemetry's leaders ended the competition over where shared instrumentation should be built. The 2019 decision mattered: it let library authors and vendors point future work at one project. But installed instrumentation is a supply chain of dependency versions and export paths. Its migration is governed by release cycles, parity, bridge quality and the willingness of many maintainers to change code they already ship.

The four-year span from the merger account to the OpenCensus retirement notice measures that work more honestly than a single launch date. It does not prove the 2019 read-only target failed; read-only status and later archival are different milestones. It shows that the public project still needed a detailed, exception-bearing exit plan in 2023. The name on the new door changed quickly. Moving the cables through it took longer.