Kubeflow 如何在没有 ksonnet 的情况下发展

许多软件项目依赖于作为独立开源项目运行的模块。当其中一个模块失去支持（这是不可避免的）时，主要项目周围的社区必须决定如何继续。

这种情况目前正在 Kubeflow 社区中发生。Kubeflow 是一个不断发展的开源平台，用于在 Kubernetes 上开发、编排、部署和运行可扩展且可移植的机器学习工作负载。最近，Kubeflow 组件 ksonnet 的主要支持者宣布将 不再支持 该软件。

当一个软件失去支持时，决策过程（和结果）会因软件是开源还是闭源而有很大差异。

手机类比

为了说明当组件失去支持时，开源社区和闭源/单一软件供应商的处理方式有何不同，让我们使用一个硬件设计的例子。

假设您购买了 A 型号手机，但它停止工作了。当您尝试修理它时，您发现制造商已倒闭且不再提供支持。由于手机的设计是专有的和封闭的，因此没有其他制造商可以支持它。

现在，假设您购买了 B 型号手机，它也停止工作了，并且其制造商也已倒闭且不再提供支持。但是，B 型号的设计是开放的，另一家公司正在营业，制造、修理和升级 B 型号手机。

这说明了使用闭源和开源原则编写的软件之间的一个区别。如果闭源软件解决方案的供应商倒闭，支持会随着供应商消失，除非供应商出售软件的设计和知识产权。但是，如果开源解决方案的供应商倒闭，则没有知识产权可出售。根据开源原则，源代码可供任何人根据许可使用和修改，因此另一家供应商可以继续维护该软件。

Kubeflow 如何在没有 ksonnet 的情况下发展

ksonnet 的支持者决定停止开发的影响说明了 Kubeflow 的开放和协作设计过程。Kubeflow 的设计人员有几个选择，例如替换 ksonnet、采用和开发 ksonnet 等。由于 Kubeflow 是一个开源项目，因此所有选项都在 Kubeflow 邮件列表中公开讨论。社区的一些建议包括

• 我们是否应该考虑 CNCF/Apache 项目，例如 helm
• 我会选择回归基础。KISS（保持简单，愚蠢）。使用简单的 jsonnet + kubectl + makefile/scripts 怎么样？例如，coreos prometheus operator 就是这样做的。这也将降低入门门槛（无需新工具），并让 k8s（gke、openshift 等）的供应商轻松地在此基础上构建。
• 我投票赞成使用简单的程序化上下文，无论是手动 jsonnet + kubectl，还是简单的 Python 脚本 + Python K8s 客户端，或是可以构建在这些之上的任何工具。

邮件列表的成员正在讨论和辩论 ksonnet 的替代方案，并将达成继续开发的决定。我喜欢开源方式的适应性在于它是社区共同完成的。与通常由一个供应商设计的闭源软件不同，开源项目的成员组织可以协作地将项目引导到他们认为最合适的方向。随着 Kubeflow 的发展，它将受益于开放、协作的决策框架。