We are working on a redesign of Open Data Hub that will result in a tiered structure for components. The first tier will be open source projects that align very well with Red Hat's product portfolio and strategy to expand our influence in ModelOps, we will be investing more engineering resources towards. This includes Kubeflow Pipelines, KServe, Ray.io, ModelMesh, and Kubeflow Notebook Controller to start. You can think of this as Open Data Hub Core.

The second tier will be open source projects that have no alignment with Red Hat's strategy and therefore doesn't make sense for us to further invest Red Hat engineering efforts in. For some components such as Pachyderm, there are ISVs we are partnered with that will continue to support the component and its integrations into ODH and RHODS. For components such as Spark where there is not a closely aligned ISV, the community will have recipes for deploying that component alongside Open Data Hub with tutorials, but it will not be officially supported anymore as part of ODH.

We will be elaborating more in the ODH community about this direction, but this allows us to focus more engineering work on the components that will ultimately be a part of RHODS. Spark doesn't make sense to be in RHODS because we would then be competing with Data Bricks.

We are instead ramping up to invest more in Ray.io, which we feel is a growing community and offers more capabilities that align with our ModelOps direction.

We will also be pushing the Google Spark operator in our "recipes" instead of the Radanalytics operator because it has more outside support and is doing better keeping up with Spark versions.

We'll have much more on this in the ODH community very very soon. We plan to open up the discussion and get more feedback from the field and others to ensure we architect something that allows us to grow stronger with innovation, but also meets the needs of our customers.