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

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

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

• 1.1.2. 啟動一個開源項目是一種挑戰(zhàn)，而且確實值得驕傲

1.2. 降低開發(fā)成本

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

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

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

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

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

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

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

1.4. 更快推向市場

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

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

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

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

• 1.4.3.2. 擺脫Copland項目

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

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

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

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

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

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

1.5. 能夠集中投資

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

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

2.1. 回顧已經存在的項目

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

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

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

2.2. 構建商業(yè)案例

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

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

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

2.3. 獲得盟友

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

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

• 2.3.3. 執(zhí)行主管

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

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

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

• 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. 公司面臨的一個重大挑戰(zhàn)是如何認識開源項目的影響，因為它不像商業(yè)產品和服務那樣與收入或客戶數量等有形結果相關聯(lián)

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

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

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