CNCF Sandbox是CNCF托管的一個開源項目孵化器，它提供了一個獨立的、靈活的、開放的環境，以幫助項目開發者構建和推廣新的云原生技術。CNCF Sandbox項目孵化器的管理主要包括以下方面：項目申請：項目開發者可以通過向CNCF提交申請，將自己的項目納入CNCF Sandbox。CNCF會對申請進行審核，確認項目是否符合CNCF的要求和標準。項目評估：申請成功的項目將進入CNCF Sandbox項目孵化器的評估流程。在評估期間，項目開發者將與CNCF社區合作，進行代碼審查、測試和驗證等工作，以確保項目的質量和可行性。項目發布：當項目通過了評估后，就可以在CNCF Sandbox項目孵化器中發布。發布后，項目開發者將與CNCF社區合作，進行推廣和宣傳工作，吸引更多的用戶和貢獻者參與到項目中來。項目維護：發布后的項目將由項目開發者和CNCF社區共同維護和管理。這包括持續的開發、測試、修復和更新，以確保項目的持續發展和進步。

總的來說，CNCF Sandbox是一個非常開放和靈活的項目孵化器，它可以幫助開發者將自己的項目推向更高的水平，同時也可以為整個云原生社區帶來更多的創新和發展，但是隨著CNCF的不斷發展，Sandbox機制在一定程度上出現了一些問題和挑戰。

注：下述內容只代表個人觀點

CNCF 云原生基金會大使，CoreDNS 開源項目維護者。主要分享云原生技術、云原生架構、容器、函數計算等方面的內容，包括但不限于 Kubernetes，Containerd、CoreDNS、Service Mesh，Istio等等

1、“開源盛況”

根據成熟度不同，CNCF項目分為Sandbox（沙盒）、Incubating（孵化）和Graduation（畢業）三個階段。

圖片

從圖中可以看出，沙盒-孵化-畢業所代表的成熟度依次升高。其中，被CNCF接受并成為Sandbox項目需要至少2個TOC的sponsor的支持，截至2023年，Sandbox項目已經達到100個， 孵化項目必須提供至少三個獨立的終端用戶成功地使用在生產環境中的資料信息，在質量和范圍方面都得到證明。而要達到畢業，則需要在孵化標準之上滿足更嚴苛的要求，代表這是一個“跨越鴻溝”的項目。

截至2023年，經由CNCF培育機制，最終畢業的項目已達20個，CNCF 畢業項目代表著對于云原生領域的重要貢獻和認可。這些項目在技術、社區和用戶方面都經過了嚴格的評估和驗證，展現出了在云原生生態系統中的領導地位和影響力。

圖片

2、“隱憂”

隨著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，下述為官方回應

圖片

3、 “小結”

對于云原生的發展來說，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)

本文轉載自微信公眾號「 DCOS」，作者「DCOS」，可以通過以下二維碼關注。

轉載本文請聯系「DCOS」公眾號。