如何管理成功的 InnerSource 程式
在此，我們將討論如何設計 InnerSource 程式，以在任何軟體開發組織內享受開放原始碼模式的最佳優點。
什麼是 InnerSource？
任何人都可以自由使用、修改及共用開放原始碼軟體。 使用開放原始碼軟體，任何人都可以檢視、修改及發佈專案，並考慮共用程式碼會導致更可靠、更可靠的軟體。
InnerSource 是為具備有限對象的專案套用開放原始碼模式的做法。 例如，某家公司可能會建立反映一般開放原始碼專案結構的 InnerSource 程式，但其只能由該公司的員工存取。 實際上，此為貴公司防火牆後方的開放原始碼程式。
InnerSource 優點
InnerSource 程式可以提供許多傳統封閉式來源模型無法提供的優點。
首先，其能「鼓勵透明度」。 透過存取其他公司專案的原始程式碼，可協助開發人員在處理自己的專案時更具生產力。 他們可以了解不同小組處理類似其所面對問題的方式，且通常會發現可以重複使用的程式碼和其他資產。 存取小組問題、提取要求及專案計劃也能提供更佳的資料，使他們可以了解專案的速度和方向。
接下來，其能「減少摩擦」。 假設取用者小組相依於不同小組所擁有專案的錯誤修正或新功能。 在 InnerSource 計畫中，他們有一個通道，可以透過此通道來提議所需的變更。 如果那些變更因任何原因而無法合併，則取用者小組可以選擇為專案建立分支來滿足其需求。
最後，其能「將做法標準化」。 開發組織經常會面臨的其中一個挑戰，是不同小組在作業方式上通常會有所差異。 建置 InnerSource 程式是採用標準慣例的絕佳機會；即使每一個開發小組並不會使用完全相同的做法，也能夠利用此標準慣例。 例如，兩個小組之間在接受貢獻上可能會偏好使用不同的流程。 藉由將他們溝通不同程序的方式標準化，能使人們更容易參與任何一個小組。
這些範例只是 InnerSource 程式所提供的幾個優點。 若要深入了解，請參閱 InnerSource 簡介 \(英文\)。
在 GitHub 上設定 InnerSource 程式
設定存放庫可見度和權限
您可以將 GitHub 存放庫設定為三個層級的可見度。 當不符合可見度需求的使用者嘗試存取存放庫時，將會看見「找不到」頁面。 層級為：
- [Public] \(公用\) 存放庫，所有人都可以看見。 請針對確實為開放原始碼，並同時可讓組織內部及外部人員存取的專案使用此可見度。
- [Internal] \(內部\) 存放庫，只有擁有存放庫之組織的成員才可以看見。 請針對 InnerSource 專案使用此可見度。
- [Private] \(私人\) 存放庫，只有其擁有者和擁有者所新增的任何小組或個人才可以看見。 請針對只應由特定使用者與群組存取的專案使用此可見度。
在您建立存放庫可見度之後，即可根據個人或小組設定權限。 有五個權限層級：
- 建議將 [Read] \(讀取\) 層級用於想要檢視或討論專案的非程式碼參與者。
- [Triage] \(分級\) 層級，建議用於需要在不具寫入權限的情況下主動管理問題和提取要求的參與者。
- [Write] \(寫入\) 層級，建議用於會主動推送至專案的參與者。
- [Maintain] \(維護\) 層級，建議用於需要在無法存取敏感性或破壞性動作的情況下管理存放庫的專案經理。
- [Admin] \(系統管理\) 層級，建議用於需要專案完整存取權 (包括如管理安全性或刪除存放庫的敏感性和破壞性動作) 的人員。
深入了解依層級分類的存放庫存取權限 \(英文\)。
建立可探索的存放庫
隨著 InnerSource 程式持續成長，存放庫的數目也很可能會大幅擴大。 雖然讓這些資產可供組織使用具有許多好處，但可能會越來越難有效率地找到內容。 為了主動解決此問題，最佳做法是讓小組考慮如何讓其他人更容易尋找及使用其存放庫。
幾個最佳做法包括：
- 使用描述性的存放庫名稱，例如
warehouse-api或supply-chain-web。 - 包含簡短的描述。 透過一、兩句話應該便足以讓潛在使用者知道該專案是否符合其需求。
- 授權您的存放庫，讓客戶知道如何使用、變更及散發軟體。
- 在存放庫中包含
README.md檔案。 GitHub 會使用此檔案，作為人們瀏覽該存放庫時的登陸頁面。
新增讀我檔案
讀我檔案會傳達專案的期望，並協助您管理貢獻。 讀我檔案可以：
- 清楚表達專案的用途和願景，來讓潛在取用者能夠了解其是否符合他們的需求。
- 提供視覺輔助工具 (例如螢幕擷取畫面或程式碼範例) 來說明專案的運作方式。
- 包含生產或示範版本應用程式的連結以供檢閱。
- 設定預期的先決條件與部署程序。
- 包含您相依之專案的參考。 這些參考是推廣他人工作的好方法。
- 使用 Markdown 來引導讀者閱讀適當格式化的內容。
如果您將讀我檔案放在存放庫的根目錄或隱藏的 .github 或 docs 目錄中，GitHub 會辨識並自動將讀我檔案呈現給存放庫訪客。 如果存放庫包含多個讀我檔案，則會依下列順序從位置選擇顯示的檔案：.github 目錄，然後是存放庫的根目錄，最後選擇 docs 目錄。
請查看一些絕佳的讀我檔案範例 \(英文\)。
在專案啟動後，請使用電子郵件和其他網路通道來加以宣傳。 透過處達適當的對象，可能可以使專案參與度大幅提升。
在 GitHub 上管理專案
隨著專案開始具有吸引力，可能會需要進行許多工作來管理大量湧入的使用者和貢獻。 根據專案的不同，光是管理專案參與者的期望便可能需要花費大量功夫。
為了主動解決此問題，GitHub 會在存放庫的根目錄 (或是 /docs 或 /.github) 中尋找 CONTRIBUTING.md 檔案。 請使用此檔案來說明專案的貢獻原則。 確切的詳細資料可能會有所不同，但最好讓潛在參與者知道專案所依循的慣例。 例如，小組在何處尋找提取要求、錯誤報告要求什麼詳細資料等等。
如果存在 CONTRIBUTING.md，GitHub 會在使用者建立問題或提取要求時顯示其連結，以鼓勵他們加以遵循。
請查看一些絕佳的 CONTRIBUTING.md 範例 \(英文\)
此外，請考慮將 CODEOWNERS 檔案新增至存放庫，以定義負責檢閱程式碼修改的個人或小組。
建立問題和提取要求範本
GitHub 支援適用於新問題和提取要求的入門範本。 使用這些範本來提供新建立問題或提取要求的初始描述文字。
例如，如果您的專案有 .github/ISSUE_TEMPLATE.md，每當使用者起始建立問題的程序時，系統便會向他們顯示此內容。 他們不必持續參考來自 CONTRIBUTING.md 的必要詳細資料，而只需要使用範本文字，以類似表單的方式填寫問題。
提取要求也相同，只是路徑會是 .github/PULL_REQUEST_TEMPLATE.md。
請查看一些絕佳的 GitHub 問題和提取要求範本 \(英文\)。
定義工作流程
針對鼓勵外部貢獻的專案，請務必指定專案所遵循的工作流程。 工作流程應包括在何處以及如何使用分支來處理錯誤和功能的詳細資料。 這也應該包含應該如何開啟提取要求，以及存放庫小組以外的人員在推送程式碼之前應該知道的任何其他詳細資料。 如果您對工作流程尚未有任何想法，您應該考慮 GitHub 流程 \(英文\)。
您應該傳達管理版本及部署的策略。 這部分的工作流程會影響日常的分支及合併，因此請務必將其傳達給參與者。 深入了解其與您 Git 分支策略的關聯性。
測量程式是否成功
所有採用 InnerSource 的小組都應該思考需要追蹤哪些計量，才能測量程式是否成功。 雖然傳統的計量 (例如「上市時間」及「回報的錯誤 (Bug) 數」) 仍然適用，其並不一定可以說明透過 InnerSource 所達成的優點。
相反地，請考慮新增能顯示因外部參與而提升專案品質的計量。 存放庫是否從外部來源接收到能修正錯誤 (Bug) 和新增功能的提取要求？ 針對專案及其未來的討論中是否有積極的參與者？ 程式是否促進 InnerSource 的擴充，並在組織其他地方驅動優點？
簡單來說，計量並不是件簡單的工作，特別是在測量個人和小組貢獻的價值和影響上。 如果誤用，計量可能會影響文化及現有程序，並降低集體對組織或領導小組所抱持的情緒。 思考測量 InnerSource 採用時，請考慮下列計量指引：
- 測量程序，而非輸出
- 程式碼檢閱周轉時間
- 提取要求大小
- 進行中的工作
- 提出所需花費的時間
- 針對目標進行測量，而非絕對值
- 測量小組，而非個人
- 專案中唯一參與者的數目
- 重複使用程式碼的專案數目
- 跨小組 @mentions 的數目
在這些 InnerSource 案例研究 \(英文\) 中了解其他人已享有的成就。