1. 讓你的項目備受歡迎

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

1.2. 倦怠是開源項目面臨的頭號挑戰(zhàn)

1.3. 為新人設(shè)置項目

• 1.3.1. 擁有一個受歡迎的項目的第一步，是要讓維護(hù)者展現(xiàn)出歡迎新人加入的態(tài)度

• 1.3.2. 設(shè)置項目的基礎(chǔ)設(shè)施

  • 1.3.2.1. 大多數(shù)項目都使用GitHub或GitLab等服務(wù)，它們?yōu)殚_源項目提供免費的代碼托管服務(wù)

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

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

    1.3.2.3.1. 開源項目通常使用Google群組、groups.io或GNU Mailman等服務(wù)

  • 1.3.2.4. 論壇：許多社群會從使用郵件列表演變?yōu)槭褂谜搲c郵件列表相比，論壇往往更容易被發(fā)現(xiàn)并且具有更好的搜索功

  • 1.3.2.5. 即時溝通渠道

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

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

    1.3.2.7.1. 還能夠建立一個知識庫，雖然在原始論壇中可能不容易被發(fā)現(xiàn)，但至少可以將內(nèi)容記錄下來，以后也更容易構(gòu)建文檔或指南

  • 1.3.2.8. 設(shè)置定期會議，并盡量確保有線上加入的選項

    1.3.2.8.1. 定期設(shè)置會議很關(guān)鍵，因為一方面，這使日程安排更容易

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

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

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

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

• 1.3.3. 創(chuàng)建入門指南

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

  • 1.3.3.2. 在用戶體驗設(shè)計領(lǐng)域，人們普遍認(rèn)為用戶使用應(yīng)用程序的前5分鐘很重要

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

    1.3.3.3.1. 對于命令行工具，使用--help命令行開關(guān)或使用man應(yīng)該能夠觸發(fā)使用指南

  • 1.3.3.4. 了解你的用戶，并為他們提供合適水平的指導(dǎo)

  • 1.3.3.5. 專注于讓用戶在前5分鐘內(nèi)取得成功

• 1.3.4. 歡迎新貢獻(xiàn)者

  • 1.3.4.1. 在自由軟件的早期，通常情況下，軟件是在“幕后”開發(fā)的，最終用戶的參與非常有限

  • 1.3.4.2. 貢獻(xiàn)者常常對參與項目感到畏懼

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

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

  • 1.3.4.3. 貢獻(xiàn)者指南不是從講解規(guī)則和流程開始的，而是始于向貢獻(xiàn)者表達(dá)感謝

  • 1.3.4.4. 第一次積極的互動是成功的另一個關(guān)鍵

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

  • 1.3.4.6. 服務(wù)型領(lǐng)導(dǎo)力

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

• 1.3.5. 當(dāng)新人產(chǎn)生影響時，要認(rèn)可他們

  • 1.3.5.1. 新人通常認(rèn)為為開源項目作出貢獻(xiàn)是為潛在雇主建立自己作品集的一種方式，因為這些代碼貢獻(xiàn)有助于展示開發(fā)者所擁有的技能

• 1.3.6. 讓新人感到受歡迎的一個關(guān)鍵方面是，隨著時間的推移，應(yīng)該支持他們成為貢獻(xiàn)者或維護(hù)者

1.4. 有效支持最終用戶

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

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

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

• 1.4.4. 管理問題

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

  • 1.4.4.2. 良好的問題管理

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

    1.4.4.2.2. 指導(dǎo)用戶提交有效的問題：最好的方法是在提交流程中提供幫助

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

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

    1.4.4.2.3.2. 為用戶設(shè)定了預(yù)期，同時也讓他們知道你在傾聽

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

• 1.4.5. 社群和開發(fā)者管理

  • 1.4.5.1. 隨著項目不斷發(fā)展，許多用戶會以各種方式使用項目，你將看到圍繞項目自然形成了一個社群

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

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

  • 1.4.5.4. 融入社區(qū)，要讓其他社群成員參與進(jìn)來，在活動中發(fā)言、聚會、發(fā)布視頻和參與其他活動來融入社群

  • 1.4.5.5. 要富有同理心且保持積極向上，因為良好的社群和開發(fā)者管理會考慮到用戶經(jīng)常是因為無法解決問題而來到社群，社群和開發(fā)者管理的作用是理解、幫助解決問題，并讓用戶帶著積極的體驗離開

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

• 1.4.6. 商業(yè)支持

  • 1.4.6.1. 一個充滿活力的社群可以為最終用戶提供巨大的支持，但它永遠(yuǎn)不會達(dá)到商業(yè)支持所能達(dá)到的水平

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

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

    1.4.6.3.1. 良好的治理模式有助于確保供應(yīng)商中立，以實現(xiàn)更具協(xié)作性的項目

1.5. 參與到對話中去

• 1.5.1. 開源社群不是你可以完全設(shè)計的東西

• 1.5.2. 把虛擬協(xié)作看作社群興起的第一個渠道

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

  • 1.5.3.1. 當(dāng)技術(shù)專家和開源愛好者在職業(yè)生涯中成長時，你往往會看到他們聚集在不同的在線社群中

  • 1.5.3.2. 使用Reddit、Stack Overflow和其他平臺的訂閱功能，當(dāng)你的項目被提及時，會收到提醒

  • 1.5.3.3. 當(dāng)你發(fā)現(xiàn)這些對話時，請推廣它們

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

    1.5.3.4.1. 有助于將可能偶然發(fā)現(xiàn)該對話的人與正確的資源聯(lián)系起來

  • 1.5.3.5. 在討論發(fā)生的在線論壇和社交媒體上發(fā)布有關(guān)項目的信息

• 1.5.4. 區(qū)域聚會和活動

  • 1.5.4.1. 聚會和活動是開源文化的重要組成部分，它們對于激發(fā)協(xié)作至關(guān)重要

  • 1.5.4.2. 在會議上發(fā)言

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

  • 1.5.4.3. 當(dāng)你參加會議時，不要坐在角落里忙于用計算機處理你的項目

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

  • 1.5.4.5. 無論是線上活動還是線下活動，社群成員往往會圍繞領(lǐng)導(dǎo)者和有影響力的人聚集，讓一個項目認(rèn)可這些領(lǐng)導(dǎo)者有助于激勵他們并引導(dǎo)社群成員向他們看齊

  • 1.5.4.6. 支持社群的自然發(fā)展是對開源項目價值的一種肯定

    1.5.4.6.1. 這并不意味著它總是容易的

2. 將貢獻(xiàn)者發(fā)展為維護(hù)者

2.1. 開源項目通常采用與創(chuàng)業(yè)公司相同的模式，對于創(chuàng)業(yè)公司來說，先考慮長期發(fā)展再考慮短期成果是很困難的，因為沒有一定程度的收入和成功，就沒必要考慮長期發(fā)展了

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

2.3. 一個好的項目，就像一家好的公司一樣，會對兩者都給予適當(dāng)?shù)年P(guān)注，并在決策時兼顧兩者

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

3. 將貢獻(xiàn)者發(fā)展為維護(hù)者的重要性

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

3.2. 擁有更多的維護(hù)者可以減輕這種負(fù)擔(dān)，并幫助所有維護(hù)者將精力集中在他們最擅長的領(lǐng)域

3.3. 減輕當(dāng)前維護(hù)者的壓力

• 3.3.1. 挑戰(zhàn)之一是維護(hù)者的倦怠

• 3.3.2. 維護(hù)者的倦怠是開源社群一直存在的問題，但這個問題變得越來越嚴(yán)重了，因為人們的生活方式發(fā)生了變化

• 3.3.3. 隨著開源軟件的廣泛使用，維護(hù)者所承受的壓力達(dá)到了歷史最高點

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

• 3.3.5. 維護(hù)者會換工作，在這個過程中，維護(hù)者必須花費相當(dāng)長的時間來適應(yīng)新工作

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

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

• 3.3.7. 如果項目沒有按照維護(hù)者或創(chuàng)建者的想法發(fā)展，運營項目的吸引力會變得越來越小

• 3.3.8. 將貢獻(xiàn)者發(fā)展為維護(hù)者可以幫助維護(hù)者減輕壓力，并保持維護(hù)者的參與度和興奮感

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

• 3.4.1. 一個挑戰(zhàn)就是決策中心集中在一個人身上，而根據(jù)領(lǐng)導(dǎo)風(fēng)格的不同，這可能有助于推動共識，也可能會扼殺其他意見

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

• 3.4.3. 互相學(xué)習(xí)新的做事方式

  • 3.4.3.1. 有更多活動經(jīng)驗的人可以分享幫助項目做準(zhǔn)備活動的技巧，而有更深入開源經(jīng)驗的人可能對復(fù)雜項目的治理設(shè)置有見解

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

• 3.4.5. 當(dāng)你作為一個項目的維護(hù)者能夠適應(yīng)新維護(hù)者加入項目時，你就不再需要成為項目中的支點了

3.5. 使當(dāng)前維護(hù)者退居幕后

• 3.5.1. 現(xiàn)有組織增加了額外的資源，盡管通常情況下是相當(dāng)少的

• 3.5.2. 新組織或獨立開發(fā)者的價值增長，他們通常很有經(jīng)驗并且在行業(yè)中已經(jīng)比較知名

• 3.5.3. 要讓維護(hù)者退居幕后，他們必須對此感到舒適

• 3.5.4. 創(chuàng)造了引入新維護(hù)者和過渡領(lǐng)導(dǎo)的正確文化，這對于一個項目的初始領(lǐng)導(dǎo)者來說往往是困難的

• 3.5.5. 使維護(hù)者退居幕后的另一個方面是思考如何最好地優(yōu)化維護(hù)者的時間

• 3.5.6. 幫助項目擴展增長的最佳方法是構(gòu)建文檔、培訓(xùn)和認(rèn)證資源，以使項目本身能夠進(jìn)行大規(guī)模教育

• 3.5.7. 作為維護(hù)者，退居幕后可能會導(dǎo)致角色和責(zé)任的轉(zhuǎn)變，讓維護(hù)者利用他們的可用時間專注于特定領(lǐng)域，但這也可能是一條繼任之路，意味著維護(hù)者完全離開了一個項目

• 3.5.8. 作為一個維護(hù)者，并沒有必要終身參與一個項目，就像我們的職業(yè)生涯一樣，我們并不局限于終身一個雇主或一份工作