6 月 1 日，開放原子開源基金會（如下簡稱基金會）發佈針對孵化項目的畢業標準 v1.0。畢業標準 v1.0 制定整體遵循「寬進嚴出」原則，注重考察項目代碼和社區的成熟度，並把項目的安全性做爲最高優先級。編程

爲進一步瞭解畢業標準 v1.0 制定意義和其背後價值觀，OSCHINA 採訪了 TOC 副主席譚中意，TOC 成員徐亮、霍海濤、馬濤；並參與 TOC 組織的針對畢業標準 v1.0 的討論會，本文據此梳理各方對畢業標準 v1.0 的見解和解讀。若是你對本份畢業標準有疑問或看法，或是想參與開放原子開源基金會共建工做，歡迎在評論區留言，或發送消息到 xuyijun@oschina.cn 聯繫咱們。瀏覽器

畢業標準詳情查看：開放原子開源基金會發布孵化項目畢業標準 v1.0安全

往期報道回顧：【專題】多角度深刻解析開放原子開源基金會運維

受訪人物簡介：ide

譚中意：TOC 副主席、百度前開源技術委員會的負責人工具

徐亮：TOC 成員、華爲開源能力中心技術專家區塊鏈

霍海濤：TOC 成員、360政企瀏覽器事業部總經理大數據

馬濤：TOC成員、阿里雲研究員、基礎軟件部操做系統團隊負責人ui

研討會部分參與者阿里雲

TOC 成員：

堵俊平：開放原子開源基金會TOC主席、Apache軟件基金會Member、華爲計算開源總經理

開源界 KOL：

劉天棟：開源社理事兼聯合創始人

莊表偉：開源社理事長

姜寧：華爲開源能力中心技術專家、基金會孵化項目導師、Apache軟件基金會 Member

王澤鋒：華爲雲原生開源負責人、CNCF技術監督委員會貢獻者、基金會孵化項目導師

溫銘：支流科技聯合創始人＆CEO、 Apache Skywalking committer

孫金城：阿里雲物聯網分析負責人、Apache軟件基金會 Member、基金會孵化項目導師

林旅強：華爲雲 AI 開發者生態專家，開源社理事兼聯合創始人

高陽：SegmentFault 思否 CEO，開放原子大學第一屆特聘講師

江波：SegmentFault 思否 COO，開源社副執行長

梁堯：開源社理事

畢業標準 v1.0 制定遵循「寬進嚴出」原則

開放原子這次發佈的畢業標準 v1.0 共分紅 10 大章節，共 45 條條款，相較於項目進入基金會孵化時的 4 條要求，數量陡增，這實際上與標準制定時的原則——「寬進嚴出」有較大關係。

TOC 成員徐亮解釋，基金會的整體原則是寬進嚴出。項目進入基金會孵化的准入門檻很是寬鬆，「基本上只要咱們認爲比較符合的項目均可以進入」。可是在畢業時，TOC 作了很是多調研工做，好比大量參考 ASF 和 CNCF 的畢業條款、規章制度，同時也根據開放原子自身的定位作了一些調整，如表述的變動等等。

「基金會最重要的事情就是指導一個項目從孵化到畢業，咱們採用寬進嚴出的原則，相對來講畢業條件很是高，這應該是整個 TOC 裏最重要的文檔，並且會指導咱們以後不少導師的工做，因此重要性很是高，因此咱們也很是慎重。」TOC 副主席譚中意表示。

畢業標準注重考察什麼，爲何？

本份標準考察重點包括項目成熟度、安全性、中立性等方面。關於這些問題的討論以及相關條款的制定，也折射出開放原子的價值觀取向。

聚焦成熟度

譚中意介紹，此份畢業標準在制定時聚焦在成熟度上，一個項目商業意義上的成功分爲三個階段：第一是項目開發的成熟度，即項目自己具有可信的程度；第二是項目上下游的聯動，即該項目成爲事實標準；第三是成爲商業、產業界標準。

「咱們在制定標準時討論，先聚焦在第一個階段項目成熟度上，讓項目可信，讓用戶有信心使用項目。」

項目成熟度主要包括社區成熟度和代碼成熟度。第九部分【Maturity（成熟度）】中對項目代碼的成熟度作了詳細要求。

關於社區成熟度的考量主要包含在畢業標準第六部分【Community（社區）】中，這也是整個畢業標準中篇幅最長的一部分，共有 10 條條款。

爲何有關社區的考覈標準最多？譚中意解釋，項目能走下去的最關鍵特徵是有成熟的社區作支撐，社區的多樣性和長期的可持續性是項目發展必不可缺的條件，這也是 TOC 花很大篇幅制定其相關內容的緣由。

項目的安全性是最高優先級

畢業標準第 5 章【Quality（質量）】第 2 條（OA-QU-20）規定：「項目的安全性是最高優先級」。

【英】The project puts a very high priority on secure software.

【中】項目的安全性是最高優先級的

對此，TOC 主席堵俊平向一些開源界人士徵詢意見：強調安全性最高優先級是否有必要？

姜寧認爲，安全問題要高度重視，也要在內部創建相應的響應機制，不然後續可能沒人敢再用這些軟件。

莊表偉認爲，開放原子是否將安全性放在最高優先級，涉及到基金會對開源項目、安全的理解，這是選擇問題，不是對錯問題。堵俊平回答道：「基金會設定孵化畢業標準，自己就是對旗下項目成熟度有所承諾，是對項目用戶負責的一種體現。若是不重視安全性，或者項目對用戶的安全性不提供任何承諾，則會對項目自己以及基金會品牌形成大的傷害。強調項目的安全性既是咱們的選擇也是咱們的態度。」

中立性是重要的

當咱們提到開源軟件基金會，一般會談到「中立性」，進入某一基金會的開源軟件能夠將其版權、商標權等經過多種方式轉移至基金會，以此保證項目中立性。反之，基金會在項目進入或是畢業時也會對項目中立性有所要求，爲社區繁榮提供保障。

開放原子開源基金會畢業標準中也有許多條款是爲了保障開源項目以及社區中立性而設計。

但近年來一些企業開源的項目，相似 Android，TensorFlow 甚至最近國內比較火的 PingCAP 並無強調中立性也取得了成功，這種現象該如何解釋？中立性爲何仍是重要的？堵俊平向你們拋出了這兩個問題。

姜寧認爲中立性是創建社區很重要的原則，若是基金會不保持中立的話，有些事情可能就守不住了。

劉天棟認爲，中立性的取捨也是選擇問題，若是想要項目保持中立能夠加入基金會，若是但願社區由公司主導，能夠選擇不進入基金會。

莊表偉和林旅強都認爲這件事涉及基金會的價值取向。莊表偉稱，能夠先區分紅功的開源項目和好的開源項目，開放原子須要對好的開源項目有一個界定，好比認定成功的可是不中立的開源項目是很差的，須要有價值觀的判斷。林旅強則認爲，若是基金會的目的在「孵化成功」，中立性則非成功的必要條件，若是將「產業多方共建」做爲判斷標準，中立性是必要關鍵，先肯定邏輯問題就解決了。

對此，堵俊平表示，多數基金會都比較中立，這個觀點不管是從邏輯仍是歷史上都是一直存在的。

部分條款詳解

項目代碼有完整的變動歷史

OA-CD-30

【英】The full history of the project's code is available via a source code control system, in a way that allows any released version to be recreated.

【中】應經過源代碼管理系統保留項目代碼的完整變動歷史，全部已發佈版本均可以被從新構建

TOC 副主席譚中意：

代碼的管理應該有完整的變動歷史，全部變動的版本均可以被從新構建。這實際上是兩件事情。

一是針對大公司捐獻的項目，不但願出現內部一個版本、外部一個版本，而後按期同步，但同步過程當中會把許多編程歷史丟掉，這是一種不夠開放的方式。若是採用這種方式是咱們不能接受的，咱們但願每一條代碼提交都應該有完整的變動歷史，這樣社區就知道是誰提交的，爲何提交。

二是已經發布的版本均可被從新構建，社區用戶能夠根據文檔，從零代碼開始從新構建出來。這也涉及到研發成熟度，好比社區的每一個發佈版本的二進制文件是否能夠知足被從新構建的條件。這條看似簡單，但想要作到，就須要每一個版本都實實在在按照可信的操做方式來生產，同時每次提交都要在公開可見的版本管理軟件上進行。

賢能治理

OA-CO-40

【英】The community strives to be meritocratic and over time aims to give more rights and responsibilities to contributors who add value to the project.

【中】社區要符合賢能治理的精神，隨着時間的推移，爲項目增值的貢獻者會被賦予更多的權利和責任

TOC 成員徐亮：

賢能治理，最初咱們在翻譯的時候，是沒有賢能治理這四個字的，是通過不少輪討論肯定下來的。在英文語境中，這個詞是 meritocracy，並不徹底是一個褒義詞，咱們並不以爲用 meritocracy 形容社區是徹底正確的事情，可是咱們又以爲在開源社區中，所謂的能者上氛圍是比較積極向上的，是社區可以健康運轉的主要因素。

不少開源項目中，一方面你們都是貢獻者，另外一方面你提交的功能越重要，或者對項目自己作出了更有意義的貢獻，就更有可能被現任維護人員選中去承擔更重要的角色。開放原子開源基金會也鼓勵這樣的行爲。

包括也考慮到咱們但願畢業項目的社區是相對獨立的，在畢業標準制定過程當中但願避免出現一家公司主導的狀況，咱們也但願給開放原子負責的項目推薦一個「到底如何產生獨立運起色制」的概念。最終咱們肯定下來，但願社區能以賢能治理的精神去讓項目本身不斷成長，更好地走下去。

CLA 貢獻者協議

OA-CD-40

【英】The provenance of each line of code is established via the source code control system, in a reliable way based on strong authentication of the committer. When third-party contributions are committed, commit messages provide reliable information about the code provenance.

【中】每一行代碼必須由具有強認證機制的提交者經過源代碼管理系統創建，當提交第三方貢獻時，提交備註中要包含可靠的代碼來源信息

TOC 副主席譚中意：

強認證機制能夠理解成每一個代碼提交者都必須簽署 CLA 或者 DCO，願意把本身貢獻的代碼的版權受權給到基金會的項目，這樣就能夠保證其餘開發者或用戶使用開放原子畢業的項目時，不存在太大的版權問題。

注：Contributor License Agreement 貢獻者許可協議(Contributor License Agreement，簡寫 CLA)是一套向開源項目運營主體（基金會或企業）授予知識產權權利的機制，不一樣開源項目和開源社區一般有各自的一套 CLA 協議，協議行文及受權表述相對嚴謹。CLA可分爲我的貢獻者許可協議（Individual CLA）和法人貢獻者許可協議（Corporate CLA）。

Developer’s Certificate of Origin開發者原創聲明（Developer’s Certificate of Origin，簡寫DCO）是開發者聲明貢獻爲原創及有權基於開源許可證對下游受權許可的文檔，其內容簡潔，非法律人士也易於閱讀和理解，不一樣開源許可證項目都可適用。

TOC 成員霍海濤：

這條在標準裏討論的確不少很細節，對畢業項目來講相當重要。

如今開源的項目不多有每一行代碼都是從新開發的，越大的項目越是會引入不少成熟的第三方軟件，它裏面的一些貢獻者條例涉及到是否容許受權。若是引入一些有許可證/版權問題的代碼，影響是很大的。因此成熟的社區中，參與代碼貢獻時，即使已經有了代碼，第一步必定要簽署 CLA 或者DCO，簽署完成以後你提交的代碼纔有可能被 review 或者 merge。

舉個極端的例子，若是不簽署CLA或者DCO，某個代碼提交者可能在項目成功被使用後，會由於某些代碼由他來提交的而要求使用者來找他受權。這樣對使用者來講是很不現實的，風險極大，每每會放棄使用該項目。所以，簽署了CLA/DCO以後，使用者能夠在沒有法律風險的狀況下去使用、推廣項目。

從執行來講，已經在孵化或者已經運行了一段時間的項目，CLA/DCO清理工做仍是一個比較大的工做量。基金會在運維方面，提供一個通用的 CLA/DCO模板，更好地去把流程打通，也是未來發力的一個重點。

畢業標準給誰看？

莊表偉在研討會中提出本身對畢業標準意義的理解，包含三個層面：一是對被孵化項目的指引；二是對外的展現，表明開放原子某種品質上的認證；三是放手的意思，基金會認爲該項目能夠自由健康的發展下去。他認爲，若是從這些意義出發，基金會針對這個標準應該有更多的解讀和發聲，以便更適合外界查看並理解這些標準。

針對這個問題，堵俊平表示目前這份畢業標準其實是寫給項目導師和 TOC 的，在可執行的層面。

此外，關於對畢業標準意義的理解，孫金城認爲，這不是在研究項目該怎麼作，而是從讓項目更好的角度出發，基金會能夠在這些維度上提供更好的幫助，梳理出基金會可以爲項目作哪些事情、提供哪些經驗等等。姜寧進一步解釋，畢業標準可讓孵化中和以後的項目都有明確目標，包括參與指導孵化的導師也有了明確目標，對後續業務開展有很大幫助。

主要爭議

這次採訪與研討會中，主要的爭議點是許可證。開放原子在畢業標準中僅設置了一條許可證相關條款：

Licenses and Copyright（許可證與版權）

OA-LC-10

【英】The code is released under the open source license that project used, meets the compatibility requirements and complies with OpenAtom Foundation's IPR policy

【中】代碼發佈須要知足項目所採用開源許可證的合規性/兼容性要求，且符合開放原子開源基金會的知識產權政策

該條款並未劃定許可證使用範圍，且開放原子開源基金會的知識產權政策目前在草案階段，其中符合「OSI 認證的開源許可證」都被容許使用，推薦優先使用寬鬆類許可證。姜寧認爲這是開放原子的一大特色：許可證沒有做出明確規定實際上是給項目必定的發展空間，好比 Apache 許可證可能不太適合一些雲廠商，可是咱們加了「OSI 認證」，框了一下，也是一個很大的亮點。

不過，也有許多人對此提出疑問，下面將問題與基金會TOC成員的回答列出：

OSCHINA：冷門許可證也是能夠接受的嗎？

徐亮：咱們在項目捐贈的時候，其實都會和項目討論，你爲什麼要選擇這樣一個許可證？

無論是寬鬆的仍是相對更爲限制的許可證，咱們都會探討選擇的緣由，是基於什麼考慮，是否有更好的建議，咱們並不把本身侷限於什麼樣的許可證，也不侷限推薦特別寬鬆的，咱們指望的是說，基於項目的狀況去討論，但首先要是一個開源許可證。

劉天棟：基金會是否有關於許可證兼容方面的考量？

堵俊平：一方面要遵照 OSI 的規範，知足十大原則；一方面項目捐獻以前容許存在許可證問題，可是要整理一個待辦清單，畢業時要保證兼容性。因此孵化過程當中，孵化團隊要把兼容性風險降下來。

溫銘：基金會如今支持全部的許可證使用，這會有一個問題，若是別人不敢在商業環境中使用它，可不能夠把協議改掉？

堵俊平：咱們首先不歧視任何一個 OSI 下的協議，不歧視、不反對、咱們優先推薦你們使用更寬鬆的協議，包括木蘭許可證、Apache 許可證，它們不只商業友好，並且法律風險更小。咱們認爲全部捐贈項目都要擴大社區和開發者生態。

莊表偉：其實許可證的選擇也是基金會的選擇。開放原子基金會選擇什麼？不能說我都要，我甚至以爲大家應該給出一組具體許可證。各類許可證都要可能會帶來複雜性，但挑一組就能夠避免衝突問題。

姜寧：許可證衝突實際上是開源項目許可證與項目引入第三方開源項目許可證的衝突，在這裏開源項目選什麼樣的許可證均可能引發衝突，須要具體問題具體分析。

林旅強：莊表偉講的是立場問題，很多國外基金會立場鮮明，例如 ASF 有本身的許可證。相較之下，開放原子基金會彷佛沒有特別明顯的立場？

堵俊平：Linux 基金會旗下的許可證也有寬鬆和傳染性的。開放原子誕生的定位就是包容性的開源基金會，可能承載了 Linux 的形態，也兼容了 Apache 的形態。咱們也有特點，吸納了 Linux 的商業友好特質，也吸納了 ASF 對社區的態度。

至於吸引什麼樣的項目取決也自己的生態，大數據領域不少項目使用 Apache 許可證，區塊鏈領域不少內核是 GPL。從整個理念上咱們仍是堅持包容的原則，許可證不該該是拒絕一個好項目的條件，兼容性方面若是須要法律支持，咱們後續會適當擴充一些法律資源。

對話基金會丨有機會在嵌入式 OS，區塊鏈等方向構建獨特生態

劉天棟：基金會目前有 8 個正在孵化中的項目，將來考不考慮設置沙箱？有一些項目社區還沒成熟可是能夠在沙箱裏作調整，包括稀缺資源導師也能夠在沙箱裏觀察。

堵俊平：這是看分幾個孵化階段。ASF 大體有 2 個階段，CNCF 是 3 階段，這個問題咱們也討論過。現階段根據導師資源的狀況，2 個階段是相對合理的選擇。將來項目多了，能夠考慮再加一個階段。

劉天棟：基金會考不考慮爲我的貢獻者作激勵機制？如今的貢獻者許可能是由公司支持，或是 ASF 都是志願者，因此徹底不會爲開發者付費。開放原子開源基金會是否是考慮採用適當的激勵我的開發者貢獻者的機制，讓如今企業單位成員以外，我的貢獻者也有平衡發展的機會。

堵俊平：首先企業有參與的熱情，有開源項目和很強的意願加入。從我的角度來講，如何回饋或是激勵我的開發者，若是有好的建議會去參考。

劉天棟：進入孵化器，畢業成爲頂級項目，這不是目的而是一個結果。目的不同，產出結果就會不同。國內的項目爲何要進入開放原子開源基金會，而不是國際上的基金會？

再具體一點，對於一些新創企業、項目，是否是能夠提供更多機會讓他們加入？

堵俊平：咱們並不認爲開放原子是侷限於中國的基金會，它是立足中國面向全球，從這個角度，項目加入基金會是對本土開源生態的豐富。

從項目角度，ASF 生態中的項目已大數據爲主、中間件生態強；Linux 基金會偏重內核項目；咱們認爲在新的領域會有新的機會，好比嵌入式 OS，區塊鏈等其餘方向，開放原子在這些領域可能構建一個比較好的生態。

對於孵化項目的進入，採用寬進嚴出原則，准入門檻低，由理事會推薦並找到 TOC 背書。咱們的 TOC 分佈也很普遍，一些 TOC 是以我的身份加入，知足准入標準並不難。

OSCHINA：畢業標準 OA-CO-80 規定要有必定數量的活躍提交者和至關規模的代碼提交數量和合並數量，爲何沒有具體肯定下來？

譚中意：

具體數字咱們沒有拍下來，由於 ASF 畢業條件默認數量是 3，可是咱們以爲應該大於等於 3，而不限於 3，咱們但願看到項目多樣性，項目能夠有長期可維護的狀態，但很差一下在拍成 3。

徐亮：

咱們在這裏把一些判斷項目是否足夠活躍、是否有至關規模的事情交給導師。由於每一個項目在向 TOC 陳述的時候，須要項目導師提供一個在輔導過程當中的報告，包括他們對項目的評估。咱們也但願在這個事情上賦予導師更大的權限。

咱們理解不一樣項目在軟件供應鏈中有不一樣的位置，可能底層軟件達到某種狀態後就會比較穩定，有些更加上層的應用則會持續快速往多個方向延伸，咱們但願有不一樣的項目，把部分責任交給導師，由導師提供意見給 TOC，TOC 再進行評判，因此咱們如今沒有輕易把數量拍成 3。

OSCHINA：那關於保證活躍度這項，TOC 會給到什麼幫助嗎？

霍海濤：個人想法是，TOC 主要目的仍是在孵化流程制定，就像徐亮老師說的，給導師更高的自由度，由於他們可能在這個項目上更專業、看得更細。固然 TOC 的角色，自己也會轉化爲部分項目的導師。

再說下爲何不能一刀切。由於開源項目有大有小，大的項目好比操做系統級別，組件很是多，其持續迭代能力也很強，活躍度、參與人數天然會比較多；小的項目好比一些工具類的項目，開發到必定程度以後就會成熟，活躍度天然會降下來。因此具體的活躍度作不到一刀切。