From 6d016624f6a882649df19ce3c9100a8d2c5cca7d Mon Sep 17 00:00:00 2001 From: Enrico Deusebio Date: Wed, 1 Jul 2026 11:05:31 +0200 Subject: [PATCH 1/7] chore: fine-tuning wording on the KDC charter Signed-off-by: Enrico Deusebio --- committee-distribution/charter.md | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/committee-distribution/charter.md b/committee-distribution/charter.md index 5a2888d95..767d4a552 100644 --- a/committee-distribution/charter.md +++ b/committee-distribution/charter.md @@ -1,23 +1,26 @@ # Kubeflow Distribution Committee -The Kubeflow Distribution Committee (KDC) is a vendor-neutral body dedicated to supporting a healthy ecosystem of solutions by prioritizing the development, sustainability, interoperability, and distribution of individual Kubeflow sub-projects. While the primary focus of the KDC is to empower these sub-projects as modular, high-quality components, the Kubeflow Community Distribution serves as a primary example of this effort – providing a validated community supported implementation that demonstrates the collective power of these projects in a unified environment. By maintaining this distribution, the KDC aims to lower the barrier to entry for users and provide a streamlined path to adoption, while ensuring that sub-projects remain robust and valuable. +The Kubeflow Distribution Committee (KDC) is a vendor-neutral body dedicated to supporting a healthy ecosystem of solutions by prioritizing the development, sustainability, interoperability, and distribution of individual Kubeflow sub-projects. While the primary focus of the KDC is to empower these sub-projects as modular, high-quality components, the Kubeflow Community Distribution serves as a primary example of this effort – providing a validated community supported implementation that demonstrates the collective power of these projects in a unified environment. ## Charter -### In Scope (Powers) +### Goals + +The committee will approve policies and decisions to bound the Kubeflow project that will pursue the following goals: 1. Promote the Kubeflow community’s vision, values, and mission in collaboration with the KSC, KOC, and WG Chairs. 2. Validate, report on, and advocate for the consumability of Kubeflow sub-projects by establishing requirements for portability and ease of deployment across heterogeneous environments; this includes identifying integration gaps—such as unexposed configurations or packaging hurdles—and opening issues with sub-project maintainers to help prioritize improvements necessary for the projects to be effectively integrated into the community distribution and the broader vendor ecosystem. 3. Define and maintain the requirements for external projects and distributions of Kubeflow sub-project to be eligible to use the Kubeflow Conformant mark. -4. Validate and impose requirements on the Kubeflow Community Distribution, which provides a reference deployment of all Kubeflow sub-projects that is vendor neutral, multi-tenant, secure, and provide an integrated experience between components. +4. Promote Kubeflow Community Distribution validation to provide reference deployments of Kubeflow sub-projects that is vendor neutral, multi-tenant, secure, and provide an integrated experience between components. + +### Restrictions -### Out of Scope (Limitations) +The committee will not approve decisions or policies on the upstream project that may undermine the longevity of the community or violate vendor-neutral sovereignty. This includes, but is not limited to: -- Anti-Ecosystem-Competitive Actions: Engaging in or permitting actions that undermine the longevity of the community or violate vendor-neutral sovereignty. This includes, but is not limited to: - **Proprietary Lock-in:** Mandating that sub-projects or the distribution depend on proprietary APIs or closed-source components when general, open-source alternatives exist. -- **Core Fragmentation:** Implementing core functionality that is not upstreamed, as the KDC’s goal is to maintain a Kubernetes-native, portable, and extensible foundation. - **Exclusionary Integration:** Forcing dependencies that intentionally disadvantage specific vendors or environments. -- **Note on Compatibility:** This does not exclude the development of community-supported or vendor-contributed adapters (e.g., data exporters, storage drivers, or external dependencies) designed to support specific environments, provided they remain external to the project's core functionality and do not compromise the portability of the base ecosystem. + +Note on Compatibility: Development of community-supported, vendor-contributed adapters (e.g., data exporters, storage drivers, or external dependencies) or proprietary plugins designed to support specific environments shall remain external to the project's core functionality and as to not compromise the portability of the base ecosystem. ## Committee Structure @@ -68,7 +71,7 @@ The decisions is adopted if more then half of the votes (rounded up) support it, ### Limitations on Company Representation -No more than one maintainer or vendor seat may be held by employees of the same organization (or conglomerate, in the case of companies owning each other). +No more than one maintainer or vendor seat may be held by employees of the same organization (or conglomerate, in the case of companies owning each other). Seat may be transferred within people of the same organization during the 1 year term. If employers change because of job changes, acquisitions, or other events, in a way that would be in violation of the proceeding limits, sufficient members of the committee must resign their positions until the requirements are satisfied. If it is impossible to find sufficient members to resign, all employees of that organization will be removed and the vacancies will be filled using the normal process. @@ -85,7 +88,7 @@ In the event of a question of company membership (for example evaluating indepen - Maintain the evolving and not exhaustive list of included dependencies for a proper multi-tenant platform installation: Istio, KNative, Dex, Oauth2-proxy, Cert-Manager, ... as well as Kubeflow sub-projects, Kubeflow Ecosystem projects and disabled by default experimental integrations. - Release tested releases of the Kubeflow Community Distribution for downstream consumption. - Provide guidance and examples how the consumer could integrate non-default external authentication (e.g., companies' Identity Provider) and popular non-default services on his own. -- Make Kubeflow Community Distribution compatible with the popular Kubernetes clusters (Kind, Rancher, AKS, GKE, EKS, OpenShift) +- Make Kubeflow Community Distribution compatible with the popular Kubernetes clusters (Kind, Rancher, AKS, GKE, EKS, OpenShift, MicroK8s/Canonical K8s) - Aid the Kubeflow subproject maintainers in creating manifests (Helm, Kustomize), security best practices, maintain releases and versioning for their application. ### Kubeflow Community Distribution maintainer requirements From f05b9bbd27c71227c079656b82ff23d917cab578 Mon Sep 17 00:00:00 2001 From: Enrico Deusebio Date: Wed, 1 Jul 2026 11:26:00 +0200 Subject: [PATCH 2/7] small update Signed-off-by: Enrico Deusebio --- committee-distribution/charter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/committee-distribution/charter.md b/committee-distribution/charter.md index 767d4a552..5d3e45bb5 100644 --- a/committee-distribution/charter.md +++ b/committee-distribution/charter.md @@ -20,7 +20,7 @@ The committee will not approve decisions or policies on the upstream project tha - **Proprietary Lock-in:** Mandating that sub-projects or the distribution depend on proprietary APIs or closed-source components when general, open-source alternatives exist. - **Exclusionary Integration:** Forcing dependencies that intentionally disadvantage specific vendors or environments. -Note on Compatibility: Development of community-supported, vendor-contributed adapters (e.g., data exporters, storage drivers, or external dependencies) or proprietary plugins designed to support specific environments shall remain external to the project's core functionality and as to not compromise the portability of the base ecosystem. +Note on Compatibility: Development of community-supported, vendor-contributed adapters (e.g., data exporters, storage drivers, or external dependencies) or proprietary plugins designed to support specific environments shall remain external to the project's core functionality and as to not compromise the portability of the base ecosystem, unless it is decided that such components would pursue the goals above and not conflict with the restrictions. ## Committee Structure From b723e3a2c4765e329797d294a85edcc79d5fe80b Mon Sep 17 00:00:00 2001 From: deusebio Date: Mon, 6 Jul 2026 11:18:58 +0200 Subject: [PATCH 3/7] Apply suggestions from code review Co-authored-by: Andrey Velichkevich Signed-off-by: deusebio --- committee-distribution/charter.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/committee-distribution/charter.md b/committee-distribution/charter.md index 5d3e45bb5..6683981be 100644 --- a/committee-distribution/charter.md +++ b/committee-distribution/charter.md @@ -6,12 +6,12 @@ The Kubeflow Distribution Committee (KDC) is a vendor-neutral body dedicated to ### Goals -The committee will approve policies and decisions to bound the Kubeflow project that will pursue the following goals: +The committee will approve policies and decisions to bound the Kubeflow subprojects that will pursue the following goals: 1. Promote the Kubeflow community’s vision, values, and mission in collaboration with the KSC, KOC, and WG Chairs. 2. Validate, report on, and advocate for the consumability of Kubeflow sub-projects by establishing requirements for portability and ease of deployment across heterogeneous environments; this includes identifying integration gaps—such as unexposed configurations or packaging hurdles—and opening issues with sub-project maintainers to help prioritize improvements necessary for the projects to be effectively integrated into the community distribution and the broader vendor ecosystem. 3. Define and maintain the requirements for external projects and distributions of Kubeflow sub-project to be eligible to use the Kubeflow Conformant mark. -4. Promote Kubeflow Community Distribution validation to provide reference deployments of Kubeflow sub-projects that is vendor neutral, multi-tenant, secure, and provide an integrated experience between components. +Collaborate with Kubeflow Community Distribution maintainers ### Restrictions @@ -71,14 +71,14 @@ The decisions is adopted if more then half of the votes (rounded up) support it, ### Limitations on Company Representation -No more than one maintainer or vendor seat may be held by employees of the same organization (or conglomerate, in the case of companies owning each other). Seat may be transferred within people of the same organization during the 1 year term. +No more than one maintainer or vendor seat may be held by employees of the same organization (or conglomerate, in the case of companies owning each other). Seat may be transferred within people of the same organization during the 1 year term if KSC approve it. If employers change because of job changes, acquisitions, or other events, in a way that would be in violation of the proceeding limits, sufficient members of the committee must resign their positions until the requirements are satisfied. If it is impossible to find sufficient members to resign, all employees of that organization will be removed and the vacancies will be filled using the normal process. In the event of a question of company membership (for example evaluating independence of corporate subsidiaries) a majority of all non-involved KSC members will decide. ## Kubeflow Community Distribution maintainers - +Kubeflow Community Distribution (KCD) is community-maintained reference for deploying Kubeflow subprojects and ecosystem integrations in a vendor neutral package. ### In Scope (minimal expectations) - The Kubeflow Community Distribution must be Kubeflow Conformant. From bc5fd4bd057cf3b4dee81dd8311586673c4e6c12 Mon Sep 17 00:00:00 2001 From: Julius von Kohout <45896133+juliusvonkohout@users.noreply.github.com> Date: Mon, 6 Jul 2026 15:58:50 +0200 Subject: [PATCH 4/7] Apply suggestions from code review Co-authored-by: Andrey Velichkevich Co-authored-by: Julius von Kohout <45896133+juliusvonkohout@users.noreply.github.com> Signed-off-by: Julius von Kohout <45896133+juliusvonkohout@users.noreply.github.com> --- committee-distribution/charter.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/committee-distribution/charter.md b/committee-distribution/charter.md index 6683981be..c36b77105 100644 --- a/committee-distribution/charter.md +++ b/committee-distribution/charter.md @@ -1,6 +1,6 @@ # Kubeflow Distribution Committee -The Kubeflow Distribution Committee (KDC) is a vendor-neutral body dedicated to supporting a healthy ecosystem of solutions by prioritizing the development, sustainability, interoperability, and distribution of individual Kubeflow sub-projects. While the primary focus of the KDC is to empower these sub-projects as modular, high-quality components, the Kubeflow Community Distribution serves as a primary example of this effort – providing a validated community supported implementation that demonstrates the collective power of these projects in a unified environment. +The Kubeflow Distribution Committee (KDC) is a vendor-neutral body dedicated to supporting a healthy ecosystem of solutions by prioritizing the development, sustainability, interoperability, and distribution of individual Kubeflow sub-projects. While the primary focus of the KDC is to empower these sub-projects as modular, high-quality components, the Kubeflow Community Distribution serves as a primary example of this effort – providing a validated community supported implementation that demonstrates the collective power of these projects in a unified platform. ## Charter @@ -11,7 +11,7 @@ The committee will approve policies and decisions to bound the Kubeflow subproje 1. Promote the Kubeflow community’s vision, values, and mission in collaboration with the KSC, KOC, and WG Chairs. 2. Validate, report on, and advocate for the consumability of Kubeflow sub-projects by establishing requirements for portability and ease of deployment across heterogeneous environments; this includes identifying integration gaps—such as unexposed configurations or packaging hurdles—and opening issues with sub-project maintainers to help prioritize improvements necessary for the projects to be effectively integrated into the community distribution and the broader vendor ecosystem. 3. Define and maintain the requirements for external projects and distributions of Kubeflow sub-project to be eligible to use the Kubeflow Conformant mark. -Collaborate with Kubeflow Community Distribution maintainers +4. Collaborate with Kubeflow Community Distribution maintainers ### Restrictions @@ -71,14 +71,14 @@ The decisions is adopted if more then half of the votes (rounded up) support it, ### Limitations on Company Representation -No more than one maintainer or vendor seat may be held by employees of the same organization (or conglomerate, in the case of companies owning each other). Seat may be transferred within people of the same organization during the 1 year term if KSC approve it. +No more than one maintainer or vendor seat may be held by employees of the same organization (or conglomerate, in the case of companies owning each other). The organization seat may be transferred within members of the same organization during the 1 year term, if KSC approves it. If employers change because of job changes, acquisitions, or other events, in a way that would be in violation of the proceeding limits, sufficient members of the committee must resign their positions until the requirements are satisfied. If it is impossible to find sufficient members to resign, all employees of that organization will be removed and the vacancies will be filled using the normal process. In the event of a question of company membership (for example evaluating independence of corporate subsidiaries) a majority of all non-involved KSC members will decide. ## Kubeflow Community Distribution maintainers -Kubeflow Community Distribution (KCD) is community-maintained reference for deploying Kubeflow subprojects and ecosystem integrations in a vendor neutral package. +Kubeflow Community Distribution (KCD) is community-maintained reference deployment of all Kubeflow sub-projects that is vendor neutral, multi-tenant, secure, and provides an integrated experience between components. ### In Scope (minimal expectations) - The Kubeflow Community Distribution must be Kubeflow Conformant. @@ -88,7 +88,7 @@ Kubeflow Community Distribution (KCD) is community-maintained reference for depl - Maintain the evolving and not exhaustive list of included dependencies for a proper multi-tenant platform installation: Istio, KNative, Dex, Oauth2-proxy, Cert-Manager, ... as well as Kubeflow sub-projects, Kubeflow Ecosystem projects and disabled by default experimental integrations. - Release tested releases of the Kubeflow Community Distribution for downstream consumption. - Provide guidance and examples how the consumer could integrate non-default external authentication (e.g., companies' Identity Provider) and popular non-default services on his own. -- Make Kubeflow Community Distribution compatible with the popular Kubernetes clusters (Kind, Rancher, AKS, GKE, EKS, OpenShift, MicroK8s/Canonical K8s) +- Make Kubeflow Community Distribution compatible with the popular Kubernetes clusters (Kind, Rancher, AKS, GKE, EKS, OpenShift, MicroK8s) - Aid the Kubeflow subproject maintainers in creating manifests (Helm, Kustomize), security best practices, maintain releases and versioning for their application. ### Kubeflow Community Distribution maintainer requirements From c1afa78a5fe3770c4fac3399b77bf51a2f569506 Mon Sep 17 00:00:00 2001 From: Julius von Kohout <45896133+juliusvonkohout@users.noreply.github.com> Date: Mon, 6 Jul 2026 16:06:19 +0200 Subject: [PATCH 5/7] Revise committee restrictions for vendor neutrality Signed-off-by: Julius von Kohout <45896133+juliusvonkohout@users.noreply.github.com> --- committee-distribution/charter.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/committee-distribution/charter.md b/committee-distribution/charter.md index c36b77105..009ddce85 100644 --- a/committee-distribution/charter.md +++ b/committee-distribution/charter.md @@ -15,12 +15,11 @@ The committee will approve policies and decisions to bound the Kubeflow subproje ### Restrictions -The committee will not approve decisions or policies on the upstream project that may undermine the longevity of the community or violate vendor-neutral sovereignty. This includes, but is not limited to: - +- Anti-Ecosystem-Competitive Actions: Engaging in or permitting actions that undermine the longevity of the community or violate vendor-neutral sovereignty. This includes, but is not limited to: - **Proprietary Lock-in:** Mandating that sub-projects or the distribution depend on proprietary APIs or closed-source components when general, open-source alternatives exist. +- **Core Fragmentation:** Implementing core functionality that is not upstreamed, as the KDC’s goal is to maintain a Kubernetes-native, portable, and extensible foundation. - **Exclusionary Integration:** Forcing dependencies that intentionally disadvantage specific vendors or environments. - -Note on Compatibility: Development of community-supported, vendor-contributed adapters (e.g., data exporters, storage drivers, or external dependencies) or proprietary plugins designed to support specific environments shall remain external to the project's core functionality and as to not compromise the portability of the base ecosystem, unless it is decided that such components would pursue the goals above and not conflict with the restrictions. +- **Note on Compatibility:** This does not exclude the development of community-supported or vendor-contributed adapters (e.g., data exporters, storage drivers, or external dependencies) designed to support specific environments, provided they remain external to the project's core functionality and do not compromise the portability of the base ecosystem. ## Committee Structure From 7ba81f0c1ff1c9bc54d1b39978ff6e70f92f799d Mon Sep 17 00:00:00 2001 From: Julius von Kohout <45896133+juliusvonkohout@users.noreply.github.com> Date: Mon, 6 Jul 2026 16:08:20 +0200 Subject: [PATCH 6/7] Apply suggestion from @juliusvonkohout Signed-off-by: Julius von Kohout <45896133+juliusvonkohout@users.noreply.github.com> --- committee-distribution/charter.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/committee-distribution/charter.md b/committee-distribution/charter.md index 009ddce85..f0696ac5c 100644 --- a/committee-distribution/charter.md +++ b/committee-distribution/charter.md @@ -77,7 +77,7 @@ If employers change because of job changes, acquisitions, or other events, in a In the event of a question of company membership (for example evaluating independence of corporate subsidiaries) a majority of all non-involved KSC members will decide. ## Kubeflow Community Distribution maintainers -Kubeflow Community Distribution (KCD) is community-maintained reference deployment of all Kubeflow sub-projects that is vendor neutral, multi-tenant, secure, and provides an integrated experience between components. +The Kubeflow Community Distribution (KCD) is the community-maintained reference deployment of all Kubeflow sub-projects and is vendor neutral, multi-tenant, secure, and provides an integrated experience between components. ### In Scope (minimal expectations) - The Kubeflow Community Distribution must be Kubeflow Conformant. From 9298c1fbeab2be558f788cc33e29bf7099aa4dae Mon Sep 17 00:00:00 2001 From: Julius von Kohout <45896133+juliusvonkohout@users.noreply.github.com> Date: Mon, 6 Jul 2026 18:18:22 +0200 Subject: [PATCH 7/7] Update charter.md to remove core fragmentation restriction Removed mention of 'Core Fragmentation' from restrictions. Signed-off-by: Julius von Kohout <45896133+juliusvonkohout@users.noreply.github.com> --- committee-distribution/charter.md | 1 - 1 file changed, 1 deletion(-) diff --git a/committee-distribution/charter.md b/committee-distribution/charter.md index f0696ac5c..876b70d40 100644 --- a/committee-distribution/charter.md +++ b/committee-distribution/charter.md @@ -17,7 +17,6 @@ The committee will approve policies and decisions to bound the Kubeflow subproje - Anti-Ecosystem-Competitive Actions: Engaging in or permitting actions that undermine the longevity of the community or violate vendor-neutral sovereignty. This includes, but is not limited to: - **Proprietary Lock-in:** Mandating that sub-projects or the distribution depend on proprietary APIs or closed-source components when general, open-source alternatives exist. -- **Core Fragmentation:** Implementing core functionality that is not upstreamed, as the KDC’s goal is to maintain a Kubernetes-native, portable, and extensible foundation. - **Exclusionary Integration:** Forcing dependencies that intentionally disadvantage specific vendors or environments. - **Note on Compatibility:** This does not exclude the development of community-supported or vendor-contributed adapters (e.g., data exporters, storage drivers, or external dependencies) designed to support specific environments, provided they remain external to the project's core functionality and do not compromise the portability of the base ecosystem.