[Graduation] gRPC Graduation Application #2101
Description
Review Project Moving Level Evaluation
- 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.
gRPC 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/grpc/grpc
- https://github.com/grpc/grpc-java
- https://github.com/grpc/grpc-go
- https://github.com/grpc/grpc-node
- https://github.com/grpc/grpc-web
- https://github.com/grpc/grpc-kotlin
- https://github.com/grpc/grpc-swift
- https://github.com/grpc/grpc-dotnet
- (and all other repos under https://github.com/grpc/)
Project Site: https://grpc.io
Languages:
- gRPC Go
- gRPC Java
- gRPC Swift
- gRPC Dot Net
- gRPC C++
- gRPC Python
- gRPC Node
- gRPC Rust
- gRPC Ruby
- gRPC PHP
Communication: https://groups.google.com/g/grpc-io
Project points of contacts:
- E John Feig, ejf@google.com (Primary)
- Richard Belleville, rbellevi@google.com
- (Post Graduation only) Book a meeting with CNCF staff to understand project benefits and event resources.
Graduation Criteria Summary for gRPC
Application Level Assertion
- This project is currently Incubating, accepted on 2017/02/17, and applying to Graduate.
Adoption Assertion
The project has been adopted by the following organizations in a testing and integration or production capacity:
- Netflix
- Spotify
- Discord
- The Kubernetes Open Source Project
- Alphabet
- Datadog
- Uber
- Broadcom
- Cisco
- and many others...
Application Process Principles
Suggested
N/A
Required
-
Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.
A General Technical Review was completed/updated on 24-03-2026, and can be discovered here. -
All project metadata and resources are vendor-neutral.
-
Communication:
- Project Website: grpc.io is hosted on GitHub under the CNCF
- Blog: Hosted as a part of the project website, on GitHub under the CNCF
- Mailing list: Hosted on Google Groups, Maintainers have admin access
- Gitter: Hosted on Gitter
-
Hosting
- Source Code: Hosted on GitHub under the CNCF
- Design Review / Roadmap (gRFCs): Hosted on GitHub under the CNCF
-
Architectural Decisions
Architectural decisions are driven by the vendor-neutral gRFC process.
This process has a solid track record of driving actual changes in the project, with well over 100 proposals accepted, the vast majority of these having been implemented.Accepted gRFCs have been authored by many different companies/organizations, including:
- Dropbox
- Microsoft
- Netflix
- Spotify
- Amazon
-
-
Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.
-
Due Diligence Review.
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
-
Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.
gRPC is very well documented as a result of a multi-year effort. Our project website is the hub for this documentation:
Governance and Maintainers
Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.
Suggested
-
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.
The gRPC project governance was first put into place in 2018.
This iteration of the governance supported the project for several years until, in 2025, the sheer number of maintainers with differing levels of expertise in domain
areas and experience in the project resulted in the introduction of a contributor ladder
and overhaul of the governance. The gRPC project continues to monitor the effectiveness of the governance and evaluate ways
to improve it.
Required
-
Clear and discoverable project governance documentation.
-
Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.
The grpc-community repo is kept up-to-date with elections and leadership activities. This has become more of a focus since our
governance overhaul in summer 2025. -
Governance clearly documents vendor-neutrality of project direction.
gRPC has a vendor-neutral open collaboration policy.
Anyone has the ability to open pull requests. Anyone has the ability to discuss them. In addition, Maintainers are expected to act in the interest of the project, independent of their employer.The contributor ladder further outlines a process for anyone to advance in the project, regardless of their organizational affiliation or employer.
-
Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.
All of the gRPC project's decision-making processes are outlined in its governance:
- Contributor Ladder Promotion (including becoming a Maintainer)
- Steering Committee Elections
- Everyday contribution acceptance
- Substantial Changes / gRFCs
- Interacting with the CNCF on the behalf of the project is a privilege granted to Steering Committee Members and Maintainers
- Governance Changes
-
Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).
Areas of expertise are tracked beginning with the second level of our contributor ladder (Core Contributor)
These areas of expertise include individual language implementations (such as C++, Java, and Go), as well as cross-cutting concerns, such as Security. Core Contributors and Maintainers are promoted on the basis of their
contributions in their area(s) of expertise and sponsors for promotion to Core Contributor must also have status in the candidate's area of expertise (tracked at the repo level).The addition of a new area of expertise or removal of an area of expertise is treated like taking on or stepping down from status at a level in the contributor ladder (example). The process for stepping down from a contributor role is documented here.
-
Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).
The full contributor ladder is documented here, with an individual roster for each level in the ladder:
The contributor ladder covers the criteria to join each level in the ladder:
Offboarding and emeritus status is handled the same way regardless of level in the ladder and is covered in this section. Involuntary removal due to inactivity is covered in this section.
-
Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.
-
Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.
The complete current roster of Maintainers is available here.
-
A number of active maintainers which is appropriate to the size and scope of the project.
The gRPC project has 13 current Maintainers and 83 total active contributors in the ladder. This number has been appropriate to handle the 10+ supported languages and several cross-cutting areas of expertise.
-
Project maintainers from at least 2 organizations that demonstrates survivability.
4 organizations are currently represented in the Maintainers list:
- Apple
- Datadog
- Microsoft
-
Code and Doc ownership in Github and elsewhere matches documented governance roles.
-
Document adoption and adherence to the CNCF Code of Conduct or the project's CoC which is based off the CNCF CoC and not in conflict with it.
The project governance states that members must abide by the CNCF Code of Conduct.
-
CNCF Code of Conduct is cross-linked from other governance documents.
The CNCF Code of Conduct is explicitly cross-linked from the various repos within the gRPC project. For example:
-
All subprojects, if any, are listed.
The gRPC project does not have subprojects. While there are many different language implementations/repositories, these implementations must coordinate tightly with one another in order to maintain compatibiliity and a consistent user experience across languages. As a result, we have teams within the project but no independent subprojects.
-
If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.
The gRPC project does not have subprojects.
Contributors and Community
Suggested
-
Contributor ladder with multiple roles for contributors.
The gRPC Contributor Ladder is defined here.
Required
-
Clearly defined and discoverable process to submit issues or changes.
There is an overall gRPC project
CONTRIBUTING.mdfile in the grpc-community repo. In addition, more specific instructions are provided in several of the individual repositories: -
Project must have, and document, at least one public communications channel for users and/or contributors.
-
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.
Subprojects communicate primarily via their Github repos (PRs and Issues). Additional communication between contributors generally happens through direct messages.
-
Up-to-date public meeting schedules and/or integration with CNCF calendar.
gRPC virtual and in-person meetups are advertised on meetup.com.
-
Documentation of how to contribute, with increasing detail as the project matures.
As mentioned above, there is an overall gRPC project
CONTRIBUTING.mdfile in the grpc-community repo. In addition, more specific instructions are provided in several of the individual repositories: -
Demonstrate contributor activity and recruitment.
The gRPC project had two of the top 10 most prolific contributors within the CNCF (featured at Kubecon NA 2025). As of July 2025, the gRPC project had the 9th highest contributor count within the CNCF.
The gRPC project speaks at nearly all Kubecons, soliciting new contributors at the end of each talk. In addition, numerous solicitation attempts are made during the annual gRPConf event.
Engineering Principles
-
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.
- A General Technical Review was completed/updated on 24-03-2026, and can be discovered here.
-
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.
- A General Technical Review was completed/updated on 24-03-2026, and can be discovered here.
-
Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.
The project roadmap is defined by gRFCs, housed in this repository.
-
Roadmap change process is documented.
The process for writing and reviewing gRFCs is outlined here.
-
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.
- A General Technical Review was completed/updated on 24-03-2026, and can be discovered here.
-
Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:
The release process is documented here and linked to from the project governance here.
- Release expectations (scheduled or based on feature implementation)
- Tagging as stable, unstable, and security related releases
- Information on branch and tag strategies
- Branch and platform support and length of support
- Artifacts included in the release.
- Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out.
-
History of regular, quality releases.
The latest version of gRPC is v1.78, the 78th minor version since 1.0 in 2015. We have been releasing on a 6 week cadence for years. (C++ releases, Go releases, Java releases)
Security
Note: this section may be augmented by a joint-assessment performed by TAG Security and Compliance.
Suggested
- Achieving OpenSSF Best Practices silver or gold badge.
Required
-
Clearly defined and discoverable process to report security issues.
The CVE reporting process is defined here.
-
Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)
All gRPC project contributors are required to enable 2-factor authentication in GitHub and access to repos is strictly controlled by Maintainers.
-
Document assignment of security response roles and how reports are handled.
Security specializations are granted to gRPC project Core Contributors and gRPC project Maintainers based on their contributions in the security domain.
-
Document Security Self-Assessment.
The gRPC project's security self-assessment can be found here.
-
Third Party Security Review.
The gRPC project completed a Security Audit with cure53. The report is available here.
- Moderate and low findings from the Third Party Security Review are planned/tracked for resolution as well as overall thematic findings, such as: improving project contribution guide providing a PR review guide to look for memory leaks and other vulnerabilities the project may be susceptible to by design or language choice ensuring adequate test coverage on all PRs.
-
Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.
Ecosystem
Suggested
N/A
Required
-
Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)
While gRPC's adopters are too numerous to centrally track them all, several are listed on the showcase page of the project website.
-
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 showcase shared above lists tens of adopters out of the thousands of companies using gRPC.
The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.
- TOC verification of adopters.
Refer to the Adoption portion of this document.
-
Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.
This is discussed at length in the General Technical Review.