OpenShift 作为容器平台的标杆产品，同时也是开源商业化的标杆，一直是被人试图追赶或者超越的对象。但是如果只是照着 OpenShift 的产品模仿，那么当追上 OpenShift 时只可能有一种情况，那就是 OpenShift 停止发展，过了一年后你终于追上了，然后会因同样原因被淘汰。
那么有没有什么方法能够追上甚至超越 OpenShift 呢？我认为要从 OpenShift 本身商业模式的选择和技术路线上的选择入手，从他们在这种选择下不可避免的缺点入手，做出差异化，才有超越的可能。
OpenShift 并不 Open
OpenShift 里的 Open 可能和 OpenAI 里的 Open 是同一个 Open。如果你尝试不通过 RedHat 的销售自己去部署一套 OpenShift 就会知道我在说什么了。
OpenShift 的所有组件确实是开源的，但如果你是一个纯粹的社区用户会步步受挫。一个功能你可能找不到对应组件，找到组件可能找不到对应源码，找到源码又没有文档指导如何编译使用。这些现象在那些完全是 OpenShift 自己使用的组件里已经见怪不怪了。大概 OpenShift 这部分的社区只是对客户和合作伙伴开放的。
而对于那些非 OpenShift 专属的组件，OpenShift 采取的策略会是一旦选择就大举投入，争取到对应组件的社区的主导权。所以会看到的一个现象是有些社区很出名的项目 OpenShift 的人完全不投入，而一个项目在平稳发展了几年后会突然涌入大量 OpenShift 的人。
这些都是 OpenShift 在商业化与开源之间权衡后的选择，并没有对错之分，但这会给更开放的项目留出机会。如果新的产品能够降低参与门槛，收取更广泛的反馈，让更多的贡献者来参与创新，那么我认为它的上限将会超越 OpenShift。
OpenShift 的技术并不先进
受限于第一点因素，OpenShift 并不能广泛的吸收整个生态的最新成果。在生态内某个组件和 OpenShift 专属的组件功能重叠情况下，OpenShift 内部的研发人员是很难有动力切换到另一个社区或者另一个公司主导的开源组件。
以我比较了解的网络为例，OpenShift 早期通过 Haproxy 实现了 Route 来打通集群外访问集群内的流量。在当时 Ingress 还不成熟，Route 是一个相比社区先进的多的方案，OpenShift 的方案在当时是绝对领先的。但是随着 Ingress 的成熟，社区生态内各种网关都在飞速发展，而 OpenShift 受限于自己早期的实现和用户用法很长时间都没有去支持 Ingress 这个在社区已经标准化的功能。现阶段 Ingress 规范已经进化到 GatewayAPI 有一段时间了，大量 AI Gateway 的新场景都在通过 GatewayAPI 进行扩展，而 OpenShift 现如今还没有支持 GatewayAPI，最近正在计划在之前的 Haproxy 上同时支持 Route，Ingress 和 GatewayAPI。
类似的案例在 OpenShift 内还有很多，早期可能还是一个优秀的方案，但由于 OpenShift 专属导致不开放，随着社区的发展，原先优势的方案反而变成了阻碍前进的障碍。就像现在在 Kubernetes 上做 Ingress Gateway 不会有人去参考 OpenShift 的实现，在很多细分领域 OpenShift 已经并不是最先进的解决方案了，尤其是在那些由 OpenShift 专属组件提供服务的领域。现在的 OpenShift 在我看来就是一个覆盖面积很广，但平庸且无趣的平台。
容器平台的生产过程其实和手机的生产很像，都是从成百上千个供应链供应商那里选择需要的配件，然后组装成一个成品。如果能够保持开放，选择供应链上最先进的那些配件，或者根据场景快速组合出一个针对特定场景的产品，那么在技术竞争力上应该会远超 OpenShift。
总结
要想真正追赶甚至超越 OpenShift，关键不是在已有功能上亦步亦趋，而是要做到更开放、更领先。这样才能摆脱追随者路径，真正形成对 OpenShift 的差异化优势，成为下一轮技术浪潮的主导者。