Alternate Proposal for OTel Tracing API vs Tokio-Tracing

[cijothomas]

This issue builds upon Option 1 discussed in OTel Tracing vs Tokio-Tracing. The parent issue used the term "deprecate Tokio-Tracing" which is disruptive. However, this proposal seeks a non-disruptive, and more collaborative approach by suggesting that the Tokio organization donates the tracing crate to the OpenTelemetry Rust project and joins as maintainers.

This approach is very similar to recognizing tracing as the OTel's official API, but it goes a step further by transferring the tracing codebase to the OpenTelemetry repository through a donation — a practice not new to OpenTelemetry, as demonstrated here and here.

Despite the code's transfer to a CNCF-owned OpenTelemetry-Rust repository, the package name could remain unchanged, continuing its publication on crates.io as usual. This ensures that current users of tracing experience no disruption in their existing workflows. It is still possible to change the name to include "opentelemetry" in future, but we can still ensure backward compatibility.

Advantages of This Approach

1. No disruptions to existing users: Users of Tokio-Tracing will experience no changes in how they use the crate. All existing functionalities will remain intact, albeit with the source code hosted under a new umbrella.

2. Enhanced Development and Stability: With the combined efforts of both the Tokio and OpenTelemetry communities, both tracing and opentelemetry can advance more rapidly towards version 1.0. The collaboration brings more resources and expertise to tackle common challenges more effectively.

All the advantages and some of the challenges of recognizing tracing as the OTel's official API applies to this proposal as well.

Note: This was already suggested here and here. Opened a dedicated issue to capture details and get feedback.

[mladedav]

What would the donation mean for the tracing project itself? I assume it would have to add first-class support for OpenTelemetry-specific features such as remote contexts and having globally unique span IDs which it currently doesn't have for performance reasons?

[davidbarsky]

I mentioned this in other contexts, but I don't think that we, as the tracing project, will do this. I understand why this issue/discussion needs to happen, however.

I assume it would have to add first-class support for OpenTelemetry-specific features such as remote contexts and having globally unique span IDs which it currently doesn't have for performance reasons?

And some governance/IP assignment stuff, I assume.

[lalitb]

I mentioned this in other contexts, but I don't think that we, as the tracing project, will do this. I understand why this issue/discussion needs to happen,

Thanks for understanding :)

I assume it would have to add first-class support for OpenTelemetry-specific features such as remote contexts and having globally unique span IDs which it currently doesn't have for performance reasons?

I believe OpenTelemetry GC does acknowledge that performance is key for system languages like C++ and Rust. And OpenTelemetry specification is flexible to scenarios where performance can be achieved by leveraging language-specific constructs or features. In general, it's important to support the OpenTelemetry Data Model, remote context management, and OTLP Export. From Rust's perspective, it is equally important that we support these features without sacrificing performance in any way.

And some governance/IP assignment stuff, I assume.

Agree, this issue is only talking about the technical feasibility, so lots of logistics around CNCF and Tokio are ignored :)