企業開源指南：啟動一個開源專案

最大限度最佳化組織中執行開源計劃或啟動開源專案的實踐。這些資源由 Linux 基金會與 TODO Group 合作開發，代表了我們的員工、專案和成員的經驗。

• 英文：https://todogroup.org/guides/starting/
• 中文：https://linuxfoundation.cn/resources/open-source-guides/starting-open-source-project/
• GitHub：https://github.com/todogroup/todogroup.github.io/blob/master/content/en/guides/starting.md

一旦公司參與開源社群已有足夠長的時間來建立聲譽，它就能夠釋出自己的開源專案。在開源參與的這個階段，公司可以從開放式協作中獲得最大的好處。您可以開放可用於社群的專有專案的原始碼。另一種常見的途徑是從頭開始建立新的開源專案並在一開始就從外部開發人員之間的協作中受益。

本指南旨在幫助已經精通開源的企業瞭解他們啟動自己的開源專案所需要了解的內容。我們將帶領您經歷這個過程，從決定開源的內容，到預算和法律考慮等等。建立開源專案的道路可能不是本就有的，但谷歌、IBM、臉書、推特和微軟等主要企業已經為您開闢了道路。按照本指南所提供的專題的且有用的建議，您將走上啟動開源專案之路。

本指南的撰稿人

• Christine Abernathy - Facebook 開源開發者 & 倡導者
• Ibrahim Haddad - 三星美國研究院研發副總裁兼開源小組負責人
• Guy Martin - Autodesk 開源負責人
• John Mertic - 基金會專案管理負責人
• Jared Smith - Capital One 開源社群經理

為何建立一個開源專案

貴公司啟動一個開源專案有很多原因。您可能旨在加快創新速度，更快實現上市，收集新想法，實現互通性或事實上的標準，招募有才能的開發人員，並收集不同的觀點和貢獻來生成更好的程式碼和更好的產品。

這些好處都可以透過使用並貢獻於在貴公司以外建立和管理的開源專案來實現。但是一個全面的開源戰略通常還包括建立並啟動您自己的開源專案。

啟動專案或釋出已有的專案作為對社群的開放原始碼可以增強奉獻意識，這樣可以進一步提高公司在開源領域的聲譽，並使公司對開源開發人員更具吸引力，且對其所貢獻的開源專案更具影響力。將您的程式碼庫作為討論的起點可以帶來其他優勢，因為您期待參與一個由合作伙伴、供應商和使用者組成的外部生態系統。

透過開放自己的程式碼和開發實踐以供外部使用和貢獻，您真正參與了開放式創新並使您的業務對於開源的使用達到了最佳效果。根據開源許可證釋出的程式碼允許任何人貢獻、檢查、修改和改進它。這種協作式的開發方式是如今事實上的開發軟體方式，也是技術創新的成熟引擎。

無論您的主要任務是金融服務，提供醫療服務，運營卡車隊，在商店或網上銷售零售商品，向乘客和航空公司乘客提供交通工具，修建道路和橋樑，或數以千計的其他專業，這都是事實。雖然這些企業當然希望保留對向客戶提供的價值至關重要的應用程式和技術，但存在無數的具有依賴性的程式碼和軟體，而且這些程式碼和軟體對組織而言並不具有高價值。將這些技術作為一個專案對外部貢獻開放可以為發展與加強這些程式碼創造新的可能性和機會。

“無論我們在公司內部聘用多少聰明人，在公司外部總是會有更聰明的人。我們發現開源並與外界分享我們的程式碼是值得的，這樣可以換取外部擁有專業知識並願意與我們分享的人們的一些很好的建議。”

Jared Smith – Capital One 開源社群經理

當公司將它們的議程向前推進至它們的員工中可能沒有所需人才的領域時，它們會希望開源。透過轉向開源，它們可以經常加快工作速度，並與朝著相同軟體目標工作的人們合作，同時也降低了成本並改進了它們的終端產品。

開源專案提供了協作的自由——即使是在同一行業的競爭對手之間——並且可以透過多方關注過程中的程式碼來加速開發程序。透過合作，開發人員可以公開分享，獲得大量反饋，並共同構建可擴充套件的、高效的且高質量的程式碼。

企業啟動新的開源專案的 5 個理由：

• 加速開源解決方案；為標準提供實施參考；分攤戰略性功能的開發成本
• 將市場商品化；降低非戰略性軟體元件的價格。
• 透過為您的產品建立生態系統來推動需求。
• 與他人合作；吸引顧客；加強與共同目標的關係。
• 為您的客戶提供自我支援的能力：無需等待您即可自行調整程式碼的能力。

來源：Ibrahim Haddad

何時建立一個開源專案

釋出或建立新的開源專案的決定取決於您的情況。貴公司首先應該透過使用開源軟體併為現有專案做出貢獻來達到一定的開源掌握水平。這是因為消費可以教您如何利用外部專案和開發人員來構建您的產品。而且參與可以使您對於開源社群的公約和文化的掌握更熟練。（請參閱我們關於使用開原始碼和參與開源社群的指南）但是一旦您熟練掌握了開源，那麼開始啟動您自己的開源專案的最佳時機就是“儘早”和“經常”。

發展方法論
儘早釋出 其他專案參與者可以提供反饋併為開發做出貢獻。 新的想法可以被合併，同時程式碼仍然是靈活的。 問題可以被其他參與者標記出來，在問題變得更嚴重之前。	經常釋出 較小的更改更易於理解、除錯、改進與推動成熟。 保持快速的開發速度、質量保證和創新。 對專案成員保持對於進展情況和當前發展狀況的高度公開。

來源：Ibrahim Haddad

從何處開始

也許建立一個新專案的時間是當您意識到您有一個無法自己解決的技術難題的時候。另一個激勵因素是當您無法找到並加入另一個做著您想讓它做的事的專案的時候。最終，這個問題並沒有正確答案。當您需要一個專案卻找不到現成的專案時，您就開始建立一個專案。

對於考慮新的開源專案的企業而言，您希望透過找到您關於“為何建立開源專案？”的獨特答案來開始。以提出關於什麼對您的組織至關重要的許多問題開始。出於正確理由來啟動一個開源專案是非常重要的。

“我認為，對於一家公司來說，考慮他們希望透過一個新的開源專案來實現什麼是至關重要的。他們必須考慮一個新的開源專案對社群和開發人員的價值以及他們希望從中獲得什麼成果。然後他們必須理解他們要以正確方式做到這一點所必須具備的所有條件，包括法律、管理、基礎架構和一個初始社群。當您提出一個開源專案時，那些是我總是強調最多的東西。”

John Mertic – Linux 基金會專案管理負責人

開始的地方包括二級編碼專案，在這些專案中，企業不需要成為一個權威機構，而且這些專案中可能有數量更龐大的一群技術人員，這些來自世界各地的技術人員可以幫助您解決問題。如果它不是關鍵任務程式碼，那麼它可能是一個很好的開源備選項。但是，它也應該是貴公司仍在積極使用和維護的程式碼。對程式碼的商業依賴可以實現錯誤修復、補丁和新功能的連續反饋迴圈。

“我們分享的許多專案都是我們在內部使用的專案，因此我們嘗試分享我們在生產中實際使用的專案。這意味著，由於Facebook的規模，它的規模經過了實戰檢驗；這是我們為社群貢獻的專業工作。另一個關鍵的是，因為我們正在使用這些工具，所以我們不會讓它們疲於奔命或不被支援，因為我們的工程師也需要它們的強大功能。”

Christine Abernathy – Facebook 開源團隊開發者&倡導者

另一個要考慮的問題是您的專案是否是獨一無二的，或者其他人是否因為他們有著類似的問題已經在研究類似的程式碼。潛在的開源專案是否對貴公司來說至關重要，貴公司是否可以將之作為專案來提供支援和管理，以及其他使用者是否也會這樣做？如果是這樣，那麼這個想法可能很有意義。

您還需要決定是否要將您的程式碼捐贈給堅持供應商中立的非營利組織，或者透過擁有和執行自己的專案來保留一些控制權。而且，答案取決於您想要實現的目標。

“做一個開源專案是因為您認識到潛在專案中的某些東西對貴公司嚴格來說並不是很重要，但您想要對其保持一定的控 制權。當您知道透過讓其他開發人員將其作為一個開源專案來參與其中，它也會幫助促進您自身的發展的時候，您可以這樣做。所以，思考追求一些事情並著手去做。”

John Mertic –Linux 基金會專案管理負責人

在啟動開源專案之前要問的問題

• 我們可以在財務上贊助該專案嗎？
• 我們有一位內部執行冠軍嗎？
• 是否有可能與現有的開源專案一同努力？
• 我們可以使用 OSS 模型啟動和維護專案嗎？
• 成功由什麼組成？
• 我們如何衡量成功？
• 專案能否吸引外部企業的參與（從一開始）？
• 是否有足夠的外部興趣來組建和發展一個開發人員社群？

來源：Ibrahim

專案計劃

一旦您已經開始了您的計劃，就有無數的細節必須考慮和解決，以使您的開源專案成為現實。讓我們一步一步地考慮問題，從您如何決定是否釋出或捐贈專案原始碼開始。

決定釋出或捐贈什麼程式碼

首先，您必須決定貴公司是否希望建立或釋出程式碼，同時保留程式碼和專案的所有權，或者您是否要將程式碼捐贈給其他人來維護和管理專案。如果程式碼已經存在，那麼有一個相關問題是您是否會發布專案中的所有程式碼或僅將其中的一部分程式碼作為開源專案釋出。

為了做出這些決定，考慮退一步去確定您心中為程式碼設定的目標。

“當我們的工程師決定要啟動開源專案時，我們會看這幾件事情。首先，我們想要確定，這個專案將對公司以外的開發人員有用嗎？且這個專案將會是變革性的嗎？這是我們可以展示的東西嗎？以及是否將會有一個圍繞此專案建立的社群，維護此專案的人能否為社群提供支援？”

Christine Abernathy – Facebook 開源團隊開發者&倡導者

例如，您可能希望吸引來自其他開發人員的關於應用程式中對您的工作不是特別重要的部分的新鮮見解。或者您可能尋求額外的實際演算法來檢測系統監控應用程式中的日誌。您只能釋出與演算法相關的程式碼，而不要將整個產品作為開源釋出。這使您可以獲得其他人的貢獻，並幫助需要類似幫助的其他人，而不會危及您的核心業務。

開始一個專案並保持整體控制權可以讓您擁有監督權並給予您幫助將其塑造成您所需要的專案的能力，同時還給予正在做貢獻的開發人員自由與控制權以讓他們完成工作。

貢獻您的程式碼是不同的。這意味著放棄並將一些控制權交給其他人維護和管理。它可能是貴公司不再需要的程式碼，但它對其他人仍然有價值，因為它為使用者填補了重要的利基。這種貴公司只可能不會再為之花費時間的程式碼，可以受到開源社群的歡迎與推動，並可能引出蓬勃發展的長期專案。它也可能是貴公司的關鍵程式碼，但一個專案需要中立，以吸引更多的參與者並發展更廣泛的生態系統。

不要僅僅提供對您不再有用或您不再有興趣的程式碼，並期望社群能夠保持它的最新狀態——這不是我們的意思。相反，不要使用開源社群或專案來拋棄舊程式碼，以看它是否能重獲活力。如果這不是一個真正重要的專案，那麼您將在開源領域失去信譽，而且當您以後嘗試開源其他程式碼時，開發人員將不會感興趣。他們會記得您過去浪費了他們的時間，這不是您想要它發生的事情。

“如果您今年建立了三個開源專案，而且它們都是非常好的專案，並且它們已經吸引了一個良好的社群，而且它們有很高的價值，那這將比每年建立 10 個開源專案更為重要。老實說，開源社群重視質量超過重視數量，而且它們會自行選擇要加入的專案。如果您創造了 10 個可怕的專案，您將不會創造任何吸引力。 您想要把好東西拿出來開源。”

Guy Martin – Autodesk 開源負責人

建立一個商業案例

啟動開源專案的好時機，是在您開發了一個完備的商業案例之後。這個案例是由可以實現的成果帶來的，就像您正在帶入市場的任何其他產品一樣。然後還需要有高管的認同，因為管理層需要理解為什麼要進行這項工作，目標和預算是什麼，路線圖將會是什麼，哪些智慧財產權將會被開放，以及將會涉及什麼程式碼，不會涉及什麼程式碼。

分配資源

您還需要決定您是否可以做出必要的資源承諾，包括能夠貢獻於專案的開發人員的時間。開發人員的時間原來可能與他們在內部程式碼工作上花費的時間長度差不多。您還需要考慮您的開發人員需要提供什麼時間、材料或幫助來幫助新社群中的其他人加快程式碼庫的速度。法律團隊也需要資源來參與建立可能涉及競爭對手的開源專案。而市場營銷投資將確保專案在啟動之後獲得支援和貢獻者。

您還需要為用於開始和維護專案的基礎架構設定預算。這包括一個專案託管和原始碼控制網站， 如保留並維護程式碼的 GitHub，還有漏洞解決方案和其他所需工具。

測試程式碼質量

您考慮在您的開源專案中使用的程式碼的完備性與成熟度也可以表示您已準備好開始啟動您的計劃。您希望確保程式碼的狀態良好，正如我們之前所提到的那樣，而不是會導致開源社群可信度災難的垃圾程式碼。

同時，您必須注意的陷阱是，完美的程式碼並不是必需的。如果您認為程式碼必須是完美的，那麼您將可能永遠無法啟動它。用您已擁有的最好的程式碼去做，並知道其他人會幫助使它變得更好。您也確實希望確保您開始時使用的程式碼不包含帶有商業秘密的程式碼註釋，引用您的專有介面或褻瀆以及其他問題，因為您要確保它足夠成熟以進入社群。

確保它是有用的

當您看到並證明，它對其他同樣為他們的IT問題尋求這樣的解決方案的人將是有用的的時候，您的專案也準備好繼續前進。這些問題可以透過傳統市場分析來收集。您想確定這是其他人會尋求並願意為之貢獻的東西，因此它可以成為一個成功的專案。做一些研究並問問周圍的意見。參加開源活動並與開發人員和演示者討論他們的問題和專案。

如果您發現其他人已經開始了一個類似的專案來解決類似的問題，那麼您可以考慮您是否想加入這個專案工作而不是複製它。如果一個類似的專案已經存在，即使您的競爭對手在推動它，協作也將更有力，因為協作是開源社群的重要組成部分。

在開源專案上與競爭對手合作是重要的考慮事項。如果貴公司啟動一個開源專案並吸引競爭對手參與，您可以建立協作和友好，所有這些都是為了程式碼的更好的質量，同時領導而不是跟隨。

諮詢您的團隊

透過我們已經列出的每一項考慮，技術團隊可以與管理團隊合作來做出這些決定並幫助指導流程以使專案成功。您的開發人員和 IT 人員可以說明它何時何地對協作變得有用。

“如果我們找不到我們正在尋找的東西，或者如果我們發現過去發揮作用的東西在我們前進的過程中不再適用於我們，我們將啟動一個開源專案。有時這是出於效能的原因。有時候，這只是成本原因或供應商鎖定原因。有時候，我們正在將一大堆基礎架構轉移到更先進的技術上，我們過去使用的一些傳統供應商只是沒有做好準備，或者不願意在雲或集裝箱化環境中執行他們的軟體。”

Jared Smith – Capital One 開源社群經理

啟動您的開源專案

一旦您正確地規劃了您的專案，現在是時候採取一些更正式的步驟來設定您的專案，從法律準備開始。這包括程式碼掃描和清理以確保程式碼的安全使用，為您的專案選擇正確的開源許可證，並設定專案管理以實現平穩運營。解決方案的相關主題包括：建立適當的基礎架構，準備程式碼以啟動，然後最終向社群傳達專案的啟動，並持續提供檔案。

法律審查

專案可能發生的最糟糕的事情之一就是社群對程式碼庫的法律清白缺乏信任。確保您釋出的程式碼具有明確的許可證和出處是非常重要的。完整的法律審查通常有助於確保獲得貢獻的內容將被社群中的其他人接受。這個審查的一個重要方面是驗證貴公司是否有權釋出所有程式碼。您的法律審查應包括商標盡職調查和註冊。請注意，如果您將專案貢獻於基金會，請確保您在開源您的程式碼庫之前與商標戰略形成一致。

您還需要為您的專案選擇許可證。記錄所有許可證或智慧財產權的要求是很重要的。智慧財產權政策可以成為建立的一個有用的檔案，以明確所有許可證和貢獻要求。此外，請確保您的程式碼具有嵌入每個檔案中的許可證標題或 SPDX 許可證識別符號。另一個最佳實踐是在每次提交時都要求開發者原產地證書（Developer Certificate of Origin）（DCO）‘簽名’，以幫助改進程式碼的出處。例如，GitHub 已經構建了一個要求用於所有儲存庫的工具，該工具可在 https://probot.github.io/apps/dco 上獲取。

熟悉常見的開源許可證及其交易是很重要的。一些有明確的專利授權，一些有防禦性的終止權利，一些保護使用者的權利，一些提供措施條款，有些只是在您的行業中更簡單或更普遍地被接受。您還需要為了您的依賴性考慮您的軟體可能與其相結合或與之整合的其他程式碼庫中正在使用的許可證。

除了軟體原始碼之外，還應考慮專案其他方面的許可證要求。如果您預計需要公司對專利授權的承諾，或者稍後重新授權專案的能力，那麼您可能需要檢視一些更常見的貢獻者許可協議（Contributor License Agreements）（通常稱為 CLA）。並非所有的 CLA 都是相似的，所以仔細考慮這個選項。還要注意，CLA 可能成為參與的障礙，因為開發人員通常需要經過艱苦的審批流程才能簽署協議。

您的專案也可能產生不是軟體的交付物。如果您的專案正在生成檔案，請討論您是否應該為檔案使用特定的許可證。例如，許多開源專案將開源許可證用於軟體，而將創作共用授權（Creative Commons license）（CC）用於檔案。此外，有些專案尋求建立可能由其他人以各種方式實施的規範。這些專案應考慮使用規格許可證的選項。其中一個例子就是開放容器倡議（Open Container Initiative）（OCI），它使用了 OWFa 1.0 版—— 專利專用許可證，以及他們正在構建的開源軟體實施的 Apache 許可證 2.0 版。

許可證的另一個常見問題是在著作權許可和許可證許可之間進行選擇。著作權通常用於描述需要相互共享的許可證，並且通常試圖保證使用者接收他們被提供的軟體的原始碼的權利。許可證許可傾向於使其他人無需履行下游義務即可輕鬆參與和分享貢獻。這特別有利於軟體部分，這些軟體部分要求軟體生產商能夠基於開原始碼庫分發專有軟體，而不洩露其變更。

每種許可方式都有其優點和缺點，但要注意分裂專案的潛在風險，這是要求互用性或為各種供應商解決方案提供可移植性的軟體的一個特殊問題。如果商業解決方案透過了社群建立的測試或一組要求，那麼通常會透過建立允許使用專案商標的一致性程式來解決此問題。預先考慮這一點將有助於預示您的法律審查和專案計劃。（有關開源法律問題和注意事項的更多資訊，請參閱我們推薦的閱讀清單。）

總而言之，法律審查過程中的步驟包括：

• 考慮開源對貴公司智慧財產權的影響
• 確保完全符合開源許可證
• 選擇要釋出的原始碼的開源許可證，在您的專案中非常清楚地記錄所有許可證要求
• 決定您是否需要貢獻者協議
• 考慮社群可能提供的非軟體輸出以及恰當的許可證，如檔案和說明書
• 決定與商標相關的任何考慮因素
• 決定是否還有其他因素可以納入您的生態系統計劃中，例如一致性測試

技術審查

技術審查驗證了原始碼可以在不依賴於其他內部程式碼或開發實踐的情況下執行，並且它不包括公司在開源釋出中不包括的第三方程式碼。

您需要確保您計劃釋出的程式碼中沒有任何部分違反了其他公司的智慧財產權，例如專利。有大量的專利兜售者會違反他人專利尋求程式碼。這是一個具有重大負面影響的巨大問題，所以您必須從一開始就把它做好。為此，公司通常使用專門的掃描工具掃描程式碼，以確保程式碼清白。新增許可證和版權宣告，以及描述它是什麼與如何使用它的檔案。

清除非公共元件的關鍵依賴性技術審查應包括所有許可證和版權宣告的驗證，而且私人程式碼評論應予以清理。 步驟包括：

• 提供檔案和用例示例
• 清除內部評論，對其他內部程式碼的引用等
• 確保編碼風格一致
• 更新原始碼檔案中的版權宣告
• 在原始碼檔案中新增許可證通知
• 將許可證文字作為檔案新增至根目錄中

管理

為了準備啟動專案，您還必須定義專案管理的技術要求。管理是專案作出關於戰略、釋出、方向和發展重點的決策所透過的過程。決策制定應該公開且開放，以幫助確保所有參與者都瞭解專案的變化並保持透明度。另外，請考慮您的管理是否應包含升級問題的途徑。

在過程的早期決定參與專案管理機構必須達到什麼標準是很重要的。關於如何追蹤功能和漏洞， 如何提交程式碼以及由誰來管理釋出流程的決策應該正式化。

您希望確保專案委託的人員擁有運營和維護專案所需的工具。這就是您的開源專案辦公室和經理參與之處。

“您需要確保需要完成這些工作的人員被充分授權以獲得成功。您還需要意識到不要將專案的業務部分與專案的技術部分混為一談——他們需要有獨特的領導力。這樣您就不會使事情停滯不前。您沒有讓人們做出關聯之外的決定。讓業務部門幫助使技術部門更加成功。”

John Mertic – Linux 基金會專案管理負責人

技術流程

在啟動之前，建立一個標準釋出流程來安排程式碼的定期釋出通常是有幫助的，因為專案維護人員進行了更改和改進。應該為專案的開發社群和業務部門設定具有明確定義和可見細節的時間表。

這些程式碼的釋出頻率應該取決於您的社群的期望。如果專案是以企業為中心的，而且您正在嘗試構建非常強硬的專案，那麼您的釋出時間表可能是每年兩次。如果專案範圍較小，且較靈活，而且您試圖從中獲取一部分內容，也許您可能每月或每週釋出程式碼。時間表的關鍵在於，社群必須規定時間線，並理解專案的能力以從速度的角度支援專案，同時向使用者提供他們需要和期望的東西。

如果社群提供的反饋意見是釋出得太快或太慢，那麼您需要檢視過程並進行一些調整。這裡最重要的是一致性、可預測性和可見性。

領導

在開始之前，設定領導角色也很重要。這對於不同的專案可能意味著不同的事情。如果您正在與多個企業參與者一起啟動一個多公司經營的專案，則該專案可能需要更正式的管理，例如管理委員會或其他管理組織。其他安排可能只需要一個從技術角度監督開源專案的所有方面的技術委員會。委員會的組成主要包括技術領導，以及向執行團隊提供關於進展和專案需求的最新資訊的聯絡員。只要技術成員和管理人員認為合適，法律團隊就可以被引入。

您的頂級架構師也一定會在那裡，還有其他知道程式碼庫工作原理的人。總而言之，委員會成員將對專案進展以及來自開發人員社群內部的支援有一個遠景。 那些是您想要他們參與計劃過程的人。

“您對貴組織的信託責任是為程式碼做貢獻，以確保這與您的董事會和您的股東以及所有受此智慧財產權委託的人保持一致。您必須確定它們與此一致。但是，那麼您必須考慮到潛在的負債、風險和類似這樣的問題，正視這些問題。不要輕視這一 點。”

John Mertic – Linux 基金會專案管理負責人

基礎架構

在專案啟動之前，您需要為專案準備一個儲存庫。這實質上是一個程式碼庫的基礎架構，在這個程式碼庫中專案將隨時對貢獻者開放。許多專案使用眾所周知的 GitHub 或 GitLab 儲存庫，或者使用如 Gerrit 這樣的工具託管自己的儲存庫。 還有很多其他選項可用，但請記住，考慮讓開發人員更簡便地參與和從事您的專案工作通常是很有用的。選擇您的平臺，開立一個賬戶，併為程式碼準備一個地方， 設定工作流程並做好準備等待魔法發生。

漏洞、問題和功能的跟蹤也應作為專案基礎架構計劃的一部分。您希望為貢獻者提供一個簡單的地方，讓他們編寫需要被解決的問題的報告和新增的可能有用的新功能的要求。然後自動構建並測試系統流程，這些流程可能需要作為專案 GitHub 儲存庫的一部分被包含在內，以便在掃描和檢查程式碼來確保其質量的同時保持您系統和專案的順利執行。

網站

下一步是為該專案建立一個公司中性的網站或維基頁面。該網頁為社群提供了一個可以找到專案資訊的地方，包括檔案、程式碼下載連結等等。該網頁還可以提供關於專案領導、範圍、使用者和貢獻者、預算、管理和其他細節的詳細資訊。

溝通

為您的社群提供溝通渠道以提出問題來尋求幫助是至關重要的。您需要查詢可整合到整個開發工作流程中的工具（例如，接收支援請求、程式碼簽入、錯誤日誌和其他任務的通知）。您還需要提供重要的論壇和社群成員機制，以便從正在從事專案工作的其他人那裡快速獲得答案。所有這些都是幫助實時推進專案的重要溝通方式。

需要考慮的一個專案工具是 Slack，一個線上團隊專案管理和溝通平臺，在這個平臺上使用者可以訪問和共享訊息與檔案，組織工作流程，執行資訊搜尋等。 但是，Slack是一個專有工具，並且可能需要花費金錢來維護。還有其他開源選項，如 IRC、Gitter.im 等。例如，Hyperledger 專案使用一個名為 Rocket.Chat 的溝通系統，這個系統是完全開源的，並提供與 Slack 類似的功能。如果您需要現代論壇，Discourse 是一個很好的選擇，它是完全開源的並且還提供可選的託管服務。

在選擇溝通系統時，請注意任何形式的鎖定、財務成本以及將來遷移至新系統的容易程度。隨著您的社群的成長，您需要適應所有新的溝通渠道，不久之前，新聞組成為許多開源專案的首選溝通方式。

“我們各種開源專案中的大約 190 個專案被安排在 GitHub 的 Autodesk 部分的一箇中心位置。我們過去至少有 14 個不同的部門專注於 Autodesk 開源專案。透過使用來自 Twitter 的一些程式碼，我們將 14 個部門放在一個單獨的檢視中，以供訪問者瀏覽。從公司的角度來看，確保人們看到您已經啟動的內容是很重要的，並且確保有一個他們可以找到的中心位置來讓他們提出問題。“

Guy Martin – Autodesk 開源負責人

啟動與維護

最終，在完成所有規劃、準備和多方面審查以及所需步驟之後，您將準備好啟動並開始維護您的開源專案。您將透過公共規劃、開放式溝通和完整的從頂層至底層的基礎架構，以及您為管理、技術流程以及兩者間的一切所建立的步驟來達成目標。

一旦這些關鍵部分全部到位，便是時候向全世界開放專案，並從貢獻者那裡獲得投入。當感興趣的貢獻者檢查這個專案並且看到它是周到的、簡潔的且有價值的時，他們將會很高興參與進來，因為這是他們可以使用的東西。

啟動之前的必要任務：

• 事先簡短介紹啟動合作伙伴
• 確保所有專案基礎架構正在執行、安全且可擴充套件
• 確保開發人員加入並監控溝通渠道（IRC，郵件列表等）
• 釋出原始碼
• 遵循開源開發模式

不要忘了營銷！

當然，啟動並不意味著您工作的結束。為了保持專案的順利進行，還有一系列額外的業務與營銷步驟也需要關注。它們包括推廣專案、制定成功的運營戰略、提供切合實際的預算和專案品牌戰略， 並建立活躍的社交媒體賬戶和有效域名以支援其長遠的成功。

營銷評估為品牌建立了指導方針。這一點尤其重要，因為它有助於確保市場資訊的一致性。營銷評估的步驟包括：

• 設計一個專案徽標、色彩設計、網站、擔保物等。
• 正式制定品牌指南
• 為專案註冊社交媒體賬戶（Twitter、Facebook、LinkedIn 等）
• 既然您擁有這個專案，那麼推廣它並讓人們知道它就在那裡，是您的工作，這樣人們就可以使用它並在專案上工作。作為營銷人員，這是一個有趣的挑戰，因為在這裡對您的成功的最後的檢驗是您可以驅動多少人加入專案中以貢獻程式碼、參與論壇、提供漏洞修復和報告問題。為專案註冊域名

“由於社群對此至關重要，因此您需要確保您照顧好社群。這可以體現在一些小事上，例如快速處理請求並確保您的專案能隨時提供幫助。所以，當有人來到您的專案時，他們可以看到它，並知道它的狀況如何。”

Christine Abernathy – Facebook 開源團隊開發者 & 倡導者

建立社群

專案啟動之後，監測外部社群的活力是至關重要的。

社群建設不會自動發生。在專案的早期階段，可能有必要在主要會議上舉辦開發人員活動或贊助商聚會以建立勢頭。

指定社群經理或社群倡導者管理期望和履行專案管理義務與透明度義務也是非常重要的。

持續的活動包括：

• 確保明確傳達方向或管理上的任何變化
• 遵循其他類似社群的最佳實踐
• 鼓勵並提供面對面社群建設的機會
• 識別合適的活動並舉行社群提交會談
• 考慮開展本地聚會

透過建立多元化的貢獻者群體，您可以透過與其他企業和將其視為有價值的專案的組織進行討論來確定他們是否有興趣投入時間、資金和其他資源來擴充套件您的初始努力，稍後決定將您的專案推進至下一個層面。透過從其他人那裡獲得投入和資源，該專案可以得到擴充套件和成長，可以為更多的貢獻者做更多的事。

這種增長意味著其他企業可能想要貢獻更多的資金來讓他們自己的開發人員加入專案工作，並透過在您已經開始的工作背後加入他們的支援來幫助推進工作。這可能涉及 10,000 美元或 250,000 美元或更多，取決於專案的重要性及其對於其他公司的意義。您的專案一旦開始，如果專案可以幫助其他公司完成任務的話，其他公司可以加入進來為專案工作貢獻資金。

這種情況如今經常發生，因為企業和組織都意識到他們試圖解決的技術問題比他們任何單獨一方都要大。正是此時，他們可以開始看到與其他公司一起參與供應商中立的聯合專案的戰略價值，這些專案正致力於更好地解決企業面臨的技術問題。

這種方法的幾個例子是：Hyperledger 的開源專案，是由 Linux 基金會贊助的促進跨行業區塊鏈技術的協作工作；雲原生計算基金會的開源專案，是將開源軟體用於建立現代私有云和公共雲。企業不僅為這些大型專案貢獻開發人員為之工作，而且還提供大量資金來幫助資助、推進和驅動技術向前發展。

結語

至少在第一次躍躍欲試去啟動一個開源專案時可能有點神秘，甚至是可怕。但是當您的企業看到並量化自身在過程中可以獲得的指數級別的價值時，第一個專案可能只是貴公司更加戰略地使用開源軟體的開端。瞭解其他人如何完成開源之路來幫助您的下一次開源努力取得成功。

開源專案啟動清單

注意事項

• 評估加入現有開源專案的可能性
• 評估公司使用開源模型啟動和維護專案的能力
• 評估其他公司從一開始就加入該專案的可能性
• 評估成功因素併為開源專案設定適當的指標

業務戰略和計劃

• 確定併為您的專案設定目標
• 從利益相關者那裡收集做這件事的原因
• 選擇要為專案考慮的程式碼
• 確定專案是否將包含應用程式的所有程式碼或僅包含部分程式碼
• 為選定的提案建立一個商業案例
• 確定是否有高管認同此舉
• 為開發人員和資金計劃資源承諾
• 設定成本預算，包括開發時間、基礎架構和相關費用
• 集合高管和技術人員進行專案討論並制定決策
• 辯論並最終確定專案範圍和選擇的程式碼

法律審查

• 考慮開源對貴公司智慧財產權的影響
• 確保完全符合開源許可證
• 選擇要釋出的原始碼的開源許可證，在您的專案中非常清楚地記錄所有許可證要求
• 決定您是否需要貢獻者協議
• 考慮社群可能提供的非軟體輸出以及恰當的許可證，如檔案和說明書
• 決定與商標相關的任何考慮因素
• 決定是否還有其他因素可以納入您的生態系統計劃中，例如一致性測試

技術審查

• 清除非公共元件的關鍵依賴性
• 提供檔案和用例示例
• 清除內部評論，對其他內部程式碼的引用等
• 確保編碼風格一致
• 更新原始碼檔案中的版權宣告
• 在原始碼檔案中新增許可證通知
• 將許可證文字作為檔案新增至根目錄中

管理和流程

• 定義專案管理步驟和結構
• 設定程式碼庫、漏洞報告和程式碼測試基礎架構
• 建立支援 Slack 的渠道、論壇和 Wiki
• 為專案的成功建立開放的貢獻者溝通渠道

品牌與營銷

• 制定營銷戰略以促進積極的貢獻者社群的發展
• 設計一個專案徽標、色彩設計、網站、擔保物等
• 正式制定品牌指南
• 為專案註冊社交媒體賬戶（Twitter、Facebook、LinkedIn 等）
• 為專案註冊域名

啟動與維護

• 啟動專案並開始開發工作和貢獻流程
• 指定社群經理或社群倡導者
• 確保明確傳達方向或管理上的任何變化
• 遵循其他類似社群的最佳實踐
• 鼓勵並提供面對面社群建設的機會

---

這些資源是與 TODO（Talk Openly，Develop Openly）組織合作建立的， 該組織是 Linux 基金會中專業的開源網路組織。特別感謝奉獻自己的時間和知識來製作這些綜合指南的開源專案負責人。參與制作的公司包括 Autodesk、Comcast、Dropbox、Facebook、Google、Intel、Microsoft、Netflix、Oath（Yahoo + AOL）、Red Hat、Salesforce、Samsung 和 VMware。如想了解更多資訊，請訪問：todogroup.org