Proposal: Donate Feast to Kubeflow

[franciscojavierarceo]

I am proposing donating Feast to Kubeflow (kubeflow/community#804).

I have copied the benefits I outlined in the Kubeflow issue:

Benefits

1. Incorporating Feast into Kubeflow (and the manifest) will help formally fill a needed gap for Kubeflow in the AI/ML Lifecycle (image for reference).
   

2. It will also allow the Data WG to have an answer for the online serving of features. Additionally, this will nicely complement the Spark Operator as Feast supports batch and stream processing using Spark as an offline store.

3. The Feast community is healthy and the users will further grow the Kubeflow community.

4. Feast is expanding its scope to support Generative AI and RAG as a first-class citizen (retrieval/vector search in particular), which will help ensure Kubeflow has a solution for RAG.

5. With the inclusion of Feast, we can provide end-to-end demos of development and production AI/ML and we can also provide suggested patterns for stitching the Kubeflow products together so that MLOps engineers, ML Engineers, and AI engineers can be impactful immediately after deploying Kubeflow.

6. I am just as committed to Feast as I have ever been and I believe this will meaningfully enhance Kubeflow and result in Kubeflow getting the benefit of my contributions and the contributions of the Feast community.

Beyond the benefits to Kubeflow, I believe it will provide significant benefits to Feast in growing our community and embedding ourselves in a complete platform. This will also allow both communities (particularly Data Scientists/MLEs) to benefit from the GenAI/LLM/NLP work that I have been doing (see here: #4964 and #4364).

I have discussed this with the Feast maintainers and have gotten approval. We also wanted to have this discussion open in the public to welcome any feedback from users.

--
For reference, the google doc is available here.

[woop]

Thanks @franciscojavierarceo!

Given that this is such a large decision for a project like Feast, it's worth spelling out the case for moving (vs not moving), and the specific implications of the donation. I can see a donation going in many different directions, some of which are very disruptive to existing users, while other approaches are nearly invisible and a net win.

Is there a document that lays out the plan and implications?

[franciscojavierarceo]

Is there a document that lays out the plan and implications?

@woop yes, see this document and this PR with that document added (will update it to reflect latest changes soon).

Given that this is such a large decision for a project like Feast, it's worth spelling out the case for moving (vs not moving), and the specific implications of the donation. I can see a donation going in many different directions, some of which are very disruptive to existing users, while other approaches are nearly invisible and a net win.

I can add a section to the doc on that 👍

[woop]

Thanks @franciscojavierarceo! The document above is mostly focused on the value to Kubeflow, so as long as we can document the value to the Feast side as well, then we're in a good spot to make a decision.

[franciscojavierarceo]

Sounds good, will update to include that as well.

[ngoduykhanh]

Out of curiosity, If Feast joins Kubeflow, will Feast still be available as a standalone open-source product that we can use as of today? I don't have access to the documentation so I can't see the detailed plan.

[franciscojavierarceo]

I'll update the access to make it public. Each Kubeflow component is meant to be standalone and integrated!

[franciscojavierarceo]

@ngoduykhanh updated!