雲原生的定義和CNCF章程

雲原生的定義

Pivotal 是雲原生應用的提出者，並推出了 Pivotal Cloud Foundry 雲原生應用平臺和Spring開源Java開發框架，成爲雲原生應用架構中先驅者和探路者。

Pivotal最初的定義

早在2015年Pivotal公司的Matt Stine寫了一本叫作遷移到雲原生應用架構的小冊子，其中探討了雲原生應用架構的幾個主要特徵，符合12因素應用：

• 面向微服務架構
• 自服務敏捷架構
• 基於API的協做
• 抗脆弱性

我已於2017年翻譯了本書，詳見遷移到雲原生應用架構。

CNCF最初的定義

到了2015年Google主導成了雲原生計算基金會（CNCF），起初CNCF對雲原生（Cloud Native）的定義包含如下三個方面：

• 應用容器化
• 面向微服務架構
• 應用支持容器的編排調度

重定義-雲原生（Cloud Native）

到了2018年，而隨着僅幾年來雲原生生態的不斷狀態，全部主流雲計算供應商都加入了該基金會，且從Cloud Native Landscape中能夠看出雲原生有意蠶食原先非雲原生應用的部分。CNCF基金會中的會員以及容納的項目愈來愈多，該定義已經限制了雲原生生態的發展，CNCF爲雲原生進行了從新定位。

如下是CNCF對雲原生的從新定義（中英對照）：

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

雲原生技術幫助公司和機構在公有云、私有云和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的表明技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

這些技術可以構建容錯性好、易於管理和便於觀察的鬆耦合系統。結合可靠的自動化手段，雲原生技術可使開發者輕鬆地對系統進行頻繁並可預測的重大變動。

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

雲原生計算基金會（CNCF）致力於培育和維護一個廠商中立的開源生態系統，來推廣雲原生技術。咱們經過將最前沿的模式普惠，讓這些創新爲大衆所用。

注：該定義的中文譯本還未正式肯定，詳見Cloud Native Definition in Chinese。

CNCF章程

CNCF（雲原生計算基金會）是Linux基金會旗下的一個基金會，加入CNCF等於同時加入Linux基金會（也意味着你還要交Linux基金會的份子錢），對於想加入CNCF基金會的企業或者組織首先要作的事情就是要了解CNCF的章程（charter），就像是做爲一個國家的公民，必須遵照該國家的憲法同樣。CNCF之因此能在短短三年的時間內發展壯大到如此規模，很大程度上是與它出色的社區治理和運做模式有關。瞭解該章程能夠幫助咱們理解CNCF是如何運做的，也能夠當咱們本身進行開源項目治理時派上用場。

該章程最後更新於2018年5月15日，詳見https://www.cncf.io/about/charter/。下文中關於CNCF章程的介紹部分引用自CNCF 是如何工做的，有改動。

下圖是我根據CNCF章程繪製的組織架構圖。

圖片 - CNCF組織架構圖

1. CNCF的使命

CNCF 沒有偏離本身的主題，核心是解決技術問題：基金會的使命是建立並推進採用新的計算模式，該模式針對現代分佈式系統環境進行了優化，可以擴展至數萬個自愈式多租戶節點。

所謂的雲原生系統須具有下面這些屬性：

• 應用容器化：將軟件容器中的應用程序和進程做爲獨立的應用程序部署單元運行，並做爲實現高級別資源隔離的機制。從整體上改進開發者的體驗、促進代碼和組件重用，並且要爲雲元是國內應用簡化運維工做。
• 動態管理：由中心化的編排來進行活躍的調度和頻繁的管理，從根本上提升機器效率和資源利用率，同時下降與運維相關的成本。
• 面向微服務：與顯式描述的依賴性鬆散耦合（例如經過服務端點），能夠提升應用程序的總體敏捷性和可維護性。CNCF 將塑造技術的發展，推進應用管理的先進技術發展，並經過可靠的接口使技術無處不在，而且易於使用。

2. CNCF扮演的角色

CNCF 實際上是在開源社區的基礎上發揮着做用，應負責：

a) 項目管理

• 確保技術可用於社區而且沒有雜七雜八的影響
• 確保技術的品牌（商標和標識）獲得社區成員的關注和使用，特別強調統一的用戶體驗和高水平的應用程序兼容性

b) 促進生態系統的發展和演進

• 評估哪些技術能夠歸入雲原生計算應用的願景，鼓勵社區交付這樣的技術，以及集成它們，且要積極的推動總結進度。
• 提供一種方法來培養各個部分的通用技術標準

c) 推廣底層技術和應用定義和管理方法，途徑包括：活動和會議、營銷（SEM、直接營銷）、培訓課程和開發人員認證。

d) 經過使技術可訪問和可靠來爲社區服務

• 旨在經過對參考架構進行明肯定義的節奏，爲每一個組成部分提供徹底集成和合格的構建。

3. CNCF的價值觀

CNCF 會極力遵循如下一些原則：

1. 快速賽過磨嘰，基金會的初衷之一就是讓項目快速的發展，從而支持用戶可以積極的使用。
2. 開放！ CNCF 是以開放和高度透明爲最高準則的，並且是獨立於任何的其它團體進行運做的。CNCF根據貢獻的內容和優勢接受全部的貢獻者，且遵循開源的價值觀，CNCF輸出的技術是可讓全部人使用和受益的，技術社區及其決策應保持高度透明。
3. 公平：CNCF 會極力避免那些很差的影響、不良行爲、以及「按需付費」的決策。
4. 強大的技術身份：CNCF 會實現並保持高度的自身技術認同，並將之同步到全部的共享項目中。
5. 清晰的邊界：CNCF 制定明確的目標，並在某些狀況下，要肯定什麼不是基金會的目標，並會幫助整個生態系統的運轉，讓人們理解新創新的重點所在。
6. 可擴展：可以支持從小型開發人員中心環境到企業和服務提供商規模的全部部署規模。這意味着在某些部署中可能不會部署某些可選組件，但整體設計和體系結構仍應適用。
7. 平臺中立：CNCF 所開發的項目並不針對某個特定平臺，而是旨在支持各類體系結構和操做系統。

4. 會員制

CNCF中的會員包括白金、金牌、銀牌、最終用戶、學術和非贏利成員等級別，不一樣級別的會員在理事會中的投票權不一樣。

a) 白金會員：在CNCF理事會中任命1名錶明，在理事會的每一個次級委員會和活動中任命1名有投票權的表明，在網站能夠突出顯示；若是也是終端用戶成員將繼承終端用戶成員的全部權利

b) 金牌會員：基金會中每有5個金牌會員，該級別的會員就能夠任命1名錶明，最多任命3個；若是也是終端用戶成員將繼承終端用戶成員的全部權利

c) 銀牌會員：基金會中每有10個銀牌會員，該級別的會員就能夠任命1名錶明，最多任命3個；若是也是終端用戶成員將繼承終端用戶成員的全部權利

d) 終端用戶：參加終端用戶諮詢社區；向終端用戶技術諮詢委員會中提名1名錶明

e) 學術和非贏利會員：學術和非營利會員分別限於學術和非營利機構，須要理事會批准。學術成員和非營利成員有權將其組織認定爲支持CNCF使命的成員以及理事會肯定的任何其餘權利或利益。

5. 理事會

a) CNCF理事會負責市場營銷、業務監督和預算審批，不負責技術方面，除了與TOC配合肯定CNCF工做範圍、完成時間表a)、更新CNCF網站

b) 負責平常事務

1. 與TOC協商CNCF的總體範圍
2. 商標和版權保護
3. 市場營銷、佈道和生態系統建設
4. 建立和執行品牌承諾項目，若是須要的話
5. 監督運營，業務發展；
6. 募資和財務管理

c) 理事會投票成員由會員表明和社區表明組成：

1. 成員表明包括：
   • 每名白金會員任命1名錶明
   • 黃金和銀牌成員當選表明
2. 技術社區表明包括：
   • 技術監督委員會主席
   • 根據當時在任的理事會批准的程序從CNCF項目中選出兩名提交者。
3. 理事會可能會以白金會員比例的價格擴展白金會員資格，對年收入低於5000萬美圓的創業公司進行長達5年的逐年審計，這些公司被視爲理事會的戰略技術貢獻者。
4. 只有來自一組關聯公司的人員能夠擔任會員表明。只有來自一組關聯公司的人員能夠擔任技術社區表明。

d) 職責

1. 批准預算，指導將全部收入來源籌集的資金用於技術、市場或社區投資，以推進 CNCF 基金的使命；
2. 選舉理事會主席主持會議，批准預算批准的支出並管理平常運做；
3. 對理事會的決定或事項進行投票；
4. 界定和執行基金會的知識產權（版權，專利或商標）政策；
5. 經過活動、新聞和分析師宣傳、網絡、社交媒體以及其餘營銷活動進行直接營銷和佈道；
6. 監督運營，業務發展；
7. 創建並監督爲推進CNCF的使命而建立的任何委員會；
8. 根據CNCF要求（可能包括認證測試）創建並執行品牌合規計劃（若有），以使用TOC創建的品牌標誌；
9. 採用商標使用準則或政策；
10. 提供總體財務管理。

e) 基金會的收入用途

1. 市場營銷，用戶擴展CNCF中的項目的採用
2. 關鍵設施建設、運行和管理項目的基礎設施
3. 促進基於容器的計算使用CNCF中的項目實現

6. 技術監督委員會（TOC）

a) 要求

CNCF 技術監督委員會，爲了保持中立，則達成了如下共識：

1. 定義和維護CNCF的技術願景。
2. 批准由理事會制定的CNCF範圍內的新項目，併爲項目建立一個概念架構。
3. 糾正項目的發展方向，決策刪除或存檔項目。
4. 接受最終用戶委員會的反饋並反映在項目中。
5. 在科學管理的狀況下調整組件的接口（在代碼標準化以前實現參考）
6. 定義在CNCF項目中實施的經常使用作法（若是有的話）。

b) 技術監督委員會的構成

1. TOC最多由9名成員組成。
2. 選出的TOC成員將涵蓋關鍵的技術領域：容器技術、操做系統、技術運維、分佈式系統、用戶級應用程序設計等。
3. 理事會將選舉6名TOC成員，最終用戶TAB將選出1名TOC成員，最初的7名TOC成員應另選兩名TOC成員。
4. 若是超過兩名TOC成員來自同一組關聯公司，不管是在選舉時仍是來自後來的工做變動，他們將共同決定誰應該下臺，或若是沒有協商的依據，則應抽籤決定。

c) 運營模式

1. TOC 會選舉出TOC的主席來，此角色主要負責 TOC 的議程和召集會議。
2. TOC 每一個季度會面對面討論重要的熱點問題。
3. TOC 可能會根據須要開會討論新出現的問題。 TOC審覈可能會提出如下問題：
   • 任何的 TOC 成員
   • 任何的理事會成員
   • 創建的CNCF項目的維護者或頂級項目負責人
   • CNCF 執行董事
   • 最終用戶技術諮詢委員會得到多數票
4. 保持透明：TOC會議、郵件列表、以及會議記錄等均是公開可訪問的。
5. 簡單的TOC問題能夠經過簡短的討論和簡單的多數表決來解決。TOC討論可經過電子郵件或TOC會議進行。
6. 在對意見和可選虛擬討論/辯論選項進行審查後，尋求共識並在必要時進行投票。
7. 目的是讓TOC在TOC和社區內尋找達成共識的途徑。知足法定人數要求的會議的TOC決定應以超過TOC成員出席率的50％的方式經過。
8. TOC會議須要TOC總人數的三分之二法定人數進行表決或做出任何決定。若是TOC會議未能達到法定人數要求，能夠進行討論，但不該有任何投票或決定。
9. TOC決定能夠在沒有會議的狀況下以電子方式提出，但要經過表決則須要多少票數才能達到會議法定人數。在電子投票中，若是任何兩名TOC成員要求召開會議討論決定，則電子投票結束時無效，而且在會議結束後能夠啓動新的投票，以討論決定已經完成。

d) 提名標準

得到 TOC 提名的開源貢獻者應該具有下面條件：

1. 承諾有足夠的可用可用時間參與CNCF TOC的活動，包括在CNCF成立時至關早期的投入，而後需持續投入時間，並且在季度的 TOC 會議以前要進行充分的準備和審查事宜。
2. 在CNCF範圍內展現了高水準的專業經驗。
3. 證實其有資格可以得到額外的工做人員或社區成員協助其在 TOC 的工做。
4. 在討論中保持中立，並提出CNCF的目標和成功與公司目標或CNCF中的任何特定項目保持平衡。

e) TOC成員提名和選舉程序

1. TOC由9位TOC成員組成：由理事會選出的6位，由最終用戶TAB選出的1位和由最初的7位TOC成員選出的2位。
2. 提名：每一個有資格提名TOC成員的我的（實體或成員）能夠提名至多2名技術表明（來自供應商、最終用戶或任何其餘領域），其中至多一個可能來自其各自公司。被提名者必須提早贊成加入到候選人名單中。
   • 最初的7名TOC成員（理事會選出的6名成員加上由最終用戶TAB選出的1名成員）應使用提名程序提名並選舉2名TOC成員。
   • 提名者須要提供最多一頁紙的介紹，其中包括被提名者的姓名，聯繫信息和支持性陳述，肯定了在CNCF領域提名的經驗。
   • 理事會、最終用戶TAB和TOC應肯定提名、投票和關於TOC選舉提名和選舉過程的任何其餘細節的時間表和日期。
   • 評估期間最少保留14個日曆日，TOC 提名者能夠聯繫和/或評估候選人。
3. 選舉：評估期結束後，理事會、最終用戶標籤和最初的7位TOC成員應分別對每位被候選人進行表決。有效投票須要知足會議法定人數所需的選票數量。每名被候選人均須要支持超過50％的投票人數，以確認被提名者符合資格標準。以多數票經過的候選人應爲合格的 TOC 成員。
4. 若是合格的被提名者的人數等於或少於可選 TOC 席位的數量，則此被提名者應在提名期結束後得到批准。若是有更多的合格被候選人比理事會，最終用戶TAB或TOC可選的開放TOC席位多，那麼該組應經過Condorcet投票選出TOC成員。Condorcet投票應經過康奈爾在線服務（http://civs.cs.cornell.edu/）使用Condorcet-IRV方法運行。
5. 若是理事會，最終用戶TAB或TOC可供選舉的公開TOC席位的合格被候選人數較少，該小組將啓動另外一輪提名，每名成員或我的有資格提名至多提名1名候選人。

f) 約束條件

1. TOC 的成員任期爲兩年，來自理事會選舉的最初六名當選TOC成員的任期爲3年。由最終用戶TAB和TOC選出的TOC成員的初始任期爲2年。
2. TOC成員可能會被其餘TOC成員的三分之二投票撤除，受影響的我的不能參加投票。
3. 任何TOC成員連續3次連續會議都將被自動暫停投票資格，直至連續參加兩次會議。爲避免疑義，暫停的TOC成員有資格在連續第二次會議中投票。
4. TOC章程、模式、方法、組成等能夠由整個理事會的三分之二票經過修改。
5. TOC議程將由TOC制定。可是，預計最初的TOC討論和決定將包括：
   • 評估包含在CNCF中的技術
   • 肯定新技術歸入CNCF的接受標準
   • 定義批准做爲標準API的貢獻技術的流程
   • 找出須要進一步調查的直接差距

7. 最終用戶社區

a) CNCF的最終用戶成員有權協調和推進CNCF用戶做爲CNCF設計的消費者的重要活動。任何做爲最終用戶的成員或非成員，每一個「最終用戶參與者」都可被邀請參加。最終用戶參與者將幫助向技術諮詢委員會和CNCF社區就與用戶有關的主題提供意見。

b) 最終用戶技術諮詢委員會是由最終用戶社區成員選舉所產生。

c) 最終用戶社區成員將得到CNCF執行董事的批准，或者 CNCF 執行董事缺席的話，則由 Linux 基金會執行董事來批准。

8. 最終用戶技術諮詢委員會（「最終用戶 TAB」）

a) 構成：最終用戶TAB應由來自最終用戶參與者的7名錶明加上TOC的1名成員組成，以便於從最終用戶TAB到TOC的晉級。

b) 選舉：爲了鼓勵最終用戶參與CNCF，前7名最終用戶會員能夠委任1名錶明參加初始最終用戶TAB，並將CNCF董事分配給任何最終用戶參與者的任何剩餘席位。在第一年以後，全部最終用戶參與者能夠提名1名錶明而且最終用戶社區應該投票選擇使用當前最終用戶 TAB 批准流程的最終用戶TAB成員。

c) 通過三分之二投票經過後最終用戶 TAB 能夠更改最終用戶社區的大小，前提是至少有7名可能的表明。

d) 最終用戶表明應當基於業務和技術敏銳度提名。候選人應該具有建設和運營體現CNCF原則的基礎設施和應用方面的重要實踐經驗。

e) 最終用戶 TAB 將討論和推動主題，重點是找出TOC和CNCF開發者社區的差距並提出優先事項。

f) 也會側重於主動推動最終用戶關心的話題，促進CNCF的市場採用，爲最終用戶舉辦會議或向理事會提供諮詢。

g) 若是最終用戶 TAB 有意願的話，它能夠批准小組委員會特別興趣小組 （「SIG」）來解決行業或專業話題。

h) 最終用戶 TAB 是技術監督委員會的主要輸入方，應與技術監督委員會的其餘輸入方和反饋一塊兒做出決策和計劃。這些建議只是建議性的，在任什麼時候候，最終用戶TAB的建議都不能用於命令或指導任何TOC或項目參與者採起任何行動或結果。

i) 爲促進與TOC的雙邊互動，最終用戶技術諮詢委員會應選出1名TOC表明。最終用戶 TAB 可邀請任何人蔘加最終用戶會議、SIG或其餘討論。

9. CNCF項目

一般狀況下，是由CNCF的成員公司、開源社區的成員將項目先是帶到CNCF 的技術監督委員會來進行討論，而後決定是否被CNCF接納。要貢獻給CNCF的項目必須是通過技術監督委員會制定的標準的，以後固然還要通過理事會的批准。CNCF 的目標是但願捐贈給CNCF的項目和CNCF已有的項目在必定程度上是有關聯的，並且是可集成的。

和CNCF 關聯起來有如下三種方法：

1. 已經在CNCF的納管之下，畢竟CNCF是中立的，致力於成爲你們的協做的歸屬地。

   a) 項目的方方面面都交由CNCF來打理

   b) 項目是由CNCF 來進行市場推廣的

   c) 項目是解決雲原生計算問題的核心組件，如Kubernetes、Mesos、etcd等等

2. 經過API或規範與CNCF相關聯XM

   a) 包括CNCF可能提供或啓用多個選項的組件

   b) 該項目被稱爲CNCF集成的一個組成部分，而不是由CNCF主辦的項目

   c) 集成和合規性由API或規範定義

   d) 項目或組件的開發是由上游社區所開發，並且保持必定的活躍度

3. CNCF 使用到的

   a) 項目或組件徹底根據OSI批准的開源許可證進行受權，而且管理良好，並在CNCF中被用做組件。

   b) 項目並無由CNCF 來進行市場推廣

   c) 項目或組件的開發是由上游社區所開發，並且保持必定的活躍度

現有的開源項目應該繼續保持其現有的技術治理結構，以保持凝聚力和速度。可是由技術監督委員會批准以後，則會適當的進行一些適應。

應根據我的的水平和貢獻期限在項目間創建一個達到提交者地位的標準協議。由於提交者是維護者的選拔人才池，有了必定程度的貢獻，且通過同行們的承認，提交者就可晉升爲維護者。

CNCF啓動的新開源項目應完成TOC採納的項目建議模板，並由TOC批准歸入CNCF。TOC成員應有充足的時間討論和審查新的項目建議書。新的項目建議書應包括項目中的角色細節，爲項目提出的治理，並肯定與CNCF的角色和價值觀保持一致。

10. 市場委員會

a) 構成，市場委員會將向全部成員開放參與，應選舉市場委員會主席制定會議議程，進行通常的討論，並幫助委員會實現其目標。市場委員會應儘量尋求共識。在市場委員會中沒法達成共識的任何問題應提交給理事會。

b) 職責，市場委員會表明理事會負責設計，開發和執行相關的市場工做。

c) 若是市場委員會變得太大而沒法有效運做，市場委員會能夠選擇選舉市場董事，並將決策權委託給市場董事。

11. 知識產權政策

a) 任何加入到CNCF的項目都必須將其擁有的商標和徽標資產轉讓給Linux基金會的全部權。

b) 每一個項目應肯定是否須要使用經批准的CNCF CLA。對於選擇使用CLA的項目，全部代碼貢獻者將承擔Apache貢獻者許可協議中規定的義務，只有在必要時才做出修改，以肯定CNCF是捐贈的接受者，而且應由理事會批准。請參閱 https://github.com/cncf/cla 上提供的CNCF參與者許可協議。

c) 全部向CNCF提交的新入站代碼應當（i）附有開發者原始證書籤名（http://developercertificate.org和（ii）根據Apache許可證2.0版（可從http://developercertificate.org和http://www.apache.org/licenses/LICENSE-2.0 得到）該許可證除了而且不得取代根據上文（b）規定的供款許可協議所承擔的義務。

d) 全部出站代碼將在Apache許可證2.0版下提供。

e) 全部評估歸入CNCF的項目都必須得到OSI批准的開源許可證的徹底許可，若是CNCF中包含的項目的許可證不是Apache許可證2.0版，則須要得到理事會的批准。

f) 全部文檔將由CNCF根據知識共享署名4.0國際許可證來提供。

g) 若是須要替代入站或出站許可證以符合槓桿式開放源代碼項目的許可證或爲實現CNCF的使命而須要其餘許可證，理事會能夠批准使用替代許可證 對於例外狀況下的接受或提供的項目捐贈。

12. 反托拉斯指南

a) 全部成員均應遵照http://www.linuxfoundation.org/antitrust-policy上提供的Linux基金會反托拉斯政策中規定的Linux基金會的要求。

b) 全部成員都應鼓勵任何可以知足成員要求的組織的公開參與，而不論其競爭利益如何。換言之，理事會不該根據除用於全部成員的標準，要求或緣由以外的任何標準，要求或理由尋求排除成員。

13. 行爲準則

全部參與者都須贊成遵照 Linux基金會行爲準則。 TSC能夠投票經過本身的CNCF行爲準則。

14. 關聯公司

a) 定義：

1. 「子公司」是指會員直接或間接擁有所涉實體超過百分之五十有投票權的證券或會員權益的任何實體；
2. 「關聯公司」是指任何控制或由成員控制的實體，或者與成員一塊兒受第三方共同控制的實體，在全部狀況下，直接或間接擁有多於全部權的控制權；
3. 「關聯公司」是指各成員的關聯公司。

b) 只有執行了參與協議的法人實體及其子公司纔有權享有該會員的權利和特權；但條件是該成員及其子公司應做爲單一成員共同對待。

c) 只有一名屬於一組關聯公司的成員有權一次性任命或提名理事會表明參加類別選舉。

d) 若是會員自己是會員或贊助商的基金會，聯盟，開源項目，會員組織，用戶組或其餘實體，那麼授予該成員的權利和特權只能擴展到該成員的員工表明，而不能擴展到其成員或發起人，除非理事會不時在特定狀況下另行批准。

e) 會員資格不得轉讓，不可轉讓、也不能轉讓，除非現有會員將其現有的會員利益和義務轉讓給其大部分業務和/或資產的繼任者，不管是經過合併，出售仍是其餘方式；只要受讓人贊成遵照 CNCF 的章程以及Linux Foundation成員所需的章程和政策。

15. 預算

a) 理事會應批准年度預算，毫不會承諾超出籌集的資金。預算應與Linux基金會的非營利性使命相一致。

b) Linux基金會應按期報告預算支出。

16. 常規和管理費用

a) Linux基金會應保管任何費用，資金和其餘現金收據。

b) 通常和行政（G＆A）費用將用於籌集資金以支付財務、會計和運營費用。 G＆A費用應等於CNCF首期總收入1,000,000美圓的9％以及CNCF總收入超過1,000,000美圓的6％。

17. 通常規則和操做

參與CNCF 應作到：

a) 展現與開源項目開發人員社區進行協調的計劃和方法，包括關於表明社區的品牌、徽標和其它標誌性的主題；

b) 以專業的方式體現維持社區的凝聚力爲目標，同時還要保持Linux基金會在開放源代碼軟件社區的善意和尊重；

c) 尊重全部商標全部人的權利，包括任何品牌和使用準則；

d) 參與Linux基金會的全部新聞和分析師關係活動；

e) 根據要求，向Linux基金會提供關於項目參與的信息，包括參加項目贊助活動的信息；

f) 直接參與到基金會旗下的任何站點。

g) 根據理事會批准的規則和程序進行運營，前提是這些規則和程序不得與Linux基金會的宗旨和政策不一致，而且不得損害Linux基金會。

18. 修正案

本章程能夠經過全部理事會成員的三分之二票數（不包括棄權）進行修改，前提是任何此類修改不得與Linux基金會的目的或政策不一致，而且不得對Linux基金會產生不利影響。

時間表A：提出CNCF範圍願景

CNCF背後的首要目標是支持和加速「雲原生計算」的採用。如下內容是初步範圍，旨在闡明CNCF將努力實施的「雲原生計算」的核心概念。該初始範圍應成爲發佈在CNCF網站上的文檔。

CNCF社區堅信雲原生計算包含三個核心屬性：

• 容器化包裝和分發
• 動態調度
• 面向微服務

注：關於雲原生的定義正在從新設定中，已經與上述不一樣了。

雲原生計算系統支持基於這些核心屬性的計算，幷包含如下理想：

• 開放性和可擴展性
• 在標準化子系統的邊界處定義良好的API
• 應用程序生命週期管理的最小障礙

圖片 - 雲原生的理想分層架構

由於上述時間表已經有些過期了，CNCF成立已經有三年時間了，正在規劃新的方案。

參考

• CNCF 是如何工做的
• https://www.cncf.io/about/charter/