1. 為什麼公司要將代碼開源

1.1. 當公司考慮為開源項目作出貢獻時，事情遠比表面上看到的要複雜得多，更不用説啓動一個開源項目了

• 1.1.1. 要想在組織內獲得對代碼開源的支持，首先需要了解開源的動機

• 1.1.2. 啓動一個開源項目是一種挑戰，而且確實值得驕傲

1.2. 降低開發成本

• 1.2.1. 底線是每個公司都會考慮的問題，這往往是關注開源的主要動機

• 1.2.2. 在軟件開發中，無論是最初的開發還是維護，都需要付出成本，其中包括新功能的開發、修復錯誤和解決安全問題

1.3. 為客户添加新的特性或功能

• 1.3.1. 每個工具都解決一個具體的問題（而且解決得很好）​，並且被設計與其他工具配合使用

• 1.3.2. 開源的另一個方面是能夠改進庫和工具，以使集成或客户體驗更好

• 1.3.3. 在開源中，這只是提交一個補丁並將其合併到主代碼倉庫的問題

• 1.3.4. 作為一個額外的好處，公司也不需要維護修復後的工具版本，這被稱為上游工作​，並且可以更容易地為公司的產品引入新的特性和功能，而不需要你做任何工作

1.4. 更快推向市場

• 1.4.1. Facebook（現在是Meta）​、Apple（蘋果）​、Amazon（亞馬遜）​、Netflix和Google（以上公司統稱FAANG）​，它們的差異化因素都是在開源的基礎上構建解決方案

• 1.4.2. Meta在崛起的過程中大量使用PHP

• 1.4.3. 蘋果在構建Mac OS X時使用FreeBSD和Mach內核項目的許多部分

• 1.4.3.1. 在從經典Mac OS轉向Mac OS X時，蘋果意識到價值在於用户體驗層面，所以構建自己的操作系統內核並沒有太大意義

• 1.4.3.2. 擺脱Copland項目

• 1.4.3.3. 使用已經擁有這些功能的內核和操作系統可以更快地將它們推向市場

• 1.4.4. 亞馬遜、Netflix和Google都使用了開源，併為更大的開源社羣構建了大量的開源項目

• 1.4.5. 許多初創公司都是從開源社羣中成長起來的，或者開創了自己的開源社羣以推動創新

• 1.4.6. 開源的價值在於構建生態系統，還有一個次要的好處，即不僅可以更快地進入市場，還可以更快地建立市場

• 1.4.7. Cloud Foundry起源於2011年Pivotal Software啓動的一個開源項目

• 1.4.7.1. Cloud Foundry作為標準—並且通過代理，Pivotal Software成了市場的領導者

1.5. 能夠集中投資

• 1.5.1. 不必為應用程序的每一層都配備專家，只需為業務至關重要的特定部分配備專家

2. 在內部獲得對代碼開源的支持

2.1. 回顧已經存在的項目

• 2.1.1. 開源項目的資源一直都很緊缺

• 2.1.2. 開發者也可能沒有足夠的資源來編寫測試、構建文檔、篩選傳入的問題、回答問題和處理安全問題

• 2.1.3. 與孤軍奮戰相比，相互合作有助於提高項目的效率，產生更大的影響，並完成更多的功能和用例

2.2. 構建商業案例

• 2.2.1. 代碼並不都是公司特有的，也不是核心代碼，而且如果讓外部人員參與，可能獲益

• 2.2.2. 開發者正在尋求擴展代碼或遇到具有挑戰性的問題，希望利用更廣泛的專業知識

• 2.2.3. 代碼與公司正在使用的開源項目相關，可以基於該項目構建，也可以從中派生，並且用例可能適用於其他人，因此將其推到上游對公司和項目都有好處

2.3. 獲得盟友

• 2.3.1. 預算盟友，他可以幫助資助開源項目所需的費用，並投入時間和精力

• 2.3.2. 技術盟友，可以是軟件工程師、架構師或管理者，他們目前正在參與代碼相關的工作，並有望在未來參與或受到開源提案的影響

• 2.3.3. 執行主管

• 2.3.3.1. 可能並不是在所有情況下都需要這個角色

• 2.3.3.2. 執行主管也可能和預算盟友是同一個人

• 2.3.3.3. 最大的區別是，主管的重要作用是確保開源能夠在公司內保持較高的戰略優先級，這使得未來更容易得到更多資源和預算

• 2.3.3.4. 隨着時間的推移，這位主管可能有機會在公司內建立一個更正式的開源團隊

• 2.3.3.5. 開源項目辦公室(Open Source Program Office，OSPO)，一般都是跨職能團隊，在公司內支持開源工作

2.4. 設定預期

• 2.4.1. 時間預期，無論是開源的過程，還是建立貢獻者基礎

• 2.4.2. 內部影響，有時所開源代碼可能沒有你想象得那麼能被廣泛應用，或者在一段時間內貢獻不會很大

• 2.4.3. 努力，開源需要很大的努力

3. 開源項目或代碼倉庫的檢查清單

3.1. 法律審查

• 3.1.1. 即將開源的代碼實際上是公司的知識產權，因此在為項目作出貢獻或在其中啓動新的開源項目之前，需要讓法律團隊對其進行審查

• 3.1.2. 法律審查，尤其是在公司第一次考慮為開源作出貢獻或啓動開源項目時，通常需要提前進行大量的教育工作

• 3.1.3. 在開源法律領域有一些出色的專家可以提供幫助

• 3.1.4. 從法律角度看，公司需要決定承受多大的風險取決於機會的可接受程度

• 3.1.5. 公司通過開源公開擁有的代碼，是從某種意義上將其知識產權交給了全世界，但對公司而言，問題在於這有多大價值

3.2. 技術審查

• 3.2.1. 團隊應該對代碼進行審查，以確保代碼有效

• 3.2.2. 代碼應該有文檔支持

• 3.2.3. 清除可能與未開源的內部項目或工具相關的任何代碼或註釋

• 3.2.4. 應該測試代碼以驗證其是否能夠正常工作

4. 衡量組織在開源方面是否成功

4.1. 開源的成功真的很難定義

• 4.1.1. 不像構建產品那樣簡單—在構建產品時，成功取決於用户或客户的數量以及由此產生的收入

• 4.1.2. 在開源領域，成功除了涉及使用情況，還包括對組織可能產生的其他潛在影響

4.2. 開源項目往往不直接與收入掛鈎（畢竟你是免費提供代碼）​，所以很難簡明地定義總投資收益率(Return On Investment，ROI)

4.3. 設定（合理）目標

• 4.3.1. 有明確性、可衡量性、可達成性、相關性和時限性(SMART)的目標是一個很好的目標設定框架

4.4. 識別和展示組織所作的貢獻

• 4.4.1. 公司面臨的一個重大挑戰是如何認識開源項目的影響，因為它不像商業產品和服務那樣與收入或客户數量等有形結果相關聯

• 4.4.2. 採用可以跟蹤多個貢獻領域的測量工具：對於較小的項目，GitHub社羣指標可能很有用，同時集成了代碼提交、開放問題、拉取請求和討論

• 4.4.3. 通過將開源貢獻與年度目標或KPI掛鈎來激勵團隊：這將使開源貢獻從“有時間就去做”轉變為“這是我的工作的一部分，公司以此為標準評估我”​，注意不要將其定位為負面的，而是要作為一個機會，因為沒有人喜歡在感覺像苦差事的事情上被評估

• 4.4.4. 制訂開源貢獻的內部表彰計劃