在開源生態系中，專案的維護與發展往往涉及多個利益相關者，其中社區與企業的協作模式尤為關鍵。以 Kubernetes 為例，其作為 CNCF（Cloud Native Computing Foundation）的核心技術，涵蓋自動擴展（autoscaling）、雲端供應商（cloud provider）等核心功能，但子專案（subproject）的維護責任與功能歸屬常引發社區與企業之間的衝突。本文探討此類衝突的成因、技術細節與解決策略，並分析如何透過明確的權責界定與協作機制，確保專案的長期可持續發展。
雲端控制器管理器（CCM）與負載平衡控制器的分工
Kubernetes 的雲端供應商功能由 CCM（Cloud Controller Manager）實現，而負載平衡器的管理則分散於不同子專案。以 AWS 為例，其負載平衡功能分為兩部分：
此分工導致功能歸屬混亂，例如 Red Hat 集團誤將需求提交至 Cloud Provider AWS，因文件未明確標註「此專案為快照檔」，造成維護團隊與社區的溝通障礙。
功能定位與遷移路徑
現有功能（如網路負載平衡器的「安全群組」功能）未實現於 CCM，需透過負載平衡控制器的註解支援。然而，缺乏明確的遷移方案，導致用戶需重新建立服務（recreate service）才能使用新功能，增加技術門檻。
CI/CD 工具的複雜性
新 Contributor 面臨工具鏈設置困難，需熟悉 Prow、Test Infra、Test Grid 等系統，學習曲線陡峭。建議社區提供清晰的工具使用指南與入門流程，並建立「Drive-by PR」機制，降低參與門檻。
測試基礎設施的整合
測試結果需整合多個系統（如 Prow、Dashboard、日誌）才能理解，社區需提供系統化的入門資源（如 CubeCon 講座），以提升協作效率。
Google 文檔權限問題
Cluster API SIG 的議程文件因公司帳號權限變更而遺失歷史紀錄，顯示缺乏備份計畫與共享儲存空間。建議建立災難備援機制，並明確文件管理責任，避免單一帳號依賴。
文件標準化與透明度
社區需定期審查文件完整性與可訪問性，並建立統一的文件格式與工具使用指南，確保資訊流通無礙。
企業主導專案的挑戰
當專案由特定公司主導時，社區需平衡企業需求（如功能優先級）與社區參與（如開放貢獻）。核心問題在於如何避免「企業控制」導致社區參與受阻，並確保功能設計符合廣泛用戶需求。
社區驅動的維護模式
需建立明確的維護流程與社區參與機制，避免「企業主導」與「社區主導」的權力衝突。例如，Red Hat 等公司可聘請工程師參與 CCM 維護，或與 AWS 合作解決功能缺失。
CI/CD 流程的社區化
原 AWS 帳戶的 CI/CD 流程需轉移至社區控制的 AWS 帳戶，確保透明度。社群成員可直接訪問日誌並透過 k.io 提交問題，禁止公司內部人員直接介入後臺操作。
功能整合與遷移策略
社群需明確哪些功能應回歸 CCM（如安全群組），並設計遷移工具與測試案例，協助用戶平滑過渡。避免將所有負載平衡功能移植至 CCM，應聚焦解決當前問題。
社區參與與文化建設
鼓勵新成員參與維護與貢獻（如提交 PR），建立開放的溝通機制，避免「封閉式」維護。例如，Red Hat 聘請工程師參與 CCM 維護，並與社群協同解決問題。
Kubernetes 社區與企業的協作挑戰，核心在於如何平衡功能維護、工具鏈標準化與社區參與。需透過明確的權責界定、透明的決策流程與持續的社區支持，才能確保專案長期可持續發展。未來，社區需建立「共治」機制，避免單一公司主導，並透過社區化 CI/CD、文件更新與遷移指引，提升項目健康度。