Organizational relationship between Spin and SpinKube

[michelleN]

A question that arose during the CNCF Sandbox submission process sparked a discussion in the last SpinKube community meeting. Should SpinKube be part of the Spin project?

Here are some points made during the discussion:
There were no strong opinions in favor of SpinKube being part of Spin during the discussion. Mostly, folks want a neutral place to put contributions with a sensible governance structure. The group leaned more towards keeping the two separate for the following reasons:

Spin is both a runtime and developer experience and although Spin can be used in Kubernetes environments, it’s not necessarily tied to Kubernetes and part of the Spin user base will not at all be interested in deploying Spin on Kubernetes. The Spin project’s surface area is quite large as is and encompasses several repositories: SDKs, plugins and triggers along with the core Spin codebase. SpinKube is a Kubernetes-based platform for running serverless Wasm. It currently focuses on Spin but is open to supporting runtimes and application models outside of Spin in the future. It also consists of a few different loosely coupled sub projects already and has its own processes (ex. SKIP, bi-weekly community meetings) and governance model.
It is early days for both projects and we want to make sure that each can grow independently. Keeping the two separate and independent may help with velocity of each project for now.

Examples of projects in a similar relationship:

• Envoy and Istio. Envoy being the dependency or a core piece of Istio but Istio being an opinionated tool built around this core dep. Had Istio been a subproject of Envoy, there would be a question around how to think about other envoy based service meshes. Istio ended up having its own entirely independent and very vibrant ecosystem.
• Kubernetes and Helm. Helm was initially part of Kubernetes as a subproject and ended up being its own project in CNCF with its own ecosystem.

We also had a few collective learnings during the discussion. For those interested in more details, please check out the notes and recording here. This issue is my attempt at summarizing. Please feel free to add more color if you were at the call to this issue if inclined and regardless of whether you were at the call or not, we'd love to hear any thoughts from both maintainers and the community.

[Mossaka]

I wanted to add my thoughts since I was out of the office and missed the last SpinKube meeting:

After reviewing the meeting notes, I don't have a strong opinion on either direction, and it seems reasonable to keep these two projects separate. However, I think one of the major hurdel is going to be justifying how SpinKube is not inherently part of Spin, as the project name might suggest. The key point raised was that "SpinKube currently focuses on Spin but is open to supporting runtimes and application models outside of Spin in the future." This seems like a significant directional departure between the two projects.

Just to clarify, when we mention potentially supporting different runtimes, are we talking about entirely different Wasm runtimes or different Spin triggers that would still operate under the Spin runtime? I believe this distinction should be clearly addressed in the project's governance. In addition, we might want to consider a different name, as "SpinKube" seems tightly binded to a specific runtime.