feast-dev
Proposal: Donate Feast to Kubeflow
I am proposing donating Feast to Kubeflow (https://github.com/kubeflow/community/issues/804).
I have copied the benefits I outlined in the Kubeflow issue:
Benefits
Incorporating Feast into Kubeflow (and the manifest) will help formally fill a needed gap for Kubeflow in the AI/ML Lifecycle (image for reference).
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.
The Feast community is healthy and the users will further grow the Kubeflow community.
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.
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.
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: https://github.com/feast-dev/feast/issues/4964 and https://github.com/feast-dev/feast/issues/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.
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?
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 đź‘Ť
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.
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.
I'll update the access to make it public. Each Kubeflow component is meant to be standalone and integrated!
@woop updated to include a "Benefits for Feast section", as follows:
Benefits for Feast
Having Feast as an official part of the Kubeflow community has the following benefits:
- Being integrated into an end-to-end AI/ML ecosystem .
- Increased adoption from the Kubeflow community.
- Aligned product roadmap and vision that best serves the community.
- Coupled with open source products that are maintained by a neutral foundation that allows for great product experiences for end-users.
- Benefit from Kubeflow’s marketing and social media support rather than duplicating effort.
- Brand benefits from Kubeflow and its enterprise appeal.
Generally I'm supportive of closer collaboration with Kubeflow - I just want to make sure we're solving the right problems and choosing the best path forward for Feast and its users.
What problem are we trying to solve?
You mentioned that maintainers are spending too much time on community management rather than technical development.
Can you share more about what specific challenges you're facing day-to-day? Is it about:
- Limited bandwidth for code reviews and feature development?
- Challenges with marketing and community growth?
- Concerns about long term sustainability?
Understanding what's actually painful would help us figure out if donation is the right solution.
Is donation the only option?
Before we go all in on donation, I'm curious if we've thought about:
-
Keeping Feast independent but deeply integrated with Kubeflow - similar to how KServe works. This would give us the integration benefits without completely merging the projects.
-
Sharing specific resources - Maybe we could get help with the parts that are most burdensome (docs, community management) while keeping the core project separate?
What would this mean for current Feast users?
I'm also thinking about our existing users:
- Will they need to change how they install or use Feast?
- How disruptive would API changes be? Are there any guarantees being made in terms of breaking changes?
- What's our plan for a smooth transition of docs and support channels?
- Are there any other downsides to the move (I'm only seeing benefits)?
Next steps
Let's figure out:
- What specific problems we're trying to solve with this move
- Whether donation is the only/best option
- A clear transition plan if we do move forward with donation
Happy to get into the details over a call, but I do want to make sure that this discussion is public for posterity sake.
I'm all for making Feast better and more sustainable - just want to make sure we're taking the right approach.
What do you think?
Can you share more about what specific challenges you're facing day-to-day? Is it about:
Limited bandwidth for code reviews and feature development? Challenges with marketing and community growth? Concerns about long term sustainability?
It is mostly about "Limited bandwidth for code reviews and feature development" and "Concerns about long term sustainability".
My work over the past year and a half has helped continue to grow the community (I don't intend on stopping that) but my bandwidth is limited and I don't want maintainers to have to focus on marketing and events. Kubeflow has a large community with folks explicitly focusing on community and attending events—Feast doesn't (excluding my best attempts).
Before we go all in on donation, I'm curious if we've thought about:
Keeping Feast independent but deeply integrated with Kubeflow - similar to how KServe works. This would give us the integration benefits without completely merging the projects.
Yes, I discussed this extensively with the Kubeflow Steering Committee and their feedback was that they are getting rid of Add-Ons as a concept entirely, so that took this option off the table and is what ultimately led to my proposal. You can see the full discussion openly in this PR: https://github.com/kubeflow/community/pull/741.
I'm also thinking about our existing users:
Will they need to change how they install or use Feast?
Nope, they will not have to. It'll still be the same pip install and we'll even incorporate a proper Feast Client in the Kubeflow SDK to be more deeply integrated with the rest of the Kubeflow components.
How disruptive would API changes be? Are there any guarantees being made in terms of breaking changes?
Absolutely no breaking changes due to Kubeflow.
What's our plan for a smooth transition of docs and support channels?
I intend on keeping the documentation. Our docs are a great example of what docs should look like (though of course we can still make some improvements).
Are there any other downsides to the move (I'm only seeing benefits)?
Candidly, not really. The Feast brand, code, deployment, and structure would still remain, we do forego some control to the Data WG that is being proposed in the sense that they can influence our decisions but I haven't actually seen that exercised. Part of giving influence to the WG is to foster a data community inside Kubeflow that also focuses on GenAI (it would be included with Spark, Model Registry, and others). FWIW, I would be a lead of that WG as well and hope to invest in making the Spark KF experience even better (especially for embedding lots of documents 🤗).
Lastly, I want to be transparent to the community, I proposed this because I think it's what's best for Feast and Kubeflow, as well as each individually. Candidly, Kubeflow has a massive gap in having 0 answer on how to serve data if it drops Feast when dropping Add-Ons. It's a very clear win-win and, I believe, it is part of the reason I was elected to the KSC (all of the feedback on social channels that I have seen about the proposal have been extremely positive).
And to answer these explicitly:
- What specific problems we're trying to solve with this move
I believe my note above addressed this explicit as well as the Google Document
- Whether donation is the only/best option
I believe I also explicitly addressed this above with this comment:
Before we go all in on donation, I'm curious if we've thought about:
Keeping Feast independent but deeply integrated with Kubeflow - similar to how KServe works. This would give us the integration benefits without completely merging the projects.
Yes, I discussed this extensively with the Kubeflow Steering Committee and their feedback was that they are getting rid of Add-Ons as a concept entirely, so that took this option off the table and is what ultimately led to my proposal. You can see the full discussion openly in this PR: https://github.com/kubeflow/community/pull/741.
- A clear transition plan if we do move forward with donation
This is also outlined in the Google Document under the Migration Plan section.
I have discussed this with the Feast maintainers and have gotten approval
Just to clarify, there isn't broad approval that donating Feast to Kubeflow is a good idea. I want to make sure that we articulate all the pros/cons before we make the decision.
Absolutely no breaking changes due to Kubeflow.
This is definitely not true. There are listed breaking changes in your proposal.
I think we need to establish a design principle on how to deal with API changes. What is easiest for the Kubeflow org may not be best for Feast users.
Are there any other downsides to the move (I'm only seeing benefits)? The Feast brand, code, deployment, and structure would still remain
If we deprecate the Feast website as well as the Slack community (as proposed) then there will be a massive loss in terms of Feast's brand and independence as an open source project. I see that as a major risk for the project, and one that could harm further adoption.
I've been reflecting on this proposal quite a bit. This is obviously a very big decision for Feast - probably the biggest since we started the project. Given what's at stake, I think we owe it to our users to take our time and think it through before making a decision.
Before we focus on Kubeflow as the solution, I'd like us to step back and clearly define what problems we're trying to solve. From the discussions, it sounds like there are a few potential issues:
- Maintainer bandwidth is stretched thin
- We want to increase Feast's visibility and adoption
- We're looking for better integration with the broader ML ecosystem
If these are indeed the core challenges, we should consider multiple approaches. For example, if maintainer bandwidth is the main concern, we can reach out to companies actively using Feast to contribute maintainers. I know of many and have started messaging them already. If it's about visibility, we could invest in more community events, blog posts, or conference talks.
I do have some concerns about the current proposal that I think we should discuss:
The Feast identity and brand has taken years to build. Moving everything under Kubeflow (especially deprecating our website and Slack) risks diluting the project's independent identity. Many users choose Feast specifically because they can use it without adopting an entire ML platform.
I'm also concerned about governance and decision making. While I trust the current maintainers completely, what happens long term if Kubeflow's priorities don't align with what's best for Feast users? How do we ensure Feast continues to serve its core purpose? Is this a one-way door, or is there an off-ramp for Feast if it doesn't align with the vision of Kubeflow?
The community we've built is incredibly valuable. I worry about fragmenting it during a transition, especially if we're shutting down established channels where users currently get help.
If we do move forward with Kubeflow, could we consider a more gradual approach? Perhaps we maintain our independent identity while establishing stronger integration and co-marketing with Kubeflow. This would let us test the waters before making irreversible changes.
To be clear - I'm not opposed to the Kubeflow path. I just want to make sure we've thought through all options and have plans to mitigate the risks. Once we donate the project, there's really no going back, so we should be confident it's the right move.
What if we set up a small working group to:
- Clearly define the problems we're trying to solve
- Evaluate 2-3 potential approaches (including Kubeflow)
- Create a more detailed transition plan that addresses the concerns
I'm happy to help with this if it would be useful. What do you all think?
Would it be possible, instead of "donating" Feast to Kubeflow, for us to consider joining the CNCF and collaborating with the Kubeflow community through a shared governance model? I believe we all deeply care about Feast and have invested a lot into it—transferring ownership entirely might feel hurt. But by joining the CNCF, we can continue to grow Feast within a broader cloud-native ecosystem while strengthening our collaboration with Kubeflow through joint maintenance and community efforts.
On Apr 30, 2025, at 9:29 AM, Willem Pienaar @.***> wrote:
woop left a comment (feast-dev/feast#4977) https://github.com/feast-dev/feast/issues/4977#issuecomment-2842575431 I've been reflecting on this proposal quite a bit. This is obviously a very big decision for Feast - probably the biggest since we started the project. Given what's at stake, I think we owe it to our users to take our time and think it through before making a decision.
Before we focus on Kubeflow as the solution, I'd like us to step back and clearly define what problems we're trying to solve. From the discussions, it sounds like there are a few potential issues:
Maintainer bandwidth is stretched thin We want to increase Feast's visibility and adoption We're looking for better integration with the broader ML ecosystem If these are indeed the core challenges, we should consider multiple approaches. For example, if maintainer bandwidth is the main concern, we can reach out to companies actively using Feast to contribute maintainers. I know of many and have started messaging them already. If it's about visibility, we could invest in more community events, blog posts, or conference talks.
I do have some concerns about the current proposal that I think we should discuss:
The Feast identity and brand has taken years to build. Moving everything under Kubeflow (especially deprecating our website and Slack) risks diluting the project's independent identity. Many users choose Feast specifically because they can use it without adopting an entire ML platform.
I'm also concerned about governance and decision making. While I trust the current maintainers completely, what happens long term if Kubeflow's priorities don't align with what's best for Feast users? How do we ensure Feast continues to serve its core purpose? Is this a one-way door, or is there an off-ramp for Feast if it doesn't align with the vision of Kubeflow?
The community we've built is incredibly valuable. I worry about fragmenting it during a transition, especially if we're shutting down established channels where users currently get help.
If we do move forward with Kubeflow, could we consider a more gradual approach? Perhaps we maintain our independent identity while establishing stronger integration and co-marketing with Kubeflow. This would let us test the waters before making irreversible changes.
To be clear - I'm not opposed to the Kubeflow path. I just want to make sure we've thought through all options and have plans to mitigate the risks. Once we donate the project, there's really no going back, so we should be confident it's the right move.
What if we set up a small working group to:
Clearly define the problems we're trying to solve Evaluate 2-3 potential approaches (including Kubeflow) Create a more detailed transition plan that addresses the concerns I'm happy to help with this if it would be useful. What do you all think?
— Reply to this email directly, view it on GitHub https://github.com/feast-dev/feast/issues/4977#issuecomment-2842575431, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3Z4QRZQXRUU6RCFBZWRZD24D27TAVCNFSM6AAAAABWA2IBJGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNBSGU3TKNBTGE. You are receiving this because you are subscribed to this thread.
Would it be possible, instead of "donating" Feast to Kubeflow, for us to consider joining the CNCF and collaborating with the Kubeflow community through a shared governance model? I believe we all deeply care about Feast and have invested a lot into it—transferring ownership entirely might feel hurt. But by joining the CNCF, we can continue to grow Feast within a broader cloud-native ecosystem while strengthening our collaboration with Kubeflow through joint maintenance and community efforts. …
That's an interesting idea. I guess the main question is: What does having a joint governance model allow us to do that we can't do today?
Hey folks, I wanted to provide an update on what's been happening as well as give some historical context.
As discussed in the document linked, Kubeflow and Feast have a rich history together but have largely operated as parallel communities with Kubeflow listing Feast as an External Add-On.
When Tecton stopped supporting Feast, members of the Kubeflow community removed it from Kubeflow's manifest (which was a great way for our target audience (i.e., new potential users) to be introduced to Feast or to deploy it along a comprehensive stack).
I joined Red Hat to work on Feast and Kubeflow as I had worked on both at my previous company (when I originally became a maintainer) and was quite passionate about their domains. My goal for Feast in Kubeflow was to (1) reintroduce Feast back into the Kubeflow manifest to continue to grow adoption and (2) participate in Kubeflow's Data Working Group (which includes the Kubeflow Spark Operator and Model Registry). All of the discussions and proposals have mostly been in service of those goals.
You can see the original proposal for the Data Working Group in this Pull request. In it you'll notice that some of the previous Kubeflow Steering Committee members were not open to including Feast into the manifest if it wasn't under Kubeflow's governance (even though it previously was in the manifests without this requirement). I disagreed with that decision but it was not mine to make.
After several conversations with the Kubeflow community and steering committee, I made the proposal above to donate Feast to Kubeflow (along with @HaoXuAI and @shuchu's support). As you can tell by this thread, there are very reasonable concerns about the donation.
I was eventually elected to the Kubeflow Steering Committee and after several private discussions (including some with @woop), the Steering Committee was willing to drop the donation requirement (they also previously dropped the requirement about deprecating our Slack and moving the github org).
So what is the proposal now? The proposal from the Steering Committee is to list Feast as a Kubeflow Project on their website and include it in the manifests, but it would be outside of its governance and would still operate as an independent community. In that sense, it's much more like a co-marketing strategy than anything else (this is exactly what KServe does and was actually incubated in Kubeflow).
I personally find this valuable as Kubeflow has a rich community and a significant presence at Kubecon all around the world (Kubecon India, North America, Europe, Japan, etc.) and Feast really doesn't have a conference presence (even thought we are quite the successful project).
The Data Working Group held off on moving forward for one year while the Feast discussion was going, as I had wanted to include it so that we could collaborate with the Spark Operator folks (which is ideal for the Feast community as Spark is one of our most popular offline stores). Unfortunately, the Data Working Group has kicked off without Feast and, while we can revisit their charter, currently we're not collaborating with that community where there is natural overlap.
All of this is to say that I think listing Feast as a Kubeflow project and its own project is a great middle ground that can further grow the Feast community without really having to impose changes to the Feast community.
But that is only my opinion and I would love feedback from the community about this as I wouldn't want to do anything that would hurt the community.
Hi all, I read through the discussion this morning again. Personally, I prefer to integrate with Kubeflow, either denote or other proper ways. My opinion is more from my observations on the tech side: 1, The way of Feast preparing features is more for Tree based ML models such as gradient boost tree models. These models are still the state-of-the-art right now. But I can see the trend of adopting LLM both in academic and industry. And I believe the performance of LLM based models will have better performance than the tree based algorithms soon. I guess the Kubeflow community is preparing them for this change at the same time. I wish we can work with them together and make Feast becomes a helpful tool between the data source and the input to any ml models. 2, The Kubeflow community has larger user bases and their software products are more mature. I wish we can attract more users and contributors to our Feast project. I see many feature store projects are using the idea and philosophy of Feast but choose to develop their own version of feature store. We may need to reflect this and thinking about why this happen.
And last but not least, we need to action fast.
