Add Makinarocks Link to External Add-Ons section

[hunhoon21]

Makinarocks Link is a JupyterLab extension to build pipelines, where each component represents a JupyterLab cell. pipeline from Link can be converted to a Kubeflow pipeline(*.yaml). It'll be a very easy way to build a Kubeflow pipeline using Makinarocks Link. So I suggest adding Makinarocks Link to External Add-Ons section on Kubeflow website.

I'll open a PR for this. Is it Okay?

Thank you.

• What Makinarocks Link is
• How the pipeline created in Link convert to Kubeflow pipeline

[varodrig]

@hbelmiro any thoughts on this?

[varodrig]

/area pipelines

[varodrig]

@kubeflow/wg-pipeline-leads to provide feedback. thanks.

[varodrig]

@kubeflow/wg-pipeline-leads to provide feedback. thanks.

[hbelmiro]

I understand External Add-Ons as former or future Kubeflow projects, which is not the case for Makinarocks.
If my understanding is correct, we should not add Makinarocks or any other project just for the sake of it integrating with Kubeflow.
I remember even hearing some discussion about removing this section.

I may be wrong though.
@andreyvelich thoughts?

[thesuperzapper]

My perspective is that external add-ons can include projects which are not currently being donated to Kubeflow, but they must be open-source and not commercial projects.

I.e. not applicable in this case.

[andreyvelich]

From my point of view it is hard to tell which projects are not "commercial" given that many OSS are dominated by the single organization.

As I said before, I would like to remove concept of external add-ons from the Kubeflow website to reduce user confusion on "What is Kubeflow ?".

If individual Kubeflow projects would like to have integration with 3rd party projects, they can always create dedicated User Guide in their website section. For example, how to use KFP with Tekton Pipelines.

@kubeflow/kubeflow-steering-committee @juliusvonkohout @franciscojavierarceo Thoughts ?

[franciscojavierarceo]

My opinion here may not be preferred but I want to be honest about it.

I, personally, am very pro an open policy. If companies want to contribute documentation or integrations to Kubeflow, I think that is beneficial to the ecosystem.

We should just make it clear that those components are "unsupported add-ons" and are maintained by the company, with our right to remove them at anytime (e.g., if the project becomes inactive or we just want to).

I would even allow that to include commercial projects.

[andreyvelich]

That make sense @franciscojavierarceo.
I think, instead of having the dedicated page for each project and maintain it, we can just have one single page, e.g. Projects that use Kubeflow Ecosystem or Projects that integrate with Kubeflow Ecosystem, where we can point to other project docs that integrate with Kubeflow Ecosystem.
And as you said, we should clearly say that Kubeflow Community can't gurantee stability of these projects.

The good examples I saw here:

• Ray docs: https://docs.ray.io/en/latest/ray-overview/ray-libraries.html
• Airflow: https://airflow.apache.org/ecosystem/#tools-integrating-with-airflow

@terrytangyuan Do you know if Argo has similar page ?

Any thoughts @chasecadet @akgraner ?