[Graduation] Dapr Graduation Application

[msfussell]

Dapr Graduation Application

Project Repo(s): https://github.com/dapr/dapr and other repos under https://github.com/dapr
Project Site: https://dapr.io/
Sub-Projects: Dapr SDKs (Java, Go, .NET, JS Python etc), cli, kubernetes-operator, installer-bundle, dashboard, dapr-shared, setup-dapr
Communication: https://github.com/dapr/community/?tab=readme-ov-file#communication-and-discord including public Discord https://discord.com/invite/dapr-778680217417809931, Maintainers Mailing Listcncf-dapr-maintainers@lists.cncf.io and regular community meetings.

Project points of contacts:

• Maintainers Mailing List cncf-dapr-maintainers@lists.cncf.io
• General Discord channel for public questions https://discord.com/channels/778680217417809931/778680217417809934 with maintainers and users

Graduation Criteria Summary for Dapr

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:

Criteria

Application Process Principles

Suggested

N/A

Required

• Give a presentation and engage with the domain specific TAG(s) to increase awareness

Suggest present to the recently formed CNCF AppDeveloper group.
See Dapr CNCF overview presentation https://youtu.be/mBgQBMhboyU

• TAG provides insight/recommendation of the project in the context of the landscape

Dapr is in the Application Definiton and Development landscape https://landscape.cncf.io/

• All project metadata and resources are vendor-neutral.

They are all vendor neutral, including communication, raising of feature proposals and governance.

• Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.
  • Met during Project's application on 18-Sept-2023. The initial PR Dapr Graduation Proposal

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies 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.

Project documentation - https://docs.dapr.io/
Project getting started and samples - https://docs.dapr.io/getting-started/

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

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 Dapr project has a Steering and Technical Committee (STC) consisting of Alibaba, Diagrid, Intel and Microsoft. The STC has been in place since Nov 2021 when Dapr was submitted to CNCF.
In Oct 2023 open elections were held and a new STC was voted in, currently at 7 members. We are looking to expand the STC to 9 or 11 members from companies who are looking to have a deeper engagement with the project.

Required

• Clear and discoverable project governance documentation.

These are the project Roles, the Membership levels and Community Managers responsibilities

• Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

The Dapr project has a Steering and Technical Committee (STC) consisting of Alibaba, Diagrid, Intel and Microsoft. See STC charter and members. The agenda and notes from each STC meeting held each month are recorded in issues. Annual goals are set in Dec for example 2023 goals and 2024 goals

In Oct 2023 open STC elections were held and a new STC was voted in, currently at 7 members. We are looking to expand the STC to 9 or 11 members.

• Governance clearly documents vendor-neutrality of project direction.

All of our decisions today are made by maintainers who're actively involved in the project. We've set out a clear path for people to become a maintainers. We have maintainers spread across several companies and will always include more.

• Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

See STC inclusion above in leadership. We actively encourage contributions from everyone and the process is documented here https://docs.dapr.io/contributing/. For large feature work we have proposals repo with guidance that anyone can raise an issue for review and discussion by the maintainers. These open issues are discussed in the twice monthly public community calls and as needed proposal calls.

• Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

Dapr has a release process and for each release a new release team is formed. The release follows the release process.

• Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

List of maintainers. A separate list of contact information and domain of responsibility is managed for the maintainer but not made public due to personal information. This is available if required.

• A number of active maintainers which is appropriate to the size and scope of the project.
  There are 21 maintainers from 6 different companies.

• Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).

The maintainer lifecycle is documented here

• Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.

There have been several maintainers that had been approved into the project repos as well as ones who have left over the 4.5 years of the project. Maintainers for SDKs, docs, CLI and dapr have left and new maintainers added.

For example in the last 6 months this has occured in the .NET SDK (Maintainer Removal, Maintainer Addition). There are also Approvers in several repos (for example SDKs) who are on a path to maintainers.

• Project maintainers from at least 2 organizations that demonstrates survivability.

There are 21 maintainers from 6 different companies.

• Code and Doc ownership in Github and elsewhere matches documented governance roles.

This is documented in the governance process for maintainers. GitHub Teams for Approvers and Maintainers are managed for each repo. As a person goes through the maintainer lifecycle they are moved between the github teams for levels of access control.

• Document agreement that project will adopt CNCF Code of Conduct.

We operate under the CNCF CoC

• CNCF Code of Conduct is cross-linked from other governance documents.

The Code of Conduct is in the governance document on project membership

• All subprojects, if any, are listed.

All the subproject are list in the repos

• If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

All subprojects are included in the governance.

"This doc outlines the responsibilities of contributor roles in Dapr. The Dapr project is subdivided into sub-projects under (predominantly, but not exclusively) runtime (dapr), components-contrib, CLI, quickstarts, docs and language-specific SDKs. Responsibilities for roles are scoped to these sub-projects (repos)."

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

• Contributor ladder with multiple roles for contributors.

Covered in the community governance

Required

• Clearly defined and discoverable process to submit issues or changes.

See docs contributing guide. We also have a proposals repo for significant feature triaging and development.

• Project must have, and document, at least one public communications channel for users and/or contributors.

We have several https://github.com/dapr/community?tab=readme-ov-file#communication-and-discord

• 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.

All documented here

• Up-to-date public meeting schedulers and/or integration with CNCF calendar.

Public Dapr community meetings are listed in the CNCF calendar

All community calls and STC meetings are tracked as issues in the community repo. These are the Upcoming community calls

Each week there is an public release milestone meeting on the status of the project where anyone can comment on an issue in the milestone.

• Documentation of how to contribute, with increasing detail as the project matures.

All contributing guidelines are here. We also encourage contributors to become part of the project release team

• Demonstrate contributor activity and recruitment.

We actively acknowledge contributors for each release in release notes (for example the v1.13.0 release here https://github.com/dapr/dapr/releases/tag/v1.13.0) and celebrate them on X.com. Our contributors numbers have been growing each release for the last 4 years. We're using digital badges (by Holopin) to award contributors (example1, example2). We were the first to start using holopin badges, which we introduced to all of CNCF to use in other projects.

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.

The overview says it all.

"Dapr is a portable, event-driven runtime that makes it easy for any developer to build resilient, stateless, and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks. Dapr codifies the best practices for building microservice applications into open, independent APIs called building blocks."

The Dapr APIs have become the standard for developing cloud native applications, and increasing in platform engineering teams exposing an API to their developers.

• Document what the project does, and why it does it - including viable cloud native use cases.

The website and the overview cover this

• Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

See the roadmap document which is updated during the planning phase of each release (3-4 time per year).

Release planning milestones issues are used for roadmap planning for upcoming milestones

• Roadmap change process is documented.

See the roadmap document which is updated during the planning phase of each release.

• Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.

Dapr is built as a sidecar process for each application and also has a control plane for different hosting environments including Kubernetes.

• Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:

  • 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.

The release process is described here this includes the use of the release end-game template that is used to track the actions and artifacts for each release.

The release process covers versioning, tagging and branching

• History of regular, quality releases.

The supported versions are documented here with the release notes, along with overall release support

Security

Note: this section may be augemented by a joint-assessment performed by TAG Security.

Suggested

• Achieving OpenSSF Best Practices silver or gold badge.

We'll look into this, however this is not an immediate priority for the project.

Required

• Clearly defined and discoverable process to report security issues.

Reporting security issues describes the process.

• Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)

2FA is required for GitHub org members.

• Document assignment of security response roles and how reports are handled.

See the security response process. By way of an example of this in practice, the latest v1.13.4 patch release was due to a reported CVE, showing that this process is in operation.

• Document Security Self-Assessment.

We did self assessment at the v1.0 on the release of the project with threat modelling and have maintained a continuous security review processes since.

• Third Party Security Review.

  • 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.

See latest completed audit and [annoucement]. (https://blog.dapr.io/posts/2023/09/05/dapr-completes-2023-security-audit-increasing-enterprise-confidence/).

3 independent audits have been done in life of the project.

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

https://www.bestpractices.dev/en/projects/5044

Ecosystem

Suggested

N/A

Required

• Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

We have a list of adopters but it is always challenging to get users to include themselves in this. A more detailed list is on our 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)

Dapr is used by over 38k known companies. See CNCF Case Studies for examples of adopters in production today and listed below.

• Derivco
• Tempestive
• HDFC Bank
• DeFacto
• UISEE
• Wortell
• At-Bay

Also others to include;

• Grafana Labs
• Zeiss
• Nasa
• Volvo
• Cisco
• PwC
• Honeywell

The project has 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.

• TOC verification of adopters.

We've supplied users in the internal graduation doc who've all agreed to be interviewed. Refer to the Adoption portion of this document.

• Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.

Dapr integrates with many CNCF projects, including;

• Kubernetes as a hosting platform with the Dapr Control Plan
• Helm used to deploy Dapr's control plane to Kubernetes.
• CloudEvents for all publish/subscribe events.
• gRPC for high-performance remote procedure calls (RPC).
• SPIFFE for identifying services and securing communications between application services.
• Open Telemetry to generate, collect, and export telemetry data, using the OT SDK and OT Collector
• Prometheus to collect and analyze runtime metrics.
• Jaeger for distributed tracing.
• Kratix

Adoption

Adopter 1 - Zeiss /Manufacturing - used from 04/2020

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient.

Adopter 2 - Grafana Labs/Monitoring - used from 08/2022

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient.

Adopter 3 - Organization/Financial - used from 07-2023

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient.

Adopter 4 - SharperImage Online/Retail - used from 06-2022

If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient.

[salaboy]

Awesome! I am looking forward to this graduation!

[cmendible]

Yes! Way to go!

[daixiang0]

So cool! Looking forward to this graduation!

[angellk]

Update: Adopter interview 1/5 completed cc: @dims

[angellk]

Update: Adopter interview 2/5 completed cc: @dims

[angellk]

Update: Adopter interview 3/5 completed cc: @dims

[angellk]

Update: Adopter interview 4/5 completed cc: @dims

[dims]

@msfussell Karena and I met late last week and we are generally positive! one thing that did stand out is that TAG interactions are a bit dated. The Dapr CNCF overview presentation to AppDeveloper group is great! but we should do some more work to line up support for the graduation.

Can you please work with the following tags?

• TAG contributor strategy to do a governance review - https://github.com/cncf/tag-contributor-strategy/issues (example cert-manager)
• TAG security self assessment - https://github.com/cncf/tag-security/blob/main/community/resources/project-resources/security-hygiene-guide.md#2-self-assessment (example for Add cert-manager graduation self-assessment tag-security#1269 )
• TAG App Delivery - Presentation to get feedback for graduation proposal (examples in-toto and cert-manager)

Thanks!

[angellk]

Closing as complete.
xref: cncf/landscape#4124 #1454