1. 讓你的項目備受歡迎

1.1. “歡迎馬車”的想法是幫助新鄰居克服結識新朋友的尷尬

1.2. 倦怠是開源項目面臨的頭號挑戰

1.3. 為新人設置項目

• 1.3.1. 擁有一個受歡迎的項目的第一步，是要讓維護者展現出歡迎新人加入的態度

• 1.3.2. 設置項目的基礎設施

  • 1.3.2.1. 大多數項目都使用GitHub或GitLab等服務，它們為開源項目提供免費的代碼託管服務

  • 1.3.2.2. 一個好的開源項目不能僅僅只有一個好的README文件，還需要有不同的溝通渠

  • 1.3.2.3. 郵件列表：電子郵件始終是任何人都能輕鬆使用的最基本的媒介

    1.3.2.3.1. 開源項目通常使用Google羣組、groups.io或GNU Mailman等服務

  • 1.3.2.4. 論壇：許多社羣會從使用郵件列表演變為使用論壇，與郵件列表相比，論壇往往更容易被發現並且具有更好的搜索功

  • 1.3.2.5. 即時溝通渠道

  • 1.3.2.6. 會議：無論是虛擬網絡電話會議還是面對面的聚會，都是項目參與者實時交流的機會

  • 1.3.2.7. 至少選擇一種易於發現的異步通信方法，如郵件列表或論壇。這不僅使來自不同時區的人們更容易進行協作，還能方便那些只能在晚上為項目作出貢獻的人

    1.3.2.7.1. 還能夠建立一個知識庫，雖然在原始論壇中可能不容易被發現，但至少可以將內容記錄下來，以後也更容易構建文檔或指南

  • 1.3.2.8. 設置定期會議，並儘量確保有線上加入的選項

    1.3.2.8.1. 定期設置會議很關鍵，因為一方面，這使日程安排更容易

  • 1.3.2.9. 保持會議的條理性，同時保持輕鬆的氛圍

    1.3.2.9.1. 舉行正式會議可能會給人一種會議非常專業的印象，但也可能被視為僵化和難以參與

  • 1.3.2.10. 要明確不同的溝通類型所適用的溝通渠道

    1.3.2.10.1. 通過即時溝通渠道很難達成共識，而使用郵件列表又很難獲得即時幫助

• 1.3.3. 創建入門指南

  • 1.3.3.1. 入門指南是歡迎人們加入項目的數字界面

  • 1.3.3.2. 在用户體驗設計領域，人們普遍認為用户使用應用程序的前5分鐘很重要

  • 1.3.3.3. 入門指南可能因項目和技術而異

    1.3.3.3.1. 對於命令行工具，使用--help命令行開關或使用man應該能夠觸發使用指南

  • 1.3.3.4. 瞭解你的用户，併為他們提供合適水平的指導

  • 1.3.3.5. 專注於讓用户在前5分鐘內取得成功

• 1.3.4. 歡迎新貢獻者

  • 1.3.4.1. 在自由軟件的早期，通常情況下，軟件是在“幕後”開發的，最終用户的參與非常有限

  • 1.3.4.2. 貢獻者常常對參與項目感到畏懼

    1.3.4.2.1. 項目中可能有他們不認識的人，這些人來自不同的地區，他們的種族、文化程度與性別也都不同，甚至可能是某個特定領域的高級專家

    1.3.4.2.2. 許多軟件工程師不擅長處理這些社交動態，所以時刻關注這些問題是緩解這種擔憂的好方法

  • 1.3.4.3. 貢獻者指南不是從講解規則和流程開始的，而是始於向貢獻者表達感謝

  • 1.3.4.4. 第一次積極的互動是成功的另一個關鍵

  • 1.3.4.5. “樂於助人”和“謙遜”

  • 1.3.4.6. 服務型領導力

  • 1.3.4.7. 表示歡迎是讓新人想留下來的第一步，但是為了讓新人留下來，項目必須展示他們對新人貢獻的重視

• 1.3.5. 當新人產生影響時，要認可他們

  • 1.3.5.1. 新人通常認為為開源項目作出貢獻是為潛在僱主建立自己作品集的一種方式，因為這些代碼貢獻有助於展示開發者所擁有的技能

• 1.3.6. 讓新人感到受歡迎的一個關鍵方面是，隨着時間的推移，應該支持他們成為貢獻者或維護者

1.4. 有效支持最終用户

• 1.4.1. 開源項目通常沒有為商業產品提供支持的能力，這是有充分理由的

• 1.4.2. 從人員配置的角度來看，很少有項目具備提供相同級別支持的能力

• 1.4.3. 在開源中，我們看到了社羣模式，這意味着我們的用户會幫助其他用户，有時bug和解決方案是在公開場合而不是閉門造車的環境下解決的

• 1.4.4. 管理問題

  • 1.4.4.1. 如何提出問題，這也是人們在項目中尋找答案的關鍵問題之一

  • 1.4.4.2. 良好的問題管理

    1.4.4.2.1. 讓提交問題變得容易：許多使用GitHub或GitLab的項目會使用默認的問題跟蹤器來處理問題，因為用户通常都知道該工具的使用方法，而且提交問題的門檻很低

    1.4.4.2.2. 指導用户提交有效的問題：最好的方法是在提交流程中提供幫助

    1.4.4.2.3. 定期審查問題並與用户溝通：如果你使用GitHub，可以使用各種GitHub操作來自動發送友好的消息，讓用户知道他們的問題已被看到

    1.4.4.2.3.1. 關鍵部分是節奏，即使你不能提供問題的解決方案，也需要説一些話，如“謝謝你提出的問題，但目前問題有點多，我們很快就會解決”​

    1.4.4.2.3.2. 為用户設定了預期，同時也讓他們知道你在傾聽

    1.4.4.2.4. 免長時間不迴應問題：將問題長期擱置且沒有新的評論或活動會給人一種項目忽略問題的印象，應確保主動定期審查陳舊問題，這不僅表明項目在積極關注問題，還有助於項目更好地確定優先級

• 1.4.5. 社羣和開發者管理

  • 1.4.5.1. 隨着項目不斷髮展，許多用户會以各種方式使用項目，你將看到圍繞項目自然形成了一個社羣

  • 1.4.5.2. 理解用户的需求，這意味着要看到評論和反饋，並幫助將其整合到項目中或展示解決方案

  • 1.4.5.3. 積極主動去幫忙，這意味着要儘早分享信息和見解，這樣其他用户就不會有同樣的困擾

  • 1.4.5.4. 融入社區，要讓其他社羣成員參與進來，在活動中發言、聚會、發佈視頻和參與其他活動來融入社羣

  • 1.4.5.5. 要富有同理心且保持積極向上，因為良好的社羣和開發者管理會考慮到用户經常是因為無法解決問題而來到社羣，社羣和開發者管理的作用是理解、幫助解決問題，並讓用户帶着積極的體驗離開

  • 1.4.5.6. OpenStack在社羣和開發者管理方面投入巨資，這幫助用户和開發者更快地取得成功，並幫助項目本身不斷髮展，能夠解決用户遇到的問題

• 1.4.6. 商業支持

  • 1.4.6.1. 一個充滿活力的社羣可以為最終用户提供巨大的支持，但它永遠不會達到商業支持所能達到的水平

  • 1.4.6.2. 沒有多少開源項目維護者希望在平安夜晚上11點修復bug

  • 1.4.6.3. 商業組織參與開源項目是一件好事

    1.4.6.3.1. 良好的治理模式有助於確保供應商中立，以實現更具協作性的項目

1.5. 參與到對話中去

• 1.5.1. 開源社羣不是你可以完全設計的東西

• 1.5.2. 把虛擬協作看作社羣興起的第一個渠道

• 1.5.3. 在線論壇和社交媒體

  • 1.5.3.1. 當技術專家和開源愛好者在職業生涯中成長時，你往往會看到他們聚集在不同的在線社羣中

  • 1.5.3.2. 使用Reddit、Stack Overflow和其他平台的訂閲功能，當你的項目被提及時，會收到提醒

  • 1.5.3.3. 當你發現這些對話時，請推廣它們

  • 1.5.3.4. 在這些對話中發表評論，將評論的作者和其他評論者鏈接到你的文檔或其他博客文章

    1.5.3.4.1. 有助於將可能偶然發現該對話的人與正確的資源聯繫起來

  • 1.5.3.5. 在討論發生的在線論壇和社交媒體上發佈有關項目的信息

• 1.5.4. 區域聚會和活動

  • 1.5.4.1. 聚會和活動是開源文化的重要組成部分，它們對於激發協作至關重要

  • 1.5.4.2. 在會議上發言

    1.5.4.2.1. 作為新的演講者，可能很難參與大型會議，但較小的區域聚會或活動總是會尋找新的主題和演講者

  • 1.5.4.3. 當你參加會議時，不要坐在角落裏忙於用計算機處理你的項目

  • 1.5.4.4. 如果你的會議被錄製下來，請在你的社羣或社交媒體中分享

  • 1.5.4.5. 無論是線上活動還是線下活動，社羣成員往往會圍繞領導者和有影響力的人聚集，讓一個項目認可這些領導者有助於激勵他們並引導社羣成員向他們看齊

  • 1.5.4.6. 支持社羣的自然發展是對開源項目價值的一種肯定

    1.5.4.6.1. 這並不意味着它總是容易的

2. 將貢獻者發展為維護者

2.1. 開源項目通常採用與創業公司相同的模式，對於創業公司來説，先考慮長期發展再考慮短期成果是很困難的，因為沒有一定程度的收入和成功，就沒必要考慮長期發展了

2.2. 開源項目往往不太依賴於短期成果，同時又不能忽視短期成果

2.3. 一個好的項目，就像一家好的公司一樣，會對兩者都給予適當的關注，並在決策時兼顧兩者

2.4. 可持續性的一個難題是要讓更多的人以不同的角色參與到項目中來，這些人來源於已經投入項目中的人

3. 將貢獻者發展為維護者的重要性

3.1. 當一個新維護者看到他們在項目中的個人參與增加時，他們常常對項目在成長過程中可能有的更大需求一無所知

3.2. 擁有更多的維護者可以減輕這種負擔，並幫助所有維護者將精力集中在他們最擅長的領域

3.3. 減輕當前維護者的壓力

• 3.3.1. 挑戰之一是維護者的倦怠

• 3.3.2. 維護者的倦怠是開源社羣一直存在的問題，但這個問題變得越來越嚴重了，因為人們的生活方式發生了變化

• 3.3.3. 隨着開源軟件的廣泛使用，維護者所承受的壓力達到了歷史最高點

• 3.3.4. 最終用户和其他下游利益相關者對維護者施加了太多壓力，把維護者當作一個完整的軟件開發團隊，而不是在不同活動之間維護項目各個方面的人員

• 3.3.5. 維護者會換工作，在這個過程中，維護者必須花費相當長的時間來適應新工作

• 3.3.6. 健康問題，無論是自己的還是親人的健康問題，都會佔用他們的時間和注意力

  • 3.3.6.1. 沒有足夠的精力繼續以以前的速度推動項目

• 3.3.7. 如果項目沒有按照維護者或創建者的想法發展，運營項目的吸引力會變得越來越小

• 3.3.8. 將貢獻者發展為維護者可以幫助維護者減輕壓力，並保持維護者的參與度和興奮感

3.4. 為項目帶來新的想法和能量

• 3.4.1. 一個挑戰就是決策中心集中在一個人身上，而根據領導風格的不同，這可能有助於推動共識，也可能會扼殺其他意見

• 3.4.2. 引入新的維護者，也就引入了新的想法和活力

• 3.4.3. 互相學習新的做事方式

  • 3.4.3.1. 有更多活動經驗的人可以分享幫助項目做準備活動的技巧，而有更深入開源經驗的人可能對複雜項目的治理設置有見解

• 3.4.4. 互相支持，並且從精神和情感支持的角度來看也是如此

• 3.4.5. 當你作為一個項目的維護者能夠適應新維護者加入項目時，你就不再需要成為項目中的支點了

3.5. 使當前維護者退居幕後

• 3.5.1. 現有組織增加了額外的資源，儘管通常情況下是相當少的

• 3.5.2. 新組織或獨立開發者的價值增長，他們通常很有經驗並且在行業中已經比較知名

• 3.5.3. 要讓維護者退居幕後，他們必須對此感到舒適

• 3.5.4. 創造了引入新維護者和過渡領導的正確文化，這對於一個項目的初始領導者來説往往是困難的

• 3.5.5. 使維護者退居幕後的另一個方面是思考如何最好地優化維護者的時間

• 3.5.6. 幫助項目擴展增長的最佳方法是構建文檔、培訓和認證資源，以使項目本身能夠進行大規模教育

• 3.5.7. 作為維護者，退居幕後可能會導致角色和責任的轉變，讓維護者利用他們的可用時間專注於特定領域，但這也可能是一條繼任之路，意味着維護者完全離開了一個項目

• 3.5.8. 作為一個維護者，並沒有必要終身參與一個項目，就像我們的職業生涯一樣，我們並不侷限於終身一個僱主或一份工作