Google Summer of Code 2025 - Please Submit Your Project Ideas

[rareddy]

Hello Kubeflow Community,

Kubeflow has officially submitted to be part of Goole Summer Code 2025. We do hope to get selected as one of the participating organizations this year. We had a very successful GSOC 2024. I thank all the Mentors and Students for making it successful.

I am looking for

• Signing up Mentors. If you would like to be a mentor this season, please reach out to me on CNCF Slack or leave your Name and git ID here. I will invite all the 2024 mentors by default, so please use this form only if you are a new mentor.

• Project Ideas for Kubeflow components. If you submit an idea, you must be a mentor (Kubeflow member and/or committer) or if you are a student submitting a proposal it must be approved by one of the component leads or a committer on that component.

Make sure your Project Ideas include ALL of the required information below:

1. Project title/description
2. Detailed description of the project. Provide as many details as possible for students to read and understand without asking too many questions about the project.
3. Expected outcomes
4. Skills required/preferred
5. Possible mentors
6. Component
7. Difficulty (Low, Medium, Expert)
8. If you already have Git issue for it, please include that here.
9. Expected size of the project (90, 175 or 350 hours. Please do NOT use any arbitrary number, choose one close to list given)

Leave a single comment here for each proposal. As we approve them, we will collate all the projects at https://www.kubeflow.org/events/gsoc-2025/. If you have questions, please come and ask in CNCF Slack #kubeflow-gsoc-participants.

All mentors MUST be assigned to one or more projects.

The deadline to submit all the ideas is Feb 15th, 2025. So, please take some time and submit them. Thank you all for your support.

[varodrig]

@rareddy are you thinking on having this content on the website? otherwise I'd recommend to create the issue on the community repository.

cc @franciscojavierarceo

[thesuperzapper]

/transfer community

[Shekharrajak]

@rareddy , I would like to be a mentor and interested on spark-operator project. I will be sharing my ideas/project proposals soon.

[Electronic-Waste]

@rareddy Hi, I was a GSoC student last year, and also a new maintainer in Kubeflow. Benefit from the GSoC project a lot, I would like to apply for the mentor of training-operator and katib this year. I'm sure it will help more new contributors like me to get engaged in Kubeflow and the world of open source.

As for the project ideas, not yet. But I'll put them here once they are ready.

cc @kubeflow/wg-automl-leads @kubeflow/wg-training-leads

[juliusvonkohout]

@rareddy here are my rough ideas

Project Idea 1

Project Title: multi-tenancy/security, Kubeflow repository Migration, and CI/CD Enhancement

Detailed Description:

• Productionize the seaweedfs PoC as secure minio replacement https://github.com/kubeflow/manifests/tree/master/contrib/seaweedfs, since we are stuck with a 5 year old minio due to AGPL
• add multi tenancy to seweadfs similar to the approach in feat(backend): isolate artifacts per namespace/profile/user using only one bucket pipelines#7725
  -Help to migrate Kubeflow/kubeflow components to kubeflow/dashboard and kubeflow/notebooks. This might even start before Gsoc
• Renovate kubeflow/dashboard dependencies, addressing CVEs.
• Implement architectural changes as needed.
• Adapt and improve scripts and CI/CD in kubeflow/manifests, including matrix calls to test multiple Kubernetes versions simultaneously.

Expected Outcomes:

• Successful migration of Kubeflow components.
• Hard multi-tenancy for the object storage
• Updated dependencies with resolved CVEs.
• Enhanced CI/CD pipeline supporting multiple Kubernetes versions.

Skills Required/Preferred:

• GitHub and GitHub Actions
• Containerfile and Kubernetes knowledge
• Experience with Python, Go and JavaScript frameworks

Possible Mentors:

• @juliusvonkohout
• @thesuperzapper are you interested?

Component: Kubeflow

Difficulty: Medium

Expected Size of the Project: 175/350 hours

Project Idea 2

Project Title: Maintain Kserve Models Web Application such that we have a proper UI for model serving.

Detailed Description:

• Clean up and merge 20 issues and 5 PRs.
• Implement a better CI/CD pipeline.
• Potentially migrate the application to /kubeflow/kserve-model-ui.
• Add features for editing, regression testing, and monitoring/metrics support.
• Synchronize with kserve 0.14+ changes.

Expected Outcomes:

• Resolved issues and merged PRs.
• less CVEs
• Improved CI/CD pipeline.
• New editing and regression testing features.
• Enhanced monitoring and metrics support.
• Application synchronized with kserve 0.14+ changes.

Skills Required/Preferred:

• GitHub Actions
• Containerfiles
• JavaScript frameworks

Possible Mentors:

• Julius von Kohout
• @varodrig do you want to help here?

Component: Kserve UI

Difficulty: Medium

Expected Size of the Project: 175+ hours

[juliusvonkohout]

@Ramesh I updated project idea one above for multi-tenancy, and seaweedfs

• Productionize the seaweedfs PoC as minio replacement https://github.com/kubeflow/manifests/tree/master/contrib/seaweedfs
• add multi tenancy to seweadfs similar to the approach in feat(backend): isolate artifacts per namespace/profile/user using only one bucket pipelines#7725

[mahdikhashan]

@rareddy Hi, I was a GSoC student last year, and also a new maintainer in Kubeflow. Benefit from the GSoC project a lot, I would like to apply for the mentor of training-operator and katib this year. I'm sure it will help more new contributors like me to get engaged in Kubeflow and the world of open source.

As for the project ideas, not yet. But I'll put them here once they are ready.

cc @kubeflow/wg-automl-leads @kubeflow/wg-training-leads

I'm new contributor to the project, trying to join the meetings and contribute to components. I'd like also to apply as a mentee. over the past few weeks @Electronic-Waste has been very helpful, and I would appreciate the opportunity to have them as my mentor, as I believe I can learn a lot from their experience.

[juliusvonkohout]

@kimwnasptd what do you think about

kubeflow/manifests#2676 (comment)

Project Idea 3

Project Title: Make our service mesh rootless by default and provide secure model inference by default.

Detailed Description:
Secure our service mesh with istio-cni by default kubeflow/manifests#2907 and an option for istio-ambient mesh kubeflow/manifests#2676 with zero overhead namespaces (single waypoint proxy deployment). Furthermore we need to enable a secure Kserve by default kubeflow/manifests#2811. A general plan is also available at
kubeflow/manifests#2528

Expected Outcomes:

• A secure cni/ambient mesh with waypoint proxies only in the istio-sytem namespace for zero overhead namespaces. Just the same as the detailed description.

Skills Required/Preferred:

• GitHub and GitHub Actions
• Kubernetes and networking
• Istio, Kustomize

Possible Mentors:

• @juliusvonkohout
• @kimwnasptd are you interested?

Component: Kubeflow

Difficulty: small
Expected Size of the Project: 175 hours

[kimwnasptd]

@juliusvonkohout I'm super interested in this! Although I'd suggest us to be a bit careful when defining the scope, to not end up shooting ourselves in the foot by committing to something that in the end might not be fully in our hand to implement.

Some gray areas I have in mind and worry me a bit:

1. If we need to update the AuthorizationPolicies of workloads
   • Since it looks like it requires targetRefs, for targeting the waypoint proxy
   • If this is the case, there are components in Kubeflow that need to be changed that are not within our control (i.e. Knative)
2. If we need to have HTTPRoute objects instead of VirtualService ones
   • For the same reason as above, regarding "third-party" components

In any case though, happy to be a mentor for that one and we can figure out a scope that could fit this effort. I'll also be looking at it with the Canonical team, so I'll have cycles to help on this as well.

[juliusvonkohout]

@juliusvonkohout I'm super interested in this! Although I'd suggest us to be a bit careful when defining the scope, to not end up shooting ourselves in the foot by committing to something that in the end might not be fully in our hand to implement.

Some gray areas I have in mind and worry me a bit:

1. If we need to update the AuthorizationPolicies of workloads
   • Since it looks like it requires targetRefs, for targeting the waypoint proxy
   • If this is the case, there are components in Kubeflow that need to be changed that are not within our control (i.e. Knative)
2. If we need to have HTTPRoute objects instead of VirtualService ones
   • For the same reason as above, regarding "third-party" components

In any case though, happy to be a mentor for that one and we can figure out a scope that could fit this effort. I'll also be looking at it with the Canonical team, so I'll have cycles to help on this as well.

I changed it to
"secure istio-cni by default and an option for istio-ambient mesh with zero overhead namespace (single waypoint proxy deployment)" maybe you have a better formulation for the targets.

[RameshOswal]

Interested in mentoring

Ramesh Oswal git-Id: rameshoswal

[rareddy]

@RameshOswal one of the requirements I am placing on mentors is, you either work with an existing lead on a component to come up with a project that you can be a mentor on. so please propose a project idea.

[Girma35]

Anyone who is looking for a junior developer and has enough time to mentor, please reach out. I am eager to develop my skills and gain experience. Feel free to connect with me on linkdin Thank you!
LinkedIn: https://www.linkedin.com/in/girma-w-a16429263
email : [email protected]

[juliusvonkohout]

Anyone who is looking for a junior developer and has enough time to mentor, please reach out. I am eager to develop my skills and gain experience. Feel free to connect with me on linkdin Thank you! LinkedIn: https://www.linkedin.com/in/girma-w-a16429263 email : [email protected]

@Girma35 you will probably reach us better via the Kubeflow Slack channels https://www.kubeflow.org/docs/about/community/. There are also enough "good first issues" marked here https://github.com/kubeflow/manifests/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22 and you might want to dive into some of the project ideas listed in this thread here.

[StefanoFioravanzo]

@rareddy here's our proposal

Title: Enhancing Kubeflow Data Science Experience with Jupyter-Centric Tools

Description & Outcomes

This project is dedicated to elevating the data science workflow within Kubeflow by creating a suite of tools and extensions that deliver a seamless, Jupyter-native user experience. The work begins with reviving and modernizing the existing Kale tool – ensuring compatibility with the latest Jupyter and Kubeflow Pipelines (KFP v2) standards – and then, optionally and depending on candidate progress, extends those capabilities by introducing new functionality. These enhancements include interactive pipeline visualizations and additional integrations, all designed to simplify and streamline the development user experience within Kubeflow.

Phase 1: Reviving and Modernizing Kale

• Audit & Dependency Update:
  • Create a detailed map of the current Kale features and capabilities.
  • Update dependencies to resolve known CVEs and deprecated modules.
  • Ensure full compatibility with the latest versions of Jupyter (e.g., JupyterLab 4.x) and Kubeflow Pipelines (KFP v2).
• API Refactoring & Integration:
  • Refactor internal APIs to align with KFP v2 and modern Jupyter environments.
  • Develop integration tests and demo workflows that validate the end-to-end execution of pipelines from within a Jupyter notebook.
• Migration
  • Migrate the updated Kale codebase into a new Jupyter-centric tools repository under the Kubeflow GitHub organization repository.

Phase 2: (optional) Extending Capabilities with Jupyter-Centric Enhancements

• Interactive Pipeline Visualization Editor:
  • Develop an interactive pipeline visualization editor that mirrors the Kubeflow Pipelines dashboard.
  • Integrate the visualization tool into the Jupyter environment, enabling users to monitor, modify, and interact with their pipelines in real time.
• Enhanced User Experience:
  • Revamp the user interface to follow Jupyter’s native design, improving usability for data scientists.
• Unified Access via a Python SDK:
  • Build a lightweight Python SDK that simplifies the configuration and access to multiple Kubeflow components (e.g., Pipelines, Training Operator & Katib, Model Registry, Model Serving, Feast).
  • Ensure that the SDK offers a “one-stop-shop” experience, reducing dependency and configuration overhead for data scientists.

Phase 3: Consolidation and Final Documentation

• Comprehensive Documentation & Tutorials:
  • Prepare detailed user guides, developer documentation, and tutorials covering the entire enhanced workflow.
  • Prepare and deliver a live demo to the Kubeflow community that illustrates the new data science experience within Kubeflow.
• Community Engagement & Feedback:
  • Engage with the Kubeflow community for feedback during the development process
  • Iterate on features based on user input and testing to ensure a smooth, production-ready experience.

Additional Notes:

• The project has high exposure within both the Kubeflow community and the Jupyter community, offering opportunities for broad collaboration and visibility.
• This project is anticipated to significantly enhance the user-friendliness and overall adoption of Kubeflow. Its outputs are highly anticipated by Kubeflow practitioners.
• Despite the project encompassing a wide range of deliverables, it will be considered successful even if only a portion of the work is completed. The student will not be working in isolation – other Kubeflow contributors will actively assist and collaborate throughout the project.

Skills Required

• Proficiency in Python for backend development and API integration.
• Experience with JavaScript/TypeScript for frontend development.
• Experience with modern UI frameworks (e.g., React, Jupyter widgets) is a plus.
• Familiarity with Jupyter Notebook, JupyterLab, and extension development.
• Experience using Git/GitHub and contributing to community-driven projects.

Mentors

@ederign
@StefanoFioravanzo

Component

Kubeflow IDE / Kubeflow Jupyter Extension (IDE Working Group)

Difficulty

Medium

GitHub Issues References

• Proposal: IDE Working Group
• Kale Donation to Kubeflow

Expected Size of the Project

350 Hours

[Shekharrajak]

Project title/description:

Enhancing Kubeflow with Batch Processing Gateway for Scalable and Efficient Multi-Cluster Spark Job Management

Detailed description of the project:

Managing Apache Spark jobs in a multi-cluster Kubernetes environment presents several challenges, including inefficient workload distribution, performance bottlenecks, and debugging complexities. Kubeflow users working with large-scale data processing and machine learning workflows require a streamlined, cloud-native experience that optimizes Spark job execution, monitoring, and debugging.
This project proposes integrating the Batch Processing Gateway (BPG) with Kubeflow to enable an efficient, scalable, and centralized approach for submitting, monitoring, and managing Spark applications across multiple clusters. By enhancing the API and user experience, this integration will provide seamless job routing, performance tracking, and debugging capabilities while reducing the computational burden on Kubeflow notebooks.

Key Objectives:

1. Analyse, Design, Plan, and Execute Spark Job Execution Strategies:
   1. Evaluate the trade-offs between running a Spark kernel directly within a Kubeflow Notebook versus leveraging the Batch Processing Gateway for job submission.
   2. Assess the cloud-native design of Kubeflow SDK and Notebook environments to determine the optimal approach for Spark integration that maximizes efficiency, scalability, and usability.
   3. Make a well-informed decision on whether to support Spark kernels within notebooks, use BPG, or implement a hybrid approach for an enhanced user experience.
2. Automated Job Routing and Scalable Execution:
   1. Implement dynamic workload routing using BPG to automatically distribute Spark jobs based on cluster load, resource availability, and workload priority.
   2. Integrate with the Spark Operator to optimize resource allocation, minimize execution delays, and ensure efficient scaling for petabyte-scale machine learning and data processing workloads.
3. Enhanced User API and Notebook Integration:
   1. Develop a Python SDK for Kubeflow notebooks, enabling users to submit, manage, and monitor Spark jobs via BPG REST APIs for a lightweight, scalable solution.
   2. Ensure a seamless user experience by providing intuitive APIs that abstract complex job management operations, making it easier for data scientists and ML engineers to experiment and iterate on workflows within
4. Comprehensive Debugging and Performance Monitoring:
   1. Enable full debugging capabilities by integrating Spark UI, logging, and monitoring tools into Kubeflow, allowing users to visualize Spark DAGs, tasks, and execution stages.
   2. Implement centralized logging and Prometheus-based monitoring to provide real-time insights into Spark job performance across clusters.
   3. Ensure users can efficiently analyze job execution, detect bottlenecks, and optimize data processing and ML workflows within Kubeflow.
   4. Note: Most of the logging APIs must be leveraged out of the box from either BPG or Spark - but we need to document, show case examples to user.

Mentors expecting GSoC project execution plan - phase wise with weekly milestone that student want to achieve.

Expected Outcomes:

• A robust integration of BPG into the Kubeflow ecosystem, enabling efficient Spark job management across multiple clusters.
• A Python SDK compatible with Kubeflow notebooks to facilitate Spark job submission through BPG, offering a scalable solution that reduces notebook load and enhances performance.
• Comprehensive documentation and user guides to assist users in leveraging the new features effectively.

Skills Required/Preferred:

**Curious to learn, design, develop and having below skillsets will be plus : **

• Proficiency in Python, Java and familiarity with developing SDKs.
• Experience with Kubernetes and managing containerized applications.
• Understanding of Apache Spark and its deployment on Kubernetes clusters.
• Familiarity with RESTful API development and integration.
• Experience with monitoring tools and logging frameworks is a plus.

Possible Mentors:

• [Shekhar Prasad Rajak], [Software Development Engineer, Apple Inc], [Github: @Shekharrajak , Mail: [email protected]]
• [Chaoran Yu], [Mentor Title/Position], [Github: @yuchaoran2011]
• [Andrey Velichkevich], [Mentor Title/Position], [Github @andreyvelich]

Component:

• Kubeflow
• Batch Processing Gateway
• Apache Spark Operator
• Kubeflow SDK proposal

Difficulty:

• Medium to Hard

GitHub Issue:

• Enhancing Kubeflow with Batch Processing Gateway for Efficient Multi-Cluster Spark Job Management spark-operator#2422

Expected Project Size:

300+ hours

By undertaking this project, contributors will play a crucial role in enhancing the performance, efficiency, and usability of Spark applications within the Kubeflow ecosystem, thereby addressing current challenges in multi-cluster job management.

Why This Project?

By integrating Batch Processing Gateway with Kubeflow Notebooks, this project provides a cloud-native, scalable, and user-friendly solution for Spark job execution, debugging. It will significantly improve performance, efficiency, and developer experience, enabling ML practitioners and data engineers to focus on experimentation and optimization without struggling with job management complexities.

Batch Processing Gateway can help enterprise environments, managing Apache Spark jobs across multiple Kubernetes clusters presents challenges such as inefficient job distribution, performance bottlenecks, and complex workload balancing. Integrating the Batch Processing Gateway (BPG) into Kubeflow aims to address these issues by providing a centralized mechanism for submitting, monitoring, and managing Spark applications across various clusters.

[chasecadet]

@rareddy id love to mentor. Especially around manifests.

[andreyvelich]

@rareddy Here are draft ideas from Training and AutoML WG.

Project 1

Title: Enable GPU Testing for LLM Blueprints in Kubeflow Trainer

Tracking issue: kubeflow/trainer#2432

Skills required: GitHub Actions, Kubernetes, PyTorch, Python

Difficulty: hard

Length: 350 hrs

Mentors: TBD

Component: Kubeflow Trainer

Project 2

Title: Support JAX and/or TensorFlow Training Runtimes in Kubeflow Trainer

Tracking issue: TBD

Skills required: Go, Kubernetes, JAX, TensorFlow

Difficulty: medium

Length: 350 hrs

Mentors: TBD

Component: Kubeflow Trainer

Project 3

Title: Support Kubernetes Sidecars for Katib Metrics Collectors

Detailed Description
Open issue: kubeflow/katib#2181

Katib implements Pull-based Metrics Collector as a sidecar container to collect training metrics from the Trials once training is complete. However, the Pull-based Metrics Collector has some problems. For example, the Trial will fail if the training container is finished before Metrics Collector is started.
After v1.28, Kubernetes add native support for sidecar containers as part of KEP 753, which allows us to launch sidecar containers before the training container. In order to address the problems with the Pull-based Metrics Collector, we need to support Kubernetes Sidecar Containers in Katib.

Expected Outcomes

Successfully integrate Katib Metrics Collectors with Kubernetes Sidecars

Provide some unit tests and e2e tests

Skills Required/Preferred: Kubernetes, Go, YAML, Python

Possible Mentors @Electronic-Waste , TBD

Component: Kubeflow Katib

Difficulty: Medium

Expected Size of the Project: 350 hours

cc @Electronic-Waste @kubeflow/wg-training-leads

[Electronic-Waste]

@rareddy Here are more possible ideas for Training and AutoML WG

Project 4

Title: Export Fine-Tuned LLM to Model Registry

Tracking issue: TBD

Detailed Description: Trainer has implemented initializers for model and dataset, and will support model exporter in the future. By supporting the model registry as one of the destinations of the exporter, Trainer will integrate with Kubeflow ecosystem more deeply.

Skills required: Kubernetes, Go, YAML, Python

Difficulty: hard

Length: 350 hrs

Mentors: TBD

Component: Kubeflow Trainer / Model Registry

Project 5

Title: Add Volcano scheduler support in Trainer

Tracking issue: TBD

Detailed Description: Currently, Trainer does not support Volcano for scheduling. Since Volcano is a widely adopted scheduler for AI workloads, it could provide Trainer with more AI-specific scheduling capabilities if we integrate Volcano into Trainer

Skills required: Kubernetes, Go, Volcano

Difficulty: hard

Length: 350 hrs

Mentors: TBD

Component: Kubeflow Trainer

cc @kubeflow/wg-training-leads @kubeflow/wg-data-leads

[juliusvonkohout]

@rareddy id love to mentor. Especially around manifests.

Yes, it could mean upstreaming the various Helm chart projects into Kubeflow/manifests. That alone would be a 175+ hours project on its own.

[kimwnasptd]

"secure istio-cni by default and an option for istio-ambient mesh with zero overhead namespace (single waypoint proxy deployment)" maybe you have a better formulation for the targets.

@juliusvonkohout what if we keep it to Ambient, to not make it too broad, but focus it on updating the components owned by Kubeflow to work with Ambient Mesh:

1. Controllers to create HTTPRoute and AuthorizationPolicies, that align with way-point proxies
2. Manifests to also have a flavour of HTTPRoute and updated AuthorizationPolicies

??

[juliusvonkohout]

• Controllers to create HTTPRoute and AuthorizationPolicies, that align with way-point proxies

• Manifests to also have a flavour of HTTPRoute and updated AuthorizationPolicies

i will try to incorporate that into the PR, but we should keep istio-cni as the simpler target as well. How far we get is another question. We can also extend if needed later.

[juliusvonkohout]

Here is the PR for anyone interested kubeflow/website#3991

[thesuperzapper]

I think we should remove the helm chart project for a few reasons:

1. We have not agreed as a community that we will have an official helm chart.
2. Technically speaking, it's not possible to deploy Kubeflow in a single helm chart. This means you will need to introduce dependencies on tools like ArgoCD, which will make it very opinionated (so any such approach makes a lot more sense as a "distribution").
3. Maintaing such a chart would not be sustainable for the community, there is a reason we went with the "distributions" method (like Kubernetes), there is just too much variation in how people can deploy Kubeflow and we can't support them all.

NOTE: Because I know people love the idea of a helm chart, I want to highlight that anyone is welcome to create a Kubeflow distribution, and if people like your project they will use it. This is just like how Kubernetes has many distributions which approach the problem in different ways.

[thesuperzapper]

@anencore94 It sounds issue like that project is better suited to be under the Kserve organization?

Are you guys participating in GSoC?

[anencore94]

@anencore94 It sounds issue like that project is better suited to be under the Kserve organization?

Are you guys participating in GSoC?

I thought kserve is under the kubeflow org even if the github organization is separated. Isn't it anymore? There is kserve as a part of kubeflow components as I can see here. https://github.com/kubeflow/kubeflow?tab=readme-ov-file#kubeflow-components , https://www.kubeflow.org/docs/started/architecture/#kubeflow-ecosystem @thesuperzapper

[thesuperzapper]

@anencore94 KServe currently has its own governance, and is separately owned by the LFAI, rather than the CNCF. However, there are discussions about them coming back under Kubeflow, but not sure what the status on that is.

That diagram is technically not correct, they are an "external add-on" (see sidebar).

There has always been lots of debate around what to call them, but from a governance perspective, KServe is not controlled by the Kubeflow Steering Committee (KSC) so is not "part" of Kubeflow officially.

[anencore94]

Thanks for the clarification, @thesuperzapper!

I understand that KServe operates independently under LFAI governance. Since my proposal mainly focused on integrating KServe with MLflow. I believe it might be more appropriate to submit it under the KServe GSoC (if they are participating officially).

I'll hide my previous comment. Thanks.

@rareddy
I'd love to be mentor in several projects on GSoC 2025.
I don't have any proposal yet, but I'm also interested in co-mentoring the following projects:

• Enable GPU Testing for LLM Blueprints in Kubeflow Trainer
• Support Kubernetes Sidecars for Katib Metrics Collectors
• Export Fine-Tuned LLM to Model Registry

[terrytangyuan]

KServe is not participating GSOC. We are working on moving from LF AI & Data to CNCF. See cncf/toc#1367

[andreyvelich]

That diagram is technically not correct, they are an "external add-on" (see sidebar).
There has always been lots of debate around what to call them, but from a governance perspective, KServe is not controlled by the Kubeflow Steering Committee (KSC) so is not "part" of Kubeflow officially.

@thesuperzapper Let's avoid any confusion here please.
KServe is a unique case among any other OSS projects, and for that reason, some people consider it part of the Kubeflow ecosystem. It has a clearly defined role within the Kubeflow AI/ML Lifecycle diagram

I've already discussed this with @yuzisun and @johnugeorge in the past.

We've also been discussing the removal of the "external add-ons" concept from the Kubeflow website to prevent confusion when users ask, What is Kubeflow?

As @anencore94 correctly pointed out, we put KServe under this diagram: https://www.kubeflow.org/docs/started/introduction/#kubeflow-overview-diagram and also in Kubeflow Architecture diagram as part of Kubeflow Components: https://www.kubeflow.org/docs/started/architecture/#kubeflow-ecosystem

And I don't see any reason to change it unless broader Kubeflow/KServe community or @kubeflow/kubeflow-steering-committee @juliusvonkohout @franciscojavierarceo have different opinion here.

---

In case of GSoC, I am fine to not include KServe if we don't want to.