一次CNCF Sandbox申请引发的闹剧
一次CNCF Sandbox申请引发的闹剧
编辑 ｜ zouyee
CNCF Sandbox是CNCF托管的一个开源项目孵化器，它提供了一个独立的、灵活的、开放的环境，以帮助项目开发者构建和推广新的云原生技术。CNCF Sandbox项目孵化器的管理主要包括以下方面：项目申请：项目开发者可以通过向CNCF提交申请，将自己的项目纳入CNCF Sandbox。CNCF会对申请进行审核，确认项目是否符合CNCF的要求和标准。项目评估：申请成功的项目将进入CNCF Sandbox项目孵化器的评估流程。在评估期间，项目开发者将与CNCF社区合作，进行代码审查、测试和验证等工作，以确保项目的质量和可行性。项目发布：当项目通过了评估后，就可以在CNCF Sandbox项目孵化器中发布。发布后，项目开发者将与CNCF社区合作，进行推广和宣传工作，吸引更多的用户和贡献者参与到项目中来。项目维护：发布后的项目将由项目开发者和CNCF社区共同维护和管理。这包括持续的开发、测试、修复和更新，以确保项目的持续发展和进步。
总的来说，CNCF Sandbox是一个非常开放和灵活的项目孵化器，它可以帮助开发者将自己的项目推向更高的水平，同时也可以为整个云原生社区带来更多的创新和发展，但是随着CNCF的不断发展，Sandbox机制在一定程度上出现了一些问题和挑战。
注：下述内容只代表个人观点
“开源盛况”
根据成熟度不同，CNCF项目分为Sandbox（沙盒）、Incubating（孵化）和Graduation（毕业）三个阶段。
从图中可以看出，沙盒-孵化-毕业所代表的成熟度依次升高。其中，被CNCF接受并成为Sandbox项目需要至少2个TOC的sponsor的支持，截至2023年，Sandbox项目已经达到100个， 孵化项目必须提供至少三个独立的终端用户成功地使用在生产环境中的资料信息，在质量和范围方面都得到证明。而要达到毕业，则需要在孵化标准之上满足更严苛的要求，代表这是一个“跨越鸿沟”的项目。
截至2023年，经由CNCF培育机制，最终毕业的项目已达20个，CNCF 毕业项目代表着对于云原生领域的重要贡献和认可。这些项目在技术、社区和用户方面都经过了严格的评估和验证，展现出了在云原生生态系统中的领导地位和影响力。
“隐忧”
随着CNCF的不断发展，Sandbox机制在一定程度上出现了一些问题和挑战。以下为一些主要的问题：
孵化项目数量过多：近年来，越来越多的开源项目申请进入CNCF的Sandbox，这使得CNCF的管理机构可能无法有效地处理这些项目，从而导致项目孵化的效率和质量下降。
孵化后的项目维护问题：一些Sandbox项目在进入CNCF后，由于各种原因（如缺乏贡献者、维护者的流失等），可能无法维持其健康的生态系统，这可能会导致项目最终停止维护。
孵化项目过度依赖CNCF：一些Sandbox项目可能会过度依赖CNCF社区提供的资源和支持，而丧失自身的社区建设和发展能力，这可能会影响项目的可持续性发展。
为了应对这些挑战和问题，CNCF在不断完善基金会章程，优化和改进其Sandbox机制，提高项目孵化的效率和质量，同时鼓励项目开发者在孵化过程中积极参与社区建设和发展，从而实现更加健康的开源生态系统。
开源“窃贼”
近期在社区看到有人滥用CNCF的Sandbox机制，篡改他人项目并修改开源协议，并申请进入Sandbox，这是非常不道德且不利于开源社区发展的行为。如果这种项目都能蒙混过关，将极大的破坏CNCF Sandbox的准入机制，导致项目质量下降，最终可能会损害整个开源社区的生态系统，幸运的是，在社区初审阶段，上述项目被否，但针对该类行为，带来的次生影响，必须予以重视。
下面让我们欣赏一下其中典型的骚操作
github ID：dongjiang1989是代码组织kubeservice-stack的拥有者，其申请进入CNCF Sandbox，但似乎没有遵守相应的开源行为准则，特别是CNCF章程中的知识产权政策，具体例证如下：
篡改开源协议
诺基亚的代码库CPU-Pooler，它使用BSD许可证，被其修改为Apache协议，且无引用等说明
nokia/CPU-Pooler
kubeservice-stack/cpusets-controller
滥用Apache协议
该作者fork了原属于FinOps基金会认证的crane-scheduler项目，并进行所谓二次开发，但需要注意的是cran-scheduler项目已经被捐赠（没有）给了FinOps基金会。
这里ahead的commit大多是deploy相关，且commit msg的习惯有待提高，这种二开的意义是什么？
此外，该作者在其local-cloud-csi-driver项目中使用了大量来自kubernetes-sigs/alibaba-cloud-csi-driver的代码，虽然没有违反Apache协议，恰当与否也另当别论，但显然不尊重开源社区，不尊重阿里巴巴等开源共建者的工作。
其中marrida fork了dongjiang1989的仓库（marrida的fork行为应该是留证据）：kubeservice-stack/local-cloud-csi-driver
类似的情况遍布于其他代码库中，个人认为该作者的行为是对开源贡献者的亵渎。
套壳项目荒谬的吹嘘
kubeservice-stack/pingmesh-agent 的README如下所示：
让我们看看他的代码结构
好了，看看碰瓷的prometheus的官方项目blackbox_exporter
blackbox_exporter的作者可能也不知道他们的项目能被吹出这种程度。
肆无忌惮的漠视
mariida提醒了诺基亚的开源工作者，他们的代码可能已经受到了侵害，有人窃取了他们的代码并删除了BSD协议，下图为诺基亚开源项目方的相关回应
诺基亚开源项目方针对dongjiang98“修改”协议的行为，让其修改协议，dongjiang1989却选择了无视
除了上述行为之外，dongjiang1989还打算将他的“个人”项目引入hub，下述为官方回应
“小结”
对于云原生的发展来说，Sandbox宽松准入政策是有益的，但是，个人认为，在TOC接纳投票之前，可能需要对代码协议进行初步审查，以避免代码抄袭和其他侵犯知识产权的行为。
对于这种情况，CNCF应该加强对Sandbox项目的审核和评估，确保每个申请进入Sandbox的项目都符合CNCF的要求和标准，并且有真正的技术需求和社区价值。同时，CNCF也应该加强对孵化项目的监管，确保它们不单纯是KPI项目，而是真正有贡献和影响力的开源项目。如果发现某个项目是纯粹的KPI项目，CNCF应该及时取消它的孵化资格，并采取其他措施，防止类似事件再次发生。总的来说，开源社区需要尊重道德和诚信原则，避免滥用CNCF的Sandbox机制，以确保整个社区的发展和进步。
由于笔者时间、视野、认知有限，本文难免出现错误、疏漏等问题，期待各位读者朋友、业界专家指正交流。
参考文献
1. https://github.com/cncf/foundation/blob/main/charter.md#11-ip-policy
2. [Sandbox] KubeService Stack · Issue #15 · cncf/sandbox (github.com)
3. Respect BSD-3-License please · Issue #1 · kubeservice-stack/cpusets-controller (github.com)
4. [OFFICIAL] kubeservice-stack Helm Chart · Issue #2951 · artifacthub/hub (github.com)