[Graduation] Buildpacks Graduation Application

[jkutner]

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.

Buildpacks 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/buildpacks, https://github.com/buildpacks-community
Project Site: https://buildpacks.io/
Sub-Projects: N/A
Communication: https://cloud-native.slack.com/ #buildpacks and various channels with #buildpacks- prefix

Project points of contacts: [email protected], Technical Oversight Committee

• (Post Graduation only) Book a meeting with CNCF staff to understand project benefits and event resources.

Graduation Criteria Summary for Buildpacks

Application Level Assertion

• This project is currently Incubating, accepted on 2020-11-18, and applying to Graduate.

Adoption Assertion

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

• See ADOPTERS.md in buildpacks/community for a complete list
• Google
• VMware by Broadcom
• Salesforce
• Bloomberg

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.
  • This was completed and occurred on DD-MMM-YYYY, and can be discovered at $LINK.

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

• All project metadata and resources are vendor-neutral.

  • The Buildpacks project operates according to well defined vendor-neutral governance guided by our Technical Oversight Committee, 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.

  • Met during Project's application on 31-08-2018.
    • The Buildpacks project has demonstrated this understanding through all applications/proposals for each maturity level
      • Sandbox: Add formal proposal for Cloud Native Buildpacks
      • Incubation: Cloud Native Buildpacks Incubation Review
      • Graduation: this document
    • The Buildpacks project has reviewed and understands the expectations as it has continued to move forward through the maturity levels as described in the process README and graduation criteria.

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.

  • Installation Documentation - https://buildpacks.io/docs/app-journey/
  • Contributing/Community Documentation - https://buildpacks.io/community/#contributing
  • Cloud Native Buildpacks Due Diligence

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 Buildpacks project has an established governance process. Formal definition and historical changes are present in our buildpacks/community repository.

Required

• Clear and discoverable project governance documentation.

  • See GOVERNANCE.md in buildpacks/community repository

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

  • Technical Oversight Committee details are present in the buildpacks/community repo
  • Committee activities are tracked as GitHub Issues, Discussions, and project RFCs.
  • TOC meetings are public and notes are taken. See the community calendar for times

• Governance clearly documents vendor-neutrality of project direction.

  • GOVERNANCE.md in buildpacks/community repo

• Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.
  • All changes to the charter, governance model, leadership roles, and membership follow the project RFC process.
  • All voting in the CNB project will adhere to a lazy consensus model
  • Complete documentation of nominatation and election processes for TOC, Maintainers, and Contributors can be found in the buildpacks/community repo.

• Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).
  • The Buildpacks project leadership and membership are divided into sub-teams that are responsible for specific components within the project. These include:
    • Technical Oversight Committee (TOC) - responsible for the direction of the project (roadmap), team leadership, and cross-cutting concerns.
    • Implementation Team - responsible for maintaining the components that constitute the Cloud Native Buildpacks reference implementation of the specification.
    • Platform Team - responsible for maintaining pack and any other platforms or platform components, as well as tools and services that support the distribution, discovery, and integration of buildpacks.
    • Learning Team - responsible for maintaining the project’s documentation, website, and resources.
    • Buildpack Authors' Tooling Team - responsible for helping buildpack authors create buildpacks
  • In addition, the buildpacks-community hosts several sub-projects that have independent governance process.

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

  • Active Technical Oversight Committee Members
  • Active Teams and their leads

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

  • There are four (4) active Technical Oversight Committee Members from three different companies/organizations.
  • There are eight (8) active Team Leads
  • The leadership of the project are part of three (3) different companies/organizations (Salesforce, VMware/Broadcom, and Bloomberg) as well as independent partcipants.

• Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).
  • Maintainers are in charge of the day to day maintenance of a team's projects.
  • New maintainers must already be contributors, must be nominated by an existing maintainer, and must be elected by a supermajority of CNB Team Leads and the TOC. Likewise, maintainers may resign or be removed by a super-majority of Team Leads and the TOC.
  • Complete documentation for the process can be found in the buildpacks/community repo

• Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.
  • Maintainer lifecycle is captured in TEAMS.md in buildpacks/community repo
  • Git history shows advancement of individuals (such as Natalie Arellano) from contributor, to maintainer to TOC member
  • Team structure and ownership of code is managed with CODEOWNERS files.

• Project maintainers from at least 2 organizations that demonstrates survivability.
  • There are three (3) different organizations with members in Buildpacks leadership positions. See above.

• Code and Doc ownership in Github and elsewhere matches documented governance roles.
  • All project components use Github CODEOWNERS file and Github Teams (ex. Pack CLI and Platform Maintainers team)

• Document adoption of the CNCF Code of Conduct
  • https://github.com/buildpacks/.github/blob/main/CODE_OF_CONDUCT.md

• CNCF Code of Conduct is cross-linked from other governance documents.
  • https://github.com/buildpacks/.github/blob/main/CODE_OF_CONDUCT.md

• All subprojects, if any, are listed.
  • Sub-projects and components are owned by Teams. All teams and their list of projects are documented in buildpacks/community.

• If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.
  • Sub-projects and components are owned by Teams. All teams and their list of projects are documented in buildpacks/community.

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 project Governance in buildpacks/community repo.

Required

• Clearly defined and discoverable process to submit issues or changes.
  • Documented in project Governance in buildpacks/community repo.

• Project must have, and document, at least one public communications channel for users and/or contributors.
  • Public CNCF Slack Channels including #buildpacks channel.

• 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.
  • Public CNCF Slack Channels
  • Public Mailing List
  • Private CNCF Slack for leadership, TOC, mentoring, and event coordination
  • Private mailing list for maintainers: [email protected]

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

• Documentation of how to contribute, with increasing detail as the project matures.
  • Detailed contribution guidelines
  • CONTRIBUTING.md template for all sub-projects

• Demonstrate contributor activity and recruitment.
  • Buildpacks within the CNCF in the past year has had 111 authors of commits.
  • Google Summer of Code 2022
  • LFX 2024
  • See CNCF project velocity report

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 DD-MMM-YYYY, and can be discovered at $LINK.

• 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 DD-MMM-YYYY, and can be discovered at $LINK.

• Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.
  • Public Roadmap
  • 2025H1 roadmap proposal

• Roadmap change process is documented.
  • Documented in GOVERNANCE.md in buildpacks/community

• 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 DD-MMM-YYYY, and can be discovered at $LINK.

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

• History of regular, quality releases.
  • Release announcements in #buildpacks-announcements Slack channel
  • History of releases and detailed changelog for each project component can be found in Github Releases (ex. Pack CLI, and Buildpacks Specifications)

Security

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

Suggested

• Achieving OpenSSF Best Practices silver or gold badge.
  • N/A

Required

• Clearly defined and discoverable process to report security issues.
  • Using GitHub SECURITY.md

• Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)
  • Enabled in both our GitHub orgs: buildpacks,buildpacks-community

• Document assignment of security response roles and how reports are handled.
  • The security team, which consists of project maintainers, will be notified of security reports via email. This process is documented in SECURITY.md

• Document Security Self-Assessment.
  • The project conducted both a self-assessment and external audit and publicly posted the results on our blog.

• 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.
    • The Buildpacks project recently completed a security review, working with Quarkslab and the Open Source Technology Improvement Fund (OSTIF).

• Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.
  • https://www.bestpractices.dev/en/projects/4748

Ecosystem

Suggested

N/A

Required

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

  • See ADOPTERS.md in buildpacks/community for a complete list

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

  • See ADOPTERS.md in buildpacks/community for a complete list

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.

  • CNCF Projects

    • Knative - Knative documents buildpacks a way to build functions on the cluster.
    • containerd - Buildpacks are used to build OCI images, which can be run by containerd.
    • kubernetes - Buildpacks can be used to build images that can be run on Kubernetes.
    • kpack is a buildpacks platform that runs as an operator on Kubernetes to produce and maintain application images.
    • Podman - Podman can be used as a docker-compatible target for executing buildpacks via pack CLI.

  • Non-CNCF Projects

    • Open Container Initiative - Buildpacks produce images that maintain compatibility with the OCI image spec.
    • Docker - pack CLI will, by default, target the Docker daemon for building images.
    • Project Piper - Project Piper is a set of tools for continuous integration and continuous delivery that uses buildpacks.
    • Tekton - Tekton integration with buildpacks is documented with the buildpacks tasks.

Adoption

Adopter 1 - Google

• Google Cloud Run - August 2019

Adopter 2 - Salesforce

• Hyperpacks: Using Buildpacks to Build Hyperforce - August 2024

Adopter 3 - VMware by Broadcom

• Overview of Tanzu Buildpacks - October 2024