Use of "OTel native" or "native" referring to OpenTelemetry

[theletterf]

We've around 230+ hits for "native" in our docs. It usually refers to native instrumentation, schemas, and so on.

I'd like to suggest that we come up with a new term and edit the docs accordingly. The term could be:

• OTel-ready
• OTel compatible
• Or just "OTel" as an adjective when we talk about specs or schemas.

I think "native" might mean lots of things that are unrelated to technical aspects, so I'd rather go with "OTel-ready" or "OTel compatible", as boring as they might sound. That has the added benefit that one knows what the thing is native about.

+CC @svrnm

[svrnm]

cc @open-telemetry/docs-approvers

I like this proposal, although I like to iterate over the exact terminology a little bit. What we want to express is "this library makes use of the OpenTelemetry API directly, there are no instrumentation libraries or any other workarounds needed".

I also wonder if we need to make this specific to libraries, because right now we also have apps that use OpenTelemetry "natively".

[svrnm]

A few additional suggestions:

• OpenTelemetry integrated
• OpenTelemetry enabled
• OpenTelemetry compliant (I would rather not use that one, because it implies some additional checks & "certifications")
• OpenTelemetry prepared
• OpenTelemetry included
• OpenTelemetry integrated
• OpenTelemetry built-in (see https://opentelemetry.io/community/mission/#telemetry-should-be-built-in)
• OpenTelemetry inside (...)

[chalin]

Btw, just a suggestion: we could host discussions under the Discussions section of this repo :). That would help keep discussion topics out of our already-busy Issues list.

[svrnm]

Btw, just a suggestion: we could host discussions under the Discussions section of this repo :). That would help keep discussion topics out of our already-busy Issues list.

There was some guidance in the otel community repo on when to use discussions and when not, let me double check on that, but overall I agree that we might use that instead of additional issues

[theletterf]

TIL! I'll use Discussions from now on.

[svrnm]

via https://github.com/open-telemetry/community/blob/main/docs/how-to-configure-new-repository.md:

A note on discussions: Discussions are disabled by default when creating a new repository. Maintainers may enable discussions, but in doing so take on the responsibility of moderating conversations in accordance with the code of conduct. Maintainers who enable discussions are encouraged to configure the discussion categories to suit their needs, e.g. by removing categories which overlap with issues.

[cartermp]

I would vote for otel-integrated.

[svrnm]

yes, while writing down that list otel-integrated was also my favourite

[svrnm]

looks like we have so far a preference for "opentelemetry integrated" or "otel-integrated".

[svrnm]

@open-telemetry/docs-approvers please make suggestions what you prefer so we can get to a consensus :-)

[svrnm]

Note, that "native instrumentation" is embedded in the spec:

https://github.com/open-telemetry/opentelemetry-specification/blob/9f0310fda53973e707f27e09da986f5f153f6491/specification/upgrading.md#library-maintainers

Developers who maintain OSS libraries are encouraged to use the OpenTelemetry API to add instrumentation directly into their library code. We refer to this approach as "native instrumentation."

[theletterf]

@svrnm Can we suggest a change upstream? Are we free to redefine or wrap that term in the docs?

[danielgblanco]

I personally like the term OTel-native rather than OTel-integrated for cases where libraries directly use the OTel API to produce telemetry.

Integrating with OTel can be done in many ways not related to usage of the API (e.g. collectors, shims, OTLP exporters, following semconv, etc). I think OTel-native would signal more clearly to users that a particularly library is "designed to run within the OTel ecosystem", in the same way that a component can run natively on a platform (i.e. without any type of compatibility layer).

[theletterf]

Are we free to decide within the SIG Comms on this? If that's the case, I'd say we do that and socialize our decision.

[svrnm]

We could but I would prefer some consensus across the project.

[danielgblanco]

Next maintainers call?

[theletterf]

I feel like I should be there. When's the next?

[svrnm]

Next monday might be skipped since there is otel community day, so the week after?

[svrnm]

"Native" is now part of the spec and we will stick with it