1. 應對增長

1.1. 開源項目通常從小規模開始，最初可能只有一個或幾個貢獻者

1.2. 當一個項目能夠持續發展時，組織就會考慮投資并將其用于內部，同時將其構建到自己的產品中

1.3. 商業化可能被視為開源的反模式，但實際上，這也是對項目價值的一種驗證

2. 衡量增長

2.1. “不能衡量就無法管理”是一句經常被引用的名言

2.2. 關注太多指標也很難，因為指標的差異太大，優化起來也很困難

2.3. 用于衡量增長的關鍵領域：認可度、采用度和多樣性

2.4. 增加項目的認知度

• 2.4.1. 在提升認知度的階段，我們的目標是讓盡可能多的人關注項目，并且了解在某人第一次接觸到該項目時所采取的行動

• 2.4.2. 顯示某人與項目接觸的指標

• 2.4.3. 查看他們可能采取的下一步行動的指標

2.5. 項目采用度

• 2.5.1. 一旦有人開始使用一個項目，下一步就是以某種方式觀察項目的采用度

• 2.5.2. 在商業項目中，通常會使用某種遙測技術來報告活躍用戶的數量，但對于開源項目來說，這種侵入性行為通常是不受歡迎的

• 2.5.3. 報告問題

• 2.5.4. 在郵件列表/論壇上提問

• 2.5.5. 撰寫關于項目使用的博客文章或進行會議演講

• 2.5.6. 為項目貢獻代碼

• 2.5.7. 關于某人使用項目的推薦或案例研究

• 2.5.8. 在項目網站或代碼倉庫中的ADOPTERS文件中列出組織標志或名稱

2.6. 項目的多樣性

• 2.6.1. 一個多樣化的項目是可持續的，因為來自不同領域的個體可以幫助支持項目，而不是依賴于某一人群、某一組織或某一地區的支持

• 2.6.2. 多樣性是在項目開始時就需要考慮的事情，因為多樣性是由項目文化塑造的

3. 評估和補救低增長的領域

3.1. 提交記錄/提交者

• 3.1.1. 獨立的提交者數量

• 3.1.2. 在一定時間內的新貢獻者數量

• 3.1.3. 提交數量

• 3.1.4. 添加/更改的代碼行數

• 3.1.5. 審查貢獻者指南，確保其對預期清晰明了，并且對貢獻者的要求不會過于苛刻，因為它可能會阻礙簡單的貢獻

• 3.1.6. 確保定期審查和回應所有貢獻，并與貢獻者合作，幫助他們將貢獻納入項目

• 3.1.7. 在發布公告中認可新貢獻者，讓他們感到受歡迎和被賞識

• 3.1.8. 貢獻者的流失

3.2. 項目使用度

• 3.2.1. 通常不鼓勵使用遙測方式，因此在開源衡量中使用指標可能很棘手

• 3.2.2. 下載量或倉庫克隆/分支量

• 3.2.3. 關于使用項目的帖子或問題

• 3.2.4. 使用項目的博客文章或其他社交媒體

• 3.2.5. 在調查中，最有可能回應的人是那些有所顧慮的人，而不是對項目完全滿意的人

• 3.2.6. 調查的確是一個絕佳的工具，可以識別項目中存在的問題，以及項目讓用戶滿意的地方

3.3. 多樣性

• 3.3.1. 提升項目的多樣性往往是非常具有挑戰性的領域之一

• 3.3.2. 它往往促使項目維護者引入與他們不同的人

• 3.3.3. 與項目維護者不同的人通常會覺得參與項目令人生畏

• 3.3.4. 在項目社群中尋找來自代表性不足群體的成員，并支持和鼓勵他們

• 3.3.5. 確保項目有一個行為準則

• 3.3.6. 將多樣化的貢獻者發展為維護者

4. 增強和擴展項目的領導力

4.1. 創始人承擔了從銷售到市場營銷再到產品開發的多種角色，包括諸如“增長黑客”這樣的角色，這些角色在公司規模擴大以后是不可持續的

4.2. 創始人的興奮度和投入程度極高，以至于他們對投入公司的時間和對他們產生的影響視而不見

4.3. 從項目通才到項目專家

• 4.3.1. 項目的需求已經高到維護者缺乏時間來專門投入特定領域

• 4.3.2. 提升項目某些領域所需的技能并非維護者所擅長的，因此盡管這些工作已經完成，但完成得并不是很好

• 4.3.3. 項目沒有很好的方式讓新用戶和開發者“自我賦能”?，這意味著缺乏良好的文檔或培訓材料

• 4.3.3.1. 當需要這樣的材料時，通常只能臨時準備，無法重新利用

• 4.3.4. 維護者傾向于在相關項目中擔任類似領導的角色，這導致他們精疲力盡

• 4.3.5. 維護者傾向于務實地管理任何行業活動，包括舉辦聚會、準備演講、進行社交外聯以及與活動經理協調

• 4.3.6. 維護者手動管理CLA，需要向每個維護者發送文檔，然后必須對每個新貢獻手動核對CLA簽署者名單

4.4. 時間管理和預期管理

• 4.4.1. 幫助維護者在其他優先事項之間平衡時間的解決方案

• 4.4.2. 時間管理實際上也是預期管理，意味著需要明確工作內容、花費的時間以及所需資源的預期

• 4.4.3. 可能會出現“貪多嚼不爛”的情況，因為通常看似簡單的事情，當你在深入研究時可能會變得更加復雜

• 4.4.4. 擴展不僅僅是增加更多資源，還包括更有效地工作

• 4.4.5. 所要做的工作太煩瑣

• 4.4.6. 溝通完成任務的預期時間框架

• 4.4.6.1. 對于問題分類，你可能明確表示所有問題將在5天內審查完畢

• 4.4.7. 溝通是開源項目的關鍵—盡可能透明和誠實往往能在維護者、貢獻者和用戶之間建立更牢固的紐帶和信任

• 4.4.8. 不善于管理時間的風險就是逐漸倦怠

4.5. 避免倦怠

• 4.5.1. 倦怠是開源領域的熱門主題之一

• 4.5.2. 倦怠是我們經常看到的現象，但實際上，它是項目維護者未能妥善管理壓力的最終表現

• 4.5.3. 使用任務管理系統記錄你需要做的所有事情

• 4.5.4. 使用任務管理系統來幫助優先排序或安排事項

• 4.5.5. 合理安排休息時間，并堅持執行

• 4.5.6. 盡可能在周末休息來恢復精力，而不是工作

• 4.5.7. 安排好節假日，將其真正用于休息和恢復精力，而不是用來修復你一直想要解決的項目功能問題

• 4.5.8. 確保飲食質量，同時安排充足的睡眠和鍛煉

• 4.5.8.1. 疲勞、疾病和焦慮都是不健康的癥狀

• 4.5.9. 找到項目之外能帶來樂趣的活動

• 4.5.10. 定期進行健康檢查

• 4.5.10.1. 對于那些生活在擁有良好的醫療保健系統的地區的人來說，他們往往是最不善于實際利用這些系統的人

• 4.5.10.2. 請至少每年安排一次身體檢查

• 4.5.11. 當你遇到心理障礙時，可以暫時離開一會兒，做一些不同的事情

5. 開源的商業化

5.1. 在20世紀90年代和21世紀初，微軟被認為是開源的主要反對者，其內部立場是“擁抱并擴展”?，這是一種用于在市場上取得主導地位的策略，也用于與其他競爭軟件供應商競爭

5.2. 很多時候，查看和修改源代碼本身就是有價值的，而這通常是商業軟件無法做到的

5.3. 時至今日，企業愿意參與開源就已經是一種進步了，這些組織在與開源項目和社群合作時采取了更加負責和尊重的方式

5.4. 時至今日，企業愿意參與開源就已經是一種進步了，這些組織在與開源項目和社群合作時采取了更加負責和尊重的方式

5.5. 開源軟件通常與免費和自由軟件一起被歸類為FLOSS，即Free Libre and Open Source Software

• 5.5.1. 開源中的自由是“自由如同言論自由，而不是免費啤酒”?，這與libre一詞的詞根有關，它更多地用于描述自由，而不是沒有成本的東西

• 5.5.2. 盡管它是免費的，但代碼的許可證為項目的用戶提供了使用項目的條款和指導

5.6. 開源項目是可以商用的，就如同項目的其他用途一般

• 5.6.1. 商用有助于開源項目的可持續模式

5.7. 可持續性循環

• 5.7.1. 項目是軟件代碼和社群本身的集合

• 5.7.1.1. 只有在一個強大、協作和多樣化的團體共同努力，一起構建他們認為非常重要的技術時，開源社群才能取得成功

• 5.7.1.2. 社群可能包括為雇主工作的企業員工，也可能包括對這個領域感興趣和有熱情的個人

• 5.7.2. 當項目變得越來越有用，對市場越來越有價值時，項目可能將被產品化

• 5.7.2.1. 產品化還有另一個視角，那就是使用，意味著有人接受該項目并以某種方式使用它

• 5.7.2.2. 當項目被他人使用時，實際上就已經產品化了，因為項目就像任何其他產品一樣被“消費”了

• 5.7.3. 所有的決策都是由經濟價值或利潤驅動的

• 5.7.3.1. 在這個可持續性循環中，利潤是驗證開源項目產品化的關鍵部分

• 5.7.3.2. 降低研究和軟件開發成本：無須編寫和維護開源項目提供的代碼

• 5.7.3.3. 擴展潛在市場：在項目中添加當前項目開發團隊沒時間或沒能力開發的特性和功能

• 5.7.3.4. 加快上市時間：開發團隊可以利用一個或多個開源項目作為他們商業產品的構建模塊，而不必自己從頭構建

• 5.7.3.5. 既節省了時間和金錢，還使工作更加靈活，所有這些都創造了經濟價值，也代表了利潤

• 5.7.4. 完成循環的關鍵是要將利潤重新投入項目中

5.8. 開源的商業化仍然頗具爭議，因為這有時會被認為是在利用開源項目和開源開發者為企業謀利

6. 開源的商業化模式

6.1. 作為更大商業軟件包的依賴項或組件

• 6.1.1. 是將開源軟件作為更大商業軟件包的依賴項或組件使用

• 6.1.2. 是最常見的開源軟件商業化形式，也是大多數人非常容易忽視的

• 6.1.3. 當依賴項或組件作為更大的商業軟件包的一部分使用時，需要確保在開源代碼中保留適當的歸屬聲明

• 6.1.4. 使用軟件包數據交換的簡化版許可證標識符可以使FOSSology等許可證掃描的工具產生更準確的結果

6.2. 服務和支持

• 6.2.1. 服務和支持是開源商業化較早的模式之一，由紅帽公司通過其Red Hat Linux Enterprise支持計劃推廣

• 6.2.2. 開源軟件本質上是免費使用的，但與所有軟件一樣，最終用戶會遇到問題或有其他需求，需要有人提供幫助

• 6.2.3. 對于公司來說，其業務所依賴的軟件出現問題可能帶來巨大的影響，如果有所謂的“可追責的對象”確實會使他們在使用軟件時感到安心

• 6.2.4. 傳統的呼叫中心或支持中心，人們可以與中心內的某人討論他們遇到的問題，并獲得有關解決問題的幫助或方法

• 6.2.5. 幫助安裝或實施開源軟件，如設置服務器或進行定制

• 6.2.6. 培訓和教育，可能是講師指導與線上培訓，或者可能是像Packt這樣的圖書出版商出版關于使用特定開源項目的圖書

• 6.2.7. 最大的挑戰也是其最具吸引力的地方就是進入門檻低

6.3. 開放核心

• 6.3.1. 開放核心仍然是一種常見且有效的商業化策略

• 6.3.2. 與開放核心類似的模式是，開源可以作為一個基礎框架，然后有多個商業擴展插件可與之連接或集成

• 6.3.3. 許多專用設備驅動程序在商業許可證下被設計為與Linux兼容

• 6.3.4. 在Hadoop等生態系統中也看到過這一點，供應商會構建從數據可視化工具到Hadoop的集成，以利用存儲在數據湖中的數據

7. 為商用設置項目

7.1. 為商業供應商提供一種使用項目的方法，可以吸引更多的使用者，也可以帶來更多你之前可能未曾想過的使用方式

7.2. 可以增加新貢獻者和維護者，幫助支持和推動項目，并幫助改進項目的運營方式和代碼倉庫的質量

7.3. 品牌和知識產權管理

• 7.3.1. 依據項目所使用的許可證，供應商應該對其產品使用的項目進行恰當的歸屬聲明，這是非常重要的

7.4. 認可和一致性計劃

• 7.4.1. 認可供應商是項目的用戶，不僅能夠表明善意，也是對開源項目本身的認可

• 7.4.2. 最簡單的方式是項目在其代碼倉庫中新建一個ADOPTERS文件

• 7.4.3. 如果用戶不僅愿意表明自己是用戶，而且愿意提供背書，那么可以考慮用戶推薦或案例研究計劃

• 7.4.4. 建立一致性計劃通常采用項目與特定供應商之間簽署法律合同的形式

• 7.4.5. 一般步驟

• 7.4.5.1. 確定什么是一致性

• 7.4.5.2. 當確定了什么是一致性后，就可以開始正式定義要求了

>  7.4.5.2.1. 第一部分是技術部分，社群可以定義實施方式或應用程序需要做什么才能符合一致性，也可以定義在支持或服務一致性的情況下，供應商應該具備什么能力

>  7.4.5.2.2. 第二部分是商業要求，通常意味著對項目的某種資金支持以及供應商在指定期間維護技術要求的義務

• 7.4.5.3. 項目需要建立處理一致性申請的運營流程

7.5. 一致性計劃是為項目籌集資金的絕佳方式，因為我們都知道運營一個開源項目需要成本