Skip to content

[Graduation] Dragonfly Graduation Application #1358

New issue
New issue
Open
Open
[Graduation] Dragonfly Graduation Application#1358
Assignees
angellkkevin-wangzefeng
Labels
gitvotegitvote/closedgitvote/passedkind/ddProject DD or item related to the DD processlevel/graduationItem related to a graduation level project or the graduation criteria/process itself.
Milestone
Q4 2025
@gaius-qi

Description

@gaius-qi
gaius-qi
opened on Jun 26, 2024

Dragonfly Graduation Application

Project Repo(s): https://github.com/dragonflyoss/dragonfly and other repos under https://github.com/dragonflyoss.

Project Site: https://d7y.io/

Sub-Projects: Dragonfly does not have formally defined "subprojects", but all repositories under the dragonflyoss adhere to the well defined governance.

Communication:

Project points of contacts:

Graduation Criteria Summary for Dragonfly

Adoption Assertion

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

Dragonfly, an open source P2P-based file distribution and image acceleration systemt, has been adopted by many prominent organizations to enhance their file and image distribution capabilities. Public adopters listed in the Dragonfly repository’s ADOPTERS.md file include major cloud and technology providers.

Criteria

Below we address the graduation criteria with detailed updates and supplements as requested.

Application Process Principles

Suggested

N/A

Required

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

Dragonfly operates according to well defined vendor-neutral governance in https://github.com/dragonflyoss/community/blob/master/GOVERNANCE.md, and all project communication, messaging, and collaboration is vendor-neutral.

  • Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.

The Dragonfly project has reviewed and understands the expectations outlined in the Cloud Native Computing Foundation (CNCF) process README and graduation criteria. As an Incubating Level Project within the CNCF, Dragonfly continues to progress through the maturity levels.

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 can be found in https://d7y.io/docs/next/. Contributor documentation for the project can be found in https://github.com/dragonflyoss/community/blob/master/CONTRIBUTING.md.

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.

Dragonfly joined the CNCF as a sandbox project in October 2018 and became an incubating project in April 2020. In January 2020, Nydus became a sub-project of Dragonfly and was widely used for image acceleration. In April 2021, the Dragonfly v2.0 was released after architectural optimization and code refactoring. Dragonfly has 12 maintainers (committers). The public list of Dragonfly adopters is in the ADOPTERS.md. We've looked to expand our governance.

Decision-Making Process:
Decisions are made through consensus among maintainers during regular community meetings or via mailing list discussions. Major decisions (e.g., roadmap changes, new maintainers) require a majority vote among maintainers and are documented in GOVERNANCE.md. Community input is encouraged through GitHub issues and public meetings before final decisions are made.

Maintainer Role Division:
Maintainers share responsibilities across all project areas but often focus on specific sub-projects or components based on expertise (e.g., Nydus for image acceleration, console for UI). Specific roles include code review, release management, and community engagement. Detailed responsibilities and current maintainers are listed in MAINTAINERS.md.

  • 2018: Initial governance model established with a small group of core maintainers from Alibaba and Ant Group focusing on basic contribution and review processes.
  • 2020: Post-incubation, governance updated to include more maintainers from diverse organizations (e.g., ByteDance, Intel) and formalized sub-project leadership for Nydus.
  • 2021-2023: Introduced detailed contributor ladders and emeritus status for maintainers, alongside public documentation of decision-making processes to ensure transparency.

Required

  • Clear and discoverable project governance documentation.

The Dragonfly project maintains clear and discoverable project governance documentation, as outlined in its GOVERNANCE.md. This document details the project's governance structure, including roles, responsibilities, and decision-making processes. It provides transparent guidelines for community participation, contributor promotions, and maintainer responsibilities, ensuring an open and inclusive process.

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

All meetings within the Dragonfly community and ecosystem are tracked in the community calendar. This calendar as well as other ways to get involved are highlighted prominently in the project's main README.

The election process is outlined at https://github.com/dragonflyoss/community/blob/master/COMMUNITY_MEMBERSHIP.md#election-process.

Reference link for the community's latest Maintainer voting election: dragonflyoss/community#62

Most of our decisions today are made by maintainers who're actively involved in the project, and we've set out a clear path for people to become maintainers. We have maintainers spread across several companies and we'd gladly accept more.

The "Maximum Representation" section of the governance policy enforces vendor neutrality in project leadership and elections.

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

Project leadership makes decisions is defined in https://github.com/dragonflyoss/community/blob/master/COMMUNITY_MEMBERSHIP.md#how-we-make-decisions.

Contribution acceptance is augmented by the contributing guide with https://github.com/dragonflyoss/community/blob/master/CONTRIBUTING.md#contributing-code-and-docs.

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

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

All maintainers share all domains of responsbility currently, refer to maintainers.

  • A number of active maintainers which is appropriate to the size and scope of the project.

In the past year we had 234 active contributors from 55 different organizations.

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

Repository maintainers are added by: https://github.com/dragonflyoss/community/blob/master/COMMUNITY_MEMBERSHIP.md#adding-new-maintainers

Repository maintainers are removed by: https://github.com/dragonflyoss/community/blob/master/COMMUNITY_MEMBERSHIP.md#removing-inactive-maintainers

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

The OWNERS.md files in the Dragonfly project repository should reflect the maintainer roles defined in the governance document.

Reference link for the community's latest Maintainer voting election: dragonflyoss/community#62

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

There are 12 maintainers from 7 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 Maintainers and Approvers are managed for each repo.

  • 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 CNCF Code of Conduct is linked from the root of the core Dragonfly repository: https://github.com/dragonflyoss/dragonfly/blob/main/CODE_OF_CONDUCT.md

  • All subprojects, if any, are listed.

Dragonfly does not have formally defined "subprojects", but all repositories under the dragonflyoss adhere to the well defined governance.

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

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.

Documented in https://github.com/dragonflyoss/community/blob/master/COMMUNITY_LADDER.md

Required

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

Reporting General Issues: https://github.com/dragonflyoss/community/blob/master/CONTRIBUTING.md#reporting-general-issues

Reporting Security Issues: https://github.com/dragonflyoss/community/blob/master/CONTRIBUTING.md#reporting-security-issues

Contributing Code and Docs: https://github.com/dragonflyoss/community/blob/master/CONTRIBUTING.md#contributing-code-and-docs

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

All communication channels are listed in the community project README: https://github.com/dragonflyoss/community/blob/master/README.md#community.

  • 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 communication channels are listed in the community project README: https://github.com/dragonflyoss/community/blob/master/README.md#community.

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

All meetings within the Dragonfly community and ecosystem are tracked in the community calendar.

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

The Contributing guide describes the process of how to contribute to the project, what the maintainers are expecting, and guidance for how to make a successful contribution.

  • Demonstrate contributor activity and recruitment.

Contributor Data and Growth Trend:

  • As of mid-2025, Dragonfly has over 200 unique contributors on GitHub, with a steady growth of 15-20 new contributors per quarter over the past two years.
  • Contribution stats are publicly tracked via GitHub insights and shared during community meetings.

Incentive Mechanism:

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.

Provider efficient, stable, and secure file distribution and image acceleration using P2P technology, aiming to become the best practice and standard solution for cloud-native architectures.

Landing Page in d7y.io:

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

The documentation lays out a general overview of the purpose and goals of the project, along with details about usage.

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

The public roadmap can be found at https://github.com/dragonflyoss/community/blob/master/ROADMAP.md.

  • Roadmap change process is documented.

The expectations and process for updating the public roadmap over time is outlined in https://github.com/dragonflyoss/community/blob/master/ROADMAP.md.

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

Architecture: https://d7y.io/docs/next/#architecture, https://d7y.io/docs/next/operations/deployment/architecture/

Components introduction: https://d7y.io/docs/next/operations/deployment/applications/manager/, https://d7y.io/docs/next/operations/deployment/applications/scheduler/, https://d7y.io/docs/next/operations/deployment/applications/client/.

Quick Start(Kubernetes): https://d7y.io/docs/next/getting-started/quick-start/kubernetes/

Integrations: https://d7y.io/docs/next/operations/integrations/container-runtime/containerd/, https://d7y.io/docs/next/operations/integrations/container-runtime/cri-o/, https://d7y.io/docs/next/operations/integrations/harbor/ and etc.

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

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 down the road but it's not an immediate priority for us.

Required

  • Clearly defined and discoverable process to report security issues.

The Dragonfly project's security policy is clearly documented at https://github.com/dragonflyoss/community/blob/master/SECURITY.md.

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

The dragonflyoss organization has enabled the GitHub setting for "Require two-factor authentication for everyone in the dragonflyoss organization."

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

The response process for security vulnerability disclosure reports is outlined in detail in https://github.com/dragonflyoss/community/blob/master/SECURITY.md.

  • Document Security Self-Assessment.

Documented in Security Self-Assessment. We intend to merge the PR to TAG Security repository, refer to https://github.com/cncf/tag-security/blob/main/community/assessments/projects/dragonfly/self-assessment.md.

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

A third party security audit was performed by Trail of Bits, you can see the full report here.

Ecosystem

Suggested

N/A

Required

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

This list shows non-exhaustive adopters of dragonfly.

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

Dragonfly integrates with many CNCF projects:

  • Kubernetes as a hosting platform with the Dragonfly.
  • Harbor preheats image and oci artifacts by Dragonfly.
  • containerd distributes image by Dragonfly.
  • cri-o distributes image by Dragonfly.
  • Prometheus to collect metrics.
  • Open Telemetry to generate, collect, and export telemetry data.
  • ArtifactHub indexes all versions of Dragonfly's main Helm chart for installation.
  • gRPC for high-performance remote procedure calls (RPC).
  • Helm used to deploy Dragonfly to Kubernetes.
  • ModelPack distributes model artifacts by Dragonfly.

Adoption

Adopter 1 - DiDi/Service - used from 04/2023

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

Adopter 2 - ByteDance/Internet - used from 09/2022

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

Adopter 3 - Ant Group/Financial - used from 10/2018

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

Adopter 4 - Kuaishou/Internet - used from 06/2019

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

Adopter 5 - Alibaba/Internet - used from 10/2018

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

Metadata

Metadata

Assignees

Labels

gitvotegitvote/closedgitvote/passedkind/ddProject DD or item related to the DD processlevel/graduationItem related to a graduation level project or the graduation criteria/process itself.

Type

No type

Projects

CNCF TOC Board

Status

In Press Coordination

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions