Re: [VOTE] OpenTelemetry for incubation

Alena Prokharchyk


Thank you for advocating on behalf of end-users. 

Keeping focus on end-user adoption, experience, and ensuring that components maturity is communicated to the users transparently ( ), was an essential part of OpenTelemetry Due Diligence. OpenTelemetry is widely adopted by end-user companies at scale, and interviewing them as part of the process was insightful. One of the common requests was to clarify OpenTracing place. OpenTracing is CNCF Incubating project, but it's being merged to OpenTelemtry which exists at Sandbox level. As a part of OpenTelemetry incubation, OpenTracing will be archived from CNCF; here is the deprecation plan: . Another common question was around integration with OpenMetrics, and it is already being prioritized by OpenTelemetry team. Together with the Prometheus and OpenMetrics community, the workgroup was formed, with weekly meetings that move this work forward.

It is true that not all the signals are not GA at this point. And it's common for projects to have experimental features. Given OpenTelemetry scope, getting the remaining current features to GA will take some community effort. OpenTelemetry already has an inclusive governing model and diverse committers base. Project moving to Incubation will help with the community growth, existing features hardening and new features/integrations development.


On Jul 6, 2021, at 3:23 PM, Eduardo Silva <eduardo@...> wrote:

-1 non-binding
Disclaimer: I like OTel project and even in Fluent ecosystem we are working towards integration with it.
My reasons might be controversial but I think OTel is not ready for incubation "yet".
As an end-user and project maintainer, I care about usability. OTel aims to cover Traces, Metrics, and Logs:
  • At this point, only Traces are in GA state. Usable.
  • Metrics: API and SDKs are "DRAFT" and the collector is experimental. Per my understanding, there is no stable integration with openmetrics or Prometheus ecosystem (for me and "many companies" this is a must). Partial usable.
  • Logs: API and SDKs are "DRAFT", the collector is experimental. Not usable.
A project at the incubation stage has to demonstrate maturity and wide adoption, if this is not the case as a foundation (CNCF) we might be sending the wrong message to the end users.
We aim to incubate projects with enough maturity and a minimal level of usability, but this is not the case. This is nothing against OTel but a purely technical opinion. I know we cannot incubate a sub-set of it like Traces only, but this is a complete offering and there are missing pieces of integration and implementation.
I think moving OTel to incubation might help cloud vendors to spread the message, but what about the end users?
The formal doc states:
"TOC acknowledged the gaps in stability and adoption of significant Logging and Metric parts of the OpenTelemetry project. TOC confirmed it should not be a blocker for incubation. "
I disagree, I think this is a blocker, there is so much pressure from vendors..., and rushing things might not be beneficial for the long term.
Why not wait a bit more and do a proper incubation with the minimal pieces on it? I think staying in Sandbox a bit more will be beneficial for the project while rushing it might hurt the ecosystem.

On Tue, 6 Jul 2021 at 15:48, Bob Killen <killen.bob@...> wrote:
+1 non-binding.

On Tue, Jul 6, 2021 at 3:31 PM Amye Scavarda Perrin <ascavarda@...> wrote:
OpenTelemetry has applied to move from Sandbox to Incubation.

Due Diligence (DD) doc: 

Alena Prokharchyk has called for public comment ( and has approved a call for a public vote.
Please vote (+1/0/-1) by replying to this thread.

Remember that the TOC has binding votes only, but we do appreciate non-binding votes from the community as a sign of support!

Amye Scavarda Perrin | Program Manager | amye@...


Join to automatically receive all group messages.