一次CNCF Sandbox申請引發(fā)的鬧劇
CNCF Sandbox是CNCF托管的一個開源項目孵化器,它提供了一個獨立的、靈活的、開放的環(huán)境,以幫助項目開發(fā)者構(gòu)建和推廣新的云原生技術(shù)。CNCF Sandbox項目孵化器的管理主要包括以下方面:項目申請:項目開發(fā)者可以通過向CNCF提交申請,將自己的項目納入CNCF Sandbox。CNCF會對申請進行審核,確認項目是否符合CNCF的要求和標準。項目評估:申請成功的項目將進入CNCF Sandbox項目孵化器的評估流程。在評估期間,項目開發(fā)者將與CNCF社區(qū)合作,進行代碼審查、測試和驗證等工作,以確保項目的質(zhì)量和可行性。項目發(fā)布:當項目通過了評估后,就可以在CNCF Sandbox項目孵化器中發(fā)布。發(fā)布后,項目開發(fā)者將與CNCF社區(qū)合作,進行推廣和宣傳工作,吸引更多的用戶和貢獻者參與到項目中來。項目維護:發(fā)布后的項目將由項目開發(fā)者和CNCF社區(qū)共同維護和管理。這包括持續(xù)的開發(fā)、測試、修復和更新,以確保項目的持續(xù)發(fā)展和進步。
總的來說,CNCF Sandbox是一個非常開放和靈活的項目孵化器,它可以幫助開發(fā)者將自己的項目推向更高的水平,同時也可以為整個云原生社區(qū)帶來更多的創(chuàng)新和發(fā)展,但是隨著CNCF的不斷發(fā)展,Sandbox機制在一定程度上出現(xiàn)了一些問題和挑戰(zhàn)。
注:下述內(nèi)容只代表個人觀點
CNCF 云原生基金會大使,CoreDNS 開源項目維護者。主要分享云原生技術(shù)、云原生架構(gòu)、容器、函數(shù)計算等方面的內(nèi)容,包括但不限于 Kubernetes,Containerd、CoreDNS、Service Mesh,Istio等等
1、“開源盛況”
根據(jù)成熟度不同,CNCF項目分為Sandbox(沙盒)、Incubating(孵化)和Graduation(畢業(yè))三個階段。
圖片
從圖中可以看出,沙盒-孵化-畢業(yè)所代表的成熟度依次升高。其中,被CNCF接受并成為Sandbox項目需要至少2個TOC的sponsor的支持,截至2023年,Sandbox項目已經(jīng)達到100個, 孵化項目必須提供至少三個獨立的終端用戶成功地使用在生產(chǎn)環(huán)境中的資料信息,在質(zhì)量和范圍方面都得到證明。而要達到畢業(yè),則需要在孵化標準之上滿足更嚴苛的要求,代表這是一個“跨越鴻溝”的項目。
截至2023年,經(jīng)由CNCF培育機制,最終畢業(yè)的項目已達20個,CNCF 畢業(yè)項目代表著對于云原生領(lǐng)域的重要貢獻和認可。這些項目在技術(shù)、社區(qū)和用戶方面都經(jīng)過了嚴格的評估和驗證,展現(xiàn)出了在云原生生態(tài)系統(tǒng)中的領(lǐng)導地位和影響力。
圖片
2、“隱憂”
隨著CNCF的不斷發(fā)展,Sandbox機制在一定程度上出現(xiàn)了一些問題和挑戰(zhàn)。以下為一些主要的問題:
孵化項目數(shù)量過多:近年來,越來越多的開源項目申請進入CNCF的Sandbox,這使得CNCF的管理機構(gòu)可能無法有效地處理這些項目,從而導致項目孵化的效率和質(zhì)量下降。
孵化后的項目維護問題:一些Sandbox項目在進入CNCF后,由于各種原因(如缺乏貢獻者、維護者的流失等),可能無法維持其健康的生態(tài)系統(tǒng),這可能會導致項目最終停止維護。
孵化項目過度依賴CNCF:一些Sandbox項目可能會過度依賴CNCF社區(qū)提供的資源和支持,而喪失自身的社區(qū)建設(shè)和發(fā)展能力,這可能會影響項目的可持續(xù)性發(fā)展。
為了應對這些挑戰(zhàn)和問題,CNCF在不斷完善基金會章程,優(yōu)化和改進其Sandbox機制,提高項目孵化的效率和質(zhì)量,同時鼓勵項目開發(fā)者在孵化過程中積極參與社區(qū)建設(shè)和發(fā)展,從而實現(xiàn)更加健康的開源生態(tài)系統(tǒng)。
開源“竊賊”
近期在社區(qū)看到有人濫用CNCF的Sandbox機制,篡改他人項目并修改開源協(xié)議,并申請進入Sandbox,這是非常不道德且不利于開源社區(qū)發(fā)展的行為。如果這種項目都能蒙混過關(guān),將極大的破壞CNCF Sandbox的準入機制,導致項目質(zhì)量下降,最終可能會損害整個開源社區(qū)的生態(tài)系統(tǒng),幸運的是,在社區(qū)初審階段,上述項目被否,但針對該類行為,帶來的次生影響,必須予以重視。
圖片
下面讓我們欣賞一下其中典型的騷操作
github ID:dongjiang1989是代碼組織kubeservice-stack的擁有者,其申請進入CNCF Sandbox,但似乎沒有遵守相應的開源行為準則,特別是CNCF章程中的知識產(chǎn)權(quán)政策,具體例證如下:
篡改開源協(xié)議
諾基亞的代碼庫CPU-Pooler,它使用BSD許可證,被其修改為Apache協(xié)議,且無引用等說明
nokia/CPU-Pooler
圖片
kubeservice-stack/cpusets-controller
濫用Apache協(xié)議
該作者fork了原屬于FinOps基金會認證的crane-scheduler項目,并進行所謂二次開發(fā),但需要注意的是cran-scheduler項目已經(jīng)被捐贈(沒有)給了FinOps基金會。
圖片
這里ahead的commit大多是deploy相關(guān),且commit msg的習慣有待提高,這種二開的意義是什么?
此外,該作者在其local-cloud-csi-driver項目中使用了大量來自kubernetes-sigs/alibaba-cloud-csi-driver的代碼,雖然沒有違反Apache協(xié)議,恰當與否也另當別論,但顯然不尊重開源社區(qū),不尊重阿里巴巴等開源共建者的工作。
其中marrida fork了dongjiang1989的倉庫(marrida的fork行為應該是留證據(jù)):kubeservice-stack/local-cloud-csi-driver
類似的情況遍布于其他代碼庫中,個人認為該作者的行為是對開源貢獻者的褻瀆。
套殼項目荒謬的吹噓
kubeservice-stack/pingmesh-agent 的README如下所示:
圖片
讓我們看看他的代碼結(jié)構(gòu)
圖片
好了,看看碰瓷的prometheus的官方項目blackbox_exporter
blackbox_exporter的作者可能也不知道他們的項目能被吹出這種程度。
肆無忌憚的漠視
mariida提醒了諾基亞的開源工作者,他們的代碼可能已經(jīng)受到了侵害,有人竊取了他們的代碼并刪除了BSD協(xié)議,下圖為諾基亞開源項目方的相關(guān)回應
圖片
諾基亞開源項目方針對dongjiang98“修改”協(xié)議的行為,讓其修改協(xié)議,dongjiang1989卻選擇了無視
除了上述行為之外,dongjiang1989還打算將他的“個人”項目引入hub,下述為官方回應
圖片
3、 “小結(jié)”
對于云原生的發(fā)展來說,Sandbox寬松準入政策是有益的,但是,個人認為,在TOC接納投票之前,可能需要對代碼協(xié)議進行初步審查,以避免代碼抄襲和其他侵犯知識產(chǎn)權(quán)的行為。
對于這種情況,CNCF應該加強對Sandbox項目的審核和評估,確保每個申請進入Sandbox的項目都符合CNCF的要求和標準,并且有真正的技術(shù)需求和社區(qū)價值。同時,CNCF也應該加強對孵化項目的監(jiān)管,確保它們不單純是KPI項目,而是真正有貢獻和影響力的開源項目。如果發(fā)現(xiàn)某個項目是純粹的KPI項目,CNCF應該及時取消它的孵化資格,并采取其他措施,防止類似事件再次發(fā)生。總的來說,開源社區(qū)需要尊重道德和誠信原則,避免濫用CNCF的Sandbox機制,以確保整個社區(qū)的發(fā)展和進步。
由于筆者時間、視野、認知有限,本文難免出現(xiàn)錯誤、疏漏等問題,期待各位讀者朋友、業(yè)界專家指正交流。
參考文獻
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)
本文轉(zhuǎn)載自微信公眾號「 DCOS」,作者「DCOS」,可以通過以下二維碼關(guān)注。
轉(zhuǎn)載本文請聯(lián)系「DCOS」公眾號。