[CNCF Graduation] Governance and Vendor Neutrality clarifications

[kfaseela]

Buildpacks already demonstrates vendor-neutrality as Governance and team responsibilities are documented (GOVERNANCE.md#vendor-neutrality, TEAMS.md)

For CNCF Graduation(cncf/toc#1538), the top-level governance body (TOC) is expected to have explicit, auditable governance mechanisms. Specifically, the following are considered mandatory:

1. Number of seats - clearly define how many members serve on the TOC.
2. Seat appointment process – describe how members are selected or elected and term limits, if applicable. (This has been partially documented; term limits and eligibility criteria and election process may be better documented).
3. Ensure consistency between GOVERNANCE.md and TEAMS.md by linking to specific teams from the respective sections of GOVERNANCE.md
4. Member affiliations and representation – each TOC member’s organizational affiliation should be publicly documented.; Count related companies together (https://github.com/cncf/foundation/blob/main/charter.md#14-related-companies). With Heroku and Salesforce considered related companies, it would be helpful to clarify how the current 3-member TOC aligns with the project’s vendor-neutrality policy (GOVERNANCE.md#vendor-neutrality). As the project prepares for graduation, this could be an opportunity to further strengthen neutrality by either adjusting TOC representation or expanding the TOC to 5+ seats with participation from additional organizations. Doing so would reinforce vendor-neutral decision-making, transparency, and long-term resilience.

References:

1. Falco governance is commonly cited for CNCF Graduation reviews: [Falco Governance] (https://github.com/falcosecurity/evolution/blob/main/GOVERNANCE.md).
2. Cross plane has a very neat table describing [company affiliation] (https://github.com/crossplane/crossplane/blob/main/GOVERNANCE.md#steering-committee-1) of top-level bodies.

[kfaseela]

@jkutner @hone : I don't seem to have permission to add this to the milestone we created, could you please link?

[kfaseela]

The contributor guide includes a vendor‑specific example (“A v2 Heroku buildpack…”): https://github.com/buildpacks/community/blob/main/contributors/guide.md#contributions

It would be nicer to replace such references with neutral wording (e.g., “platform‑agnostic…”) and applying this principle consistently across all Buildpacks documentation.

[hone]

The contributor guide includes a vendor‑specific example (“A v2 Heroku buildpack…”): https://github.com/buildpacks/community/blob/main/contributors/guide.md#contributions

It would be nicer to replace such references with neutral wording (e.g., “platform‑agnostic…”) and applying this principle consistently across all Buildpacks documentation.

We can change the wording, but that particular example is b/c "v2 Heroku Buildpacks" are a type of buildpack using the "v2 Heroku Buildpack API". Other platforms like Dokku support running those buildpacks using that API. If you feel strongly, we can remove that example.

[kfaseela]

The contributor guide includes a vendor‑specific example (“A v2 Heroku buildpack…”): https://github.com/buildpacks/community/blob/main/contributors/guide.md#contributions
It would be nicer to replace such references with neutral wording (e.g., “platform‑agnostic…”) and applying this principle consistently across all Buildpacks documentation.

We can change the wording, but that particular example is b/c "v2 Heroku Buildpacks" are a type of buildpack using the "v2 Heroku Buildpack API". Other platforms like Dokku support running those buildpacks using that API. If you feel strongly, we can remove that example.

Thanks for the explanation, the reasoning makes sense. From a Graduation and vendor-neutrality perspective, the goal is mainly to avoid downstream-specific references in contributor-facing examples where possible. If feasible, using API- or version-based terminology (rather than a vendor name) would help keep the docs fully neutral. Did not mean to completely remove the example, rather retain the example with a neutral wording.

[hone]

@kfaseela it sounds like for this example you're 👍 keeping it. Totally agree on the vendor-neutrality, so if you find other examples happy to change those.

[kfaseela]

@kfaseela it sounds like for this example you're 👍 keeping it. Totally agree on the vendor-neutrality, so if you find other examples happy to change those.

@hone : From the CNCF Graduation vendor-neutrality perspective, the goal is just to avoid downstream/vendor-specific names in examples where possible, so that documentation reads as broadly applicable. If you think the example helps readers and should be retained, it could be replaced with wording that preserves the same API context but without naming a specific vendor, eg:
A v2 buildpack using the legacy V2 buildpack API that runs Cloud Native Buildpack (v3) builds on platforms that only support older V2 buildpacks.

If there’s value in keeping vendor-specific examples, one other option could be to move them to a separate page explicitly scoped for downstream/platform examples, if there is scope for showcasing multiple vendors (e.g., at least three) rather than a single one.