[codeboten]

This PR contains a project proposal as discussed during the 29-Sept-2026 specification/maintainer SIG call.

Closes #3483

[ocelotl]

Copy of this comment:

Nice 😎

The idea of reimplementing an OpenTelemetry component in a different language has many applications: better performance, lower memory usage, removing a dependency, sharing one implementation across several SDKs, etc. There is clear interest in this idea, and this issue is one example.

In order to avoid misunderstandings and to make communication easier and more accurate, I would like to propose a name for this idea: refit.

The term comes from the ship industry. A refit replaces a ship's machinery while the ship stays the same ship: same hull, same name, same crew.

I am deliberately proposing refit instead of port. The term port already has a different meaning: adapting a program so that it runs in an environment where it could not run before, usually on a different operating system or processor. The result is a second version of the program that runs in the new environment. A port benefits the users of the new environment. After Linux was ported from x86 to ARM, the users of Linux on x86 did not get any benefits. A refit changes the implementation of a component in place, so the users of that component keep the same API and get the benefits of the new implementation.

It gives us a small set of consistent terms:

1. The refit: replacing the implementation of an OpenTelemetry component with one written in another language, without changing that component's public API.
2. The refitted component: the component that is reimplemented in another language. Its users see no difference.
3. The refitting component: the component, written in another language, that provides the new implementation.
4. The refitter: whoever performs a refit.

A few sentences to show how it reads:

The Python BatchSpanProcessor is a refitted component: its API is unchanged, and the refitting component underneath it is written in C++.

Every refit must preserve the semantics the refitted component already guarantees.

This PR adds batch span processor support to the refitting component, so the Python BatchSpanProcessor refit can drop its pure-Python implementation.

Two refits are in flight. The Python TracerProvider refit is feature complete, and the Node OTLPTraceExporter refit is waiting on async exporter support.

[ocelotl]

I think we could restructure this document for clarity. Also, there is a typo.

[ocelotl]

I understand the idea you have of this project is to "wrap" the C++ SDK with Python bindings, but I think "wrapper" is not specific enough.
Wrapping an SDK is the technique this project will use and wrapping is a technique used all over software for all kinds of purposes.

What is specific to this project is that wrapping an SDK implemented in language B with bindings for language A creates a relationship between SDK A and SDK B: the implementation of SDK A is replaced by SDK B, while the API of A stays exactly as it is for its users.

That relationship will come up again and again, for other components and other languages, so we will need to name the individual cases. If we use the word "wrapper" then the best we can say is "the Python TracerProvider wrapper is feature complete" or "the Node OTLPTraceExporter wrapper is waiting on async exporter support".

Neither of those sentences tells the reader that the Python or Node API for those components is unchanged or that the underlying implementation is not written in Python or Node respectively. The only thing the reader gets is that some components are being wrapped.

On the other hand, with a term of our own, "the Python TracerProvider new_term is feature complete" and "the Node OTLPTraceExporter new_term is waiting on async exporter support" tell the reader exactly what the previous two sentences could not: the Python and Node APIs for those components are unchanged, and the implementation underneath each one is not written in Python or Node.

I think we would benefit from using a new term to describe this project, and I have proposed one here. If we use that proposal, then the title becomes:

Suggested change

	# OpenTelemetry SDK Wrapper
	# OpenTelemetry SDK Refit

Of course, the definition of refit should follow immediately so the reader can understand what we mean by "refit" in the title.

Coining a term is not unusual here. OpenTelemetry has done this before, both to replace a word that was ambiguous and to name something new:

• Baggage replaced "Distributed Context" (oteps#36)
• Instrumentation Scope replaced "Instrumentation Library" (opentelemetry-proto#362)
• Connector named a fifth Collector component type, alongside receiver, processor, exporter and extension
• Injector named the idea behind The OpenTelemetry Injector Project
• Entity named the central concept of Resources and Entities
• Distribution, or "distro", named a packaging pattern that already existed under other names (docs)

[tedsuo]

If the specific goal of this project is "C++ Bindings for Python" then that should be the name of the project. That will help people looking at the calendar, scanning through the project lists, etc. Neither "refit" or "wrapper" really describe what the specific goal is.

[ocelotl]

I would suggest we rename this file (if we decide to use my naming proposal) to sdk-refit.md.

[codeboten]

I don't feel strongly on the name and am happy to let others weigh in here, will rename the file appropriately once the name is agreed.

[ocelotl]

The project proposed here provides performance the benefits

This seems to state the project has already reached the goal of providing benefits and it seems to be contradicted by this line:

An objective is to prove this approach as part of the project.

I think proving the approach proposed here has benefits is the goal of this project.

[ocelotl]

performance the benefits of an underlying SDK

This needs more context, an SDK does not have performance benefits on its own.

[ocelotl]

API implementers

I am not sure API implementers will benefit from this project, end users will, that is correct.

[ocelotl]

Reference implementation SDKs

I think this is another name for native SDKs which is already being used elsewhere in this PR.

[ocelotl]

I am having a bit of a hard time understanding what you mean here. What do you mean with an SDK offering "flexibility"?

[ocelotl]

I think using OpenTelemetry regardless of the language increases resource consumption. I think what you mean here is that there are certain implementations of OpenTelemetry that significantly increase resource consumption, and those implementations are the ones who can benefit the most from the approach proposed in this project.

[ocelotl]

What do you mean here?

[ocelotl]

The OTel community is currently working across many languages to support reference implementations of all the features in every language.

I think what you are trying to say here is that the OTel community is currently working to add all the OpenTelemetry features to every native SDK.

[ocelotl]

We have always proposed...

We have always promised that to our users.

[ocelotl]

The proposal for this project is to leverage that model as well as existing OpenTelemetry component to provide alternative SDKs for specific use-cases.

I think the proposal for this project is something else. What I think you want to say here is that this project will use the existing separation between API and SDK to allow end users to use alternative SDKs for specific purposes.

[ocelotl]

An objective is to prove this approach.

A requirement is that the performance improventes are worth the investment.

This seems contradictory or at least hard to understand, an objective is to test this approach and a requirement is that the approach is worth the investment?

[ocelotl]

What do you mean with flexibility here? I agree that this project is not trying to replace existing SDK implementations, but I think the reason is that there is no certainty that a refitted SDK can satisfy every use case existing SDK implementations can because we have not tested all those use cases yet with a refitted SDK.

[tedsuo]

Performance is an optimization. If we are optimizing for higher performance and lower resource consumption, that will be better achieved if this project does not attempt to provide all of the plugins, hooks, and configuration options currently available in the existing SDKs. For example, it may be the case that this implementation only provides OTLP via Proto/HTTP as the sole exporter option, in order to reduce file size and optimize container start up time.

I would suggest adding details to this section to clarify that performance is an optimization goal, and this implementation will makes trade-offs to achieve that.

The other important form of flexibility is supporting build/deployment environments where our C++ binding mechanism doesn't work or otherwise creates a lot of trouble.

[tedsuo]

Another form of flexibility is "mix-n-match." For example, installing the OTel tracing SDK, but binding to Prometheus for metrics and not installing a logging SDK at all.

This implementation could be all-or-nothing, in order to avoid the complexity that comes with offering those options.

[ocelotl]

Is this a leftover from a template?

[ocelotl]

I think this document captures the essence of this project but can be edited for clarity. Glad to help if help is needed with this part ✌️

[ocelotl]

The comments I added before can be addressed later as enhancements, approving ✌️

[pellared]

I think we should also take look at OBI https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation as one of the possible solutions.

It can already be used with Python. I think it is worth mentioning that it can be already used as an SDK for users of OTel Go API (see: https://opentelemetry.io/docs/zero-code/obi/distributed-traces/#instrument-applications-that-use-the-go-trace-api), similar feature is planned for other languages. We already have issues like:

• 🏆 Epic: OTel API/SDK Integration opentelemetry-ebpf-instrumentation#1140
• Support manual instrumentation inside OBI traces opentelemetry-ebpf-instrumentation#2659

This was initially brought up by @lmolkova 🙏

[tedsuo]

Definitely worth investigating! Especially if the goal is to support the same instrumentation we already have, and not to try and create a duplicate set of instrumentation using ebpf targets.

[tedsuo]

I think that this project is great, my main suggestion is to pick a small scope, as it's possible for this project to sprawl. For example, C++ bindings might be a good idea for improved performance. Rust, eBPF, native-sdk-but-with-a-different-architecture might also prove to work well. It might be different in different languages. But if you pick one approach for the initial investigation, it will be more clear who should join the SIG to work on it.

I would suggest continuing with the C++ binding investigation, and determine which would languages benefit from that approach. If someone wants to investigate another approach, they can follow up with a separate project, and we can compare the results. (If there are enough people available to work on two investigations at the same time, great.)