Explore possibility of projects existing as a part of or under two or more foundations

[TheFoxAtWork]

trafficstars

CNCF provides a home for cloud native projects, the nature of "cloud native" applies modern software development methodologies, practices, and processes to gain efficiencies and grow high velocity projects, however cloud native is not the only open source community that benefits from these principles. In particular, the general principles and best practices in supply chain security and application development apply universally, with the notable exception in their implementation and operating environments (depending on the project).

As a result, there may be projects who move in both a cloud native and larger open source arena. We're seeing projects begin to apply in the CNCF that focus on technologies that have their own foundation but implement concepts in a cloud native way, to whom do these belong? to which foundation does the project (and foundation) provide the most value or benefit?

When an umbrella organization is similar (such as Linux Foundation) it can remove a set of questions in how do we manage or support these kinds of projects, but there are still plenty to figure out.

As expressed in OpenSSF TAC public Channel there are quite a few considerations and issues to be worked through. It is my personal preference that we plan for this to occur so we are not surprised and figuring it out when it does.

Some initial thoughts to drive discussion (knowing full well this is a broader Foundation discussion):

• The concept of a Home Foundation could be useful for a project, determining their governance, escalations, etc.
• The concept of "Guest" projects could also be useful, encouraging cross-foundation collaboration by allowing a Hosting Foundation to provide visibility and audience opportunities to a project by its members (this occasionally occurs today although not formally).
  How this could look in practice for an existing foundation's project: A project exists under a Home Foundation, because of the overlapping interests and domain expertise area, the project wishes to be a "guest" of another foundation. This application, and potential status affords them limited visibility at host events, inclusion on project listing page, cross-calendar postings, etc. (any number of things I'm not immediately thinking of).

By establishing some guidance in this area, we can support members of multiple foundations in their contributions so their experience is less fractured with the value of providing adopters (organizations and maintainers) great value in their engagements.

[TheFoxAtWork]

@caniszczyk this sounds like your area.... there was discussion on today's TOC call that this may need to go to the GB but getting your gut check on this would be nice

[JustinCappos]

I'd like to quickly add here a few reasons why projects that are in the CNCF might want to consider this:

• Additional channel to promote the project. A different audience comes to KubeCon vs Open Source Summit vs AGL, etc. and if your work is applicable, it can help to have it seen by more eyes. For example, the OpenSSF project Sigstore just got a lot of visibility to KubeCon which I hope will be a major boost for the already quickly growing project.
• Signaling to adopters that a project is applicable outside of cloud native. One thing that has sometimes surprised us is that some potential adopters viewed TUF as only applicable to cloud native because of the graduated status within the CNCF. Having a project multi-homed helps to address this.
• Facilities that are not provided by the CNCF. We have enjoyed working with the Linux Foundation's Joint Development Foundation (JDF) as a standards body to standardize our secure automotive updater Uptane. (We actually left IEEE/ISTO to move to the JDF and have never regretted it.) As CNCF projects become more widely used outside of the cloud native domain, standards may start to matter for some stakeholders. Letting a project have multiple "homes" would let it avail itself of capabilities like this which can enhance adoption and trust.

As I mentioned in the open meeting, the maintainers on the projects I have in the CNCF are super happy with the support the CNCF has provided us. We wouldn't want a reduction of CNCF support as part of multi homing. We're just looking to expand even further and faster!

[raravena80]

FYI. The KServe presented/discussed the project today in the TAG-Runtime meeting (02/09/2023). They see more alignment with the CNCF because Kubeflow is becoming part of the CNCF and there is a lot of cross collaboration with other CNCF projects like Kubernetes, Argo, etc, etc. If a project cannot be part of the CNCF and the LF AI & Data at the same time, it would be good to have clarity on how they can move from one foundation to another, and how they can keep collaborating with their previous foundation.

At the moment, we are recommending them to check with CNCF staff on what would be the process to move the project from the LF AI to the CNCF.

cc: @yuzisun @nikhita