[Graduation] OpenTelemetry Graduation Application
Review Project Moving Level Evaluation
- [x] I have reviewed the TOC's moving level readiness triage guide, ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed.
OpenTelemetry Graduation Application
v1.6
This template provides the project with a framework to inform the TOC of their conformance to the Graduation Level Criteria.
Project Repo(s): https://github.com/open-telemetry
Project Site: https://opentelemetry.io
Sub-Projects: OpenTelemetry Specification, Collector, Client SDKs (.NET, Go, Java, JavaScript/TypeScript, Python, Ruby, PHP, C++, Rust, Erlang/Elixir), Operator, Demo, Contrib repos
Communication: CNCF Slack (#opentelemetry, language/SIG-specific channels)
Graduation point of contact: Austin Parker (mailto:[email protected]) Project points of contacts: Governance Committee (mailto:[email protected])
- [ ] (Post Graduation only) Book a meeting with CNCF staff to understand project benefits and event resources.
Graduation Criteria Summary for OpenTelemetry
Application Level Assertion
- [x] This project is currently Incubating, accepted on 2021-08-11, and applying to Graduate.
Adoption Assertion
The project has been adopted by the following organizations in a testing and integration or production capacity:
OpenTelemetry is used at hundreds (potentially thousands) of organizations worldwide. We maintain a best-effort list of adopters on our website, including the following --
- bureau.id
- Dyte
- eBay
- Ecobee
- Farfetch
- GitHub
- Global Processing
- MercadoLibre
- NAV - Norweigen Gorvernment
- Sicredi
- Skyscanner
- Uplight
- VTEX
In addition, OpenTelemetry is supported by all major observability vendors as of this writing. In no particular order --
- Datadog
- New Relic
- Splunk Observability
- Honeycomb
- Cisco AppDynamics
- Dynatrace
- ServiceNow Cloud Observability (fka Lightstep)
- Sumo Logic
- IBM Instana
- Grafana
- SigNoz
- Logz.io
- Elastic Stack
- AWS CloudWatch (X-Ray)
- Azure Monitor
- Google Cloud Operations
Application Process Principles
Suggested
N/A
Required
-
[x] Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.
- OpenTelemetry delivered multiple updates to TAG Observability, most recent update on 12/18/2024.
-
[x] TAG provides insight/recommendation of the project in the context of the landscape
- TAG Observability filed a positive recommendation in cncf/toc#N NNNN. [INFO NEEDED – link once opened]
-
[x] All project metadata and resources are vendor-neutral.
- Governance charters limit representation to prevent any single vendor dominance.
- Community standards prioritize vendor neutrality in interactions and engagements.
- Please see https://github.com/open-telemetry/community/blob/main/mission-vision-values.md for more.
- Please see https://opentelemetry.io/community/marketing-guidelines/ for information about vendor-neutral marketing guidelines.
-
[x] Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.
- Acknowledged during this application (May 2025).
Completion of this due diligence document, resolution of concerns raised, and presentation for public comment satisfies the Due Diligence Review criteria.
- [x] Additional documentation as appropriate for project type, e.g.: installation documentation, end-user documentation, reference implementation and/or code samples.
- Comprehensive docs at https://opentelemetry.io/docs/ and reference demo app.
- SIGs also maintain language or component specific documentation where appropriate; See this README.md as an example.
- We maintain an evolving set of guides for contributors and maintainers as well.
Governance and Maintainers
(May be augmented by TAG Contributor Strategy Governance Review)
Suggested
- [x] Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.
- Governance Committee charters revised in Sep 2024 to reflect project scale and lessons learned.
- As of May 2025, we are revising the Technical Committee charter to improve project resiliency, velocity, and set us up for scaling into the future.
- In addition, we've established wide-ranging changes to our project and SIG governance strategies over the years in order to empower maintainers as well as manage scope and complexity.
Required
- [x] Clear and discoverable project governance documentation. – See https://github.com/open-telemetry/community.
- [x] Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.
– Elections are held annually, most recently in October 2024.
- All governance committee meeting notes are published here. Recordings of GC meetings are available upon request.
- The community repository contains other relevant documentation.
- [x] Governance clearly documents vendor-neutrality of project direction. – A maximum of two members from a single organization can participate on the Governance Committee or Technical Committee.
- [x] Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.
– Defined in GC and TC charters; OTEP RFC process governs technical decisions.
- Please see the OTEP Process for more information.
- [x] Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).
– The membership ladder describes our basic roles and functions.
- Each SIG or Project may expand upon these basic guidelines if needed.
- An example of this is the Collector's CONTRIBUTING.md file.
- [x] Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation. – The maintainer's list on our website draws from GitHub and documents all members and their roles.
- [x] A number of active maintainers appropriate to size/scope.
– Given the size and scope of OpenTelemetry, we have a large amount of maintainers.
- Governance consists of 9 members, and the TC currently sits 8 (see https://github.com/open-telemetry/community/blob/main/community-members.md)
- We currently have over 120 maintainers across all projects and SIGs.
- [x] Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status). – Please see this guide.
- [x] Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.
– 2023–24 saw 7 new maintainers added, 4 moved to emeritus.
- Most recently, a TC member stepped down and moved to emeritus. https://github.com/open-telemetry/community/pull/2756
- [x] Project maintainers from at least 2 organizations that demonstrates survivability. – Maintainers span >15 companies.
- [x] Code and Doc ownership in GitHub matches governance roles.
– CODEOWNERS files auto-synced with GitHub teams.
- We are currently in the process of adopting a more robust IaC solution to manage ownership and provide a single source of truth; See https://github.com/open-telemetry/community/issues/1596
- [x] Document adoption of the CNCF Code of Conduct – Linked in every repo’s
README. - [x] CNCF Code of Conduct is cross-linked from other governance documents.
- [x] All subprojects are listed. – See “SIGs and Working Groups” table in community repo.
- [x] If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.
– Each SIG README lists maintainers and signal maturity.
- This document is the canonical reference for membership.
Contributors and Community
(May be augmented by TAG Contributor Strategy Governance Review)
Suggested
- [x] Contributor ladder with multiple roles for contributors
– We have a contributor ladder that defines roles from member to emeritus maintainer.
- See Membership, Roles, and Responsibilities for more details.
Required
- [x] Clearly defined and discoverable process to submit issues or changes.
– CONTRIBUTING guides; GitHub PR flow.
- See https://github.com/open-telemetry/community/blob/main/guides/contributor/processes.md#file-an-issue for more information, as well as the entire Contributor guide.
- [x] Project must have, and document, at least one public communications channel for users and/or contributors. – Our primary public communications channel for announcements and information is our blog on opentelemetry.io.
- [x] List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.
– OpenTelemetry, as a large project, supports many communication channels in order to meet our community where they are. The following list is intended to be exhaustive.
- CNCF Slack: #opentelemetry, as well as various SIG channels with #otel- prefix. The sigs.yml document contains all of these, and is the source of truth.
- Social Media: We maintain an active Mastodon, Bluesky, LinkedIn, and YouTube presence. Links to all of these can be found on our main website, opentelemetry.io
- Web and Email: Our canonical source for announcements is opentelemetry.io. We are moving towards a consolidated listserv approach, as our listservs are rarely utilized.
- Non-public channels: Project leadership maintains several private channels on CNCF Slack for async discussion about private topics, including security topics.
- [x] Up-to-date public meeting schedulers and/or CNCF calendar integration.
– Due to the amount of SIG meetings the project supports, we offer multiple options for calendering.
- Our primary calendars are listed on the community repository, but individual SIGs get their own calendar to avoid meeting spam.
- [x] Documentation of how to contribute, with increasing detail as the project matures.
– Our contributor guide collects a variety of guidance on project-wide processes.
- Individual SIGs may go beyond this and provide SIG-specific guidance in their CONTRIBUTING.md files.
- Recently, we launched our Contributor Experience SIG to further study and make recommendations on improving the contribution experience, especially for new contributors.
- [x] Demonstrate contributor activity and recruitment.
– OpenTelemetry is one of the largest and most active projects in the CNCF.
- We have over 150 unique contributing companies each month, and over 1100 unique contributors a month since the beginning of 2024.
- See DevStats for more detailed information.
Engineering Principles
- [x] Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently. This requirement may also be satisfied by completing a General Technical Review.
– OpenTelemetry seeks to provide a standard, vendor-agnostic, cloud-native, and fully featured telemetry framework.
- Please see our Mission, Vision, and Values statement for more.
- [x] Document what the project does, and why it does it - including viable cloud native use cases. This requirement may also be satisfied by completing a General Technical Review – Our documentation lays out a general overview of the purpose and goals of the project, along with details about usage.
- [x] Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.
– We maintain several different roadmap documents, and are in the process of consolidating them.
- A narrative roadmap document is published by the GC to discuss top-level organization priorities.
- Our project board contains in-progress projects and deliverables for the entire organization.
- We track specification projects and OTEPs here.
- Individual SIGs maintain their own roadmaps and publicize them through our blog and GitHub.
- [x] Roadmap change process is documented.
– Our project management process describes how non-trivial specification or scope changes are handled at an organizational level.
- Individual SIGs may adopt this, or their own process.
- [x] Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This requirement may also be satisfied by completing a General Technical Review and capturing the output in the project's documentation.
– Our documentation contains a variety of examples on how to conceptually integrate OpenTelemetry into cloud-native workloads.
- Our specification also includes a thorough architectural overview for each component.
- [x] Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:
- Release expectations – Each SIG may choose its own cadence for releases based on the idioms of their language. Conventionally, these are documented in a VERSIONINING.md or other document. All SIGs must follow organization-level guidance on versionining and stability.
- Tagging and tag strategies – Please see versioning and stability for a complete discussion. In general, we define broad classes (experimental, stable, deprecated) and allow SIGs to use language-conventional mechanisms to communicate those expectations.
- Branch/platform support & support window – Versioning and stability defines the length of support for releases.
- Artifacts – Each SIG distributes artifacts through language-conventional mechanisms including package registries, container registries, .deb and .rpm files, etc. We rely on GitHub as the source of truth for all binary artifacts.
- [x] History of regular, quality releases. – Each SIG releases on a self-directed cadence based on project needs. Some SIGs release biweekly, some monthly, others as-needed. Our upgrade policy defines our goals around backwards compatibility and upgrade process for consumers of telemetry and other artifacts.
Security
(May be augmented by TAG Security assessment)
Suggested
- [ ] Achieving OpenSSF Best Practices silver or gold badge. – In progress.
Required
- [x] Clearly defined and discoverable process to report security issues.
– GitHub “Security” tab.
- https://github.com/open-telemetry/.github/blob/main/SECURITY.md
- [x] Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)
– 2FA required for org members; branch protections enabled.
- https://github.com/open-telemetry/community/blob/main/docs/how-to-configure-new-repository.md#branches--branch-protection-rules
- In addition, our new IaC system will provide a single source of truth and access management for ancillary resources (cloud accounts, gdocs, etc.)
- [x] Document assignment of security response roles and how reports are handled.
– Our Security SIG documents our response roles, charter, and processes.
- https://github.com/open-telemetry/sig-security/blob/main/security-response.md
- https://github.com/open-telemetry/sig-security/blob/main/sig-security-charter.md
- [x] Document Security Self-Assessment. – See https://github.com/cncf/tag-security/blob/main/community/assessments/projects/open-telemetry/self-assessment.md
- [x] Third Party Security Review.
– Audit by OSTIF/7ASecurity, Jan 2024; all high/medium issues fixed.
- See https://7asecurity.com/reports/pentest-report-opentelemetry.pdf for full report.
- We have also undertaken a fuzzing audit of the Collector; See https://opentelemetry.io/blog/2024/fuzzing-audit-results/
- [x] Achieve the OpenSSF Best Practices passing badge.
– Collector and core SDKs have Passing badge.
- See https://www.bestpractices.dev/en/projects?q=OpenTelemetry for a full report. We continually work to improve our best practices across all SIGs.
- https://github.com/open-telemetry/sig-security/blob/main/security-dashboard.md also contains an overview of OpenSSF scorecards by repository.
Ecosystem
Suggested
N/A
Required
- [x] Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)
– Our website has a list of adopters.
- We also have a variety of self-identified adopters that are not captured in this list, for some more examples please see our most recent KubeCon Project Update
- [x] Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters) – The project has provided a variety of public and non-public adopters to the TOC; You can also refer to the adopter list linked earlier as well as at the preface to this issue.
- [ ] TOC verification of adopters. – Pending TOC.
- [x] Clearly documented integrations and/or compatibility with other CNCF and non-CNCF projects.
- Prometheus
- Jaeger
- Envoy
- Linkerd
- Kubernetes
- And many more including Kafka, Cortex, Cri-O, Harbor, KEDA, Keycloak, Kyverno, OpenFeature, MySQL, and hundreds of other libraries and frameworks.
Adoption
These are three examples of the many organizations and verticals that have adopted OpenTelemetry.
Adopter 1 – Amazon Web Services / Cloud Provider
Production since 2021 via the AWS Distro for OpenTelemetry.
Adopter 2 – Shopify / E-commerce
Production since 2020; KubeCon EU 2020 talk “Observability at Shopify with OpenTelemetry”.
Adopter 3 – ecobee / Consumer IoT
Production since 2021; case study on Honeycomb blog.
Additional adopters available upon request.
Status Update: Dims and I are continuing to review the project. We will be reaching out for adopter interview scheduling in the next two weeks.
Status Update: Emailed 5 of the submitted adopters to begin scheduling interviews.
Status update: No response yet from any adopters, resent requests to the same adopter short list. continuing review of the project, waiting on the governance review to be completed so we can incorporate those items.
I've posted a WIP of the gov review here: https://github.com/cncf/toc/pull/1801
It has all the questions answered, but not the summary. TL;DR excellent, no major blockers
Status update: An unlisted/unsubmitted adopter reached out to see if they can assist with the graduation for the project. I've reached out to coordinate for potential interview.
Status update: Emailed the unlisted/unsubmitted adopter for scheduling.
-edit- Nearly complete with the DD a few outstanding items to do:
- get summary and finalization of governance review merged into TOC repo
- indepth review of the security audit to surface any untracked recommendations, findings requiring mitigation are already addressed
- Ecosystem review (Adopter interviews)
-/edit-
Status Update: 1 adopter has responded affirmatively. Working on getting them scheduled now. reached out to 1 more adopter TAB is reaching out to End Users again for requests for participation CNCF Staff are also reaching out.
Hi folks, saw this tweet asking for OTel adopters to speak for the graduation application of OTel. I’m at a CNCF end-user company and we are an adopter of OTel. Happy to help.
Responding to the tween. End User (Intuit) and we are adopters for Otel. Willing to be interviewed.
@venkspr Fabulous! If you are in CNCF Slack or Kubernetes Slack, could you send me a DM (Emily Fox, TheMoxieFox) with your email so i can send you the information?
same @Debanitrkl If you are in CNCF Slack or Kubernetes Slack, could you send me a DM (Emily Fox, TheMoxieFox) with your email so i can send you the information?
Status update: 2 adopter interviews scheduled! 🥳
[Status Update] Adopter interview 1 is completed and the summary has been sent for approval.
[Status Update] Adopter 1 has approved the content Adopter 2 interview has been completed and summary has been sent for approval Adopter 3 interview has been completed and summary has been sent for approval
Two more adopters have scheduled for a total of 5 adopters.
Adopter 2 interview was approved. Status of recommendations and non-critical/high findings from Security Audit now captured in the DD Draft. pending two more adopter interviews to occur, already scheduled.
Status update: Adopter 3 - pending approval Adopter 4 - waiting on input to finalize the interview, draft summary, and then receive approval.
No further adopter interviews scheduled/needed. Once these are complete @dims and I will sync on next steps with the TOC.
Status update: Adopter 3 - pending approval Adopter 4 - summary sent, pending approval Adopter 5 - pending scheduling. We will move forward with this interview in the event adopter 3 isnt able to receive approval.
Status Update: Adopter 3 - pending approval Adopter 4 - approved Adopter 5 - pending scheduling
The TOC met with the OTel GC and TC to discuss the current status of the graduation due diligence, opportunities for improvement and to gain better clarity on the complexity and scoping of the project and it's governance. The following items were taken for action:
- Stability and core components will be clarified and documented.
- Will roadmap the stability of the collector and for contrib.
- Will publish the guarantees for components moving to 1.0
- TOC will conduct more adopter interviews - @austinlparker will get the list of adopters to @TheFoxAtWork and @dims to conduct further interviews and receive well-rounded feedback for the project.
- TOC and GC/TC will sync up next after KCCN 2025 NA.