從開源軟件開發中體會到的心得
英文原文：Lessons Learned Building Open Source Software
Mitchell Hashimoto 是一名開源軟件工程師。由他托管到 GitHub 上的開源項目 Vagrant，是一個用于創建和部署虛擬化開發環境的工具。近日，Mitchell 撰文講述了在開發 Vagrant 的過程中學到的有關開源軟件開發的一些心得。
以下為原文文章：
把 Vagrant 做成一個相當成功的開源項目，這花費了我不少時間。但我從中也學到很多。此前，我并沒有看過很多關于開源項目學習的文章，但由于這些知識很重要，因此我想和大家分享一下我的一些關于開源軟件的心得。這些心得不僅和軟件開發有關，還包含了作為一個開源項目的維護者，如何做好市場推廣等方面的內容。
一、和軟件開發相關的心得
下面這些是關于軟件開發方面的心得：
1、態度友好
這一點是最重要的。有時，你可能會聽到一個糟糕的創意，收到的 pull requests 里面盡是劣質的代碼，甚至還要忍受用戶的抱怨，盡管他們沒有花一分錢。當你遇到這些情況，請記住：即使用戶不一定尊重你，你也要尊重用戶。我曾經只因為一件事情而大動肝火，但是現在，我可以很自豪的說：無論遇到以上哪種情況，我的態度都會很友好。對用戶有一個友好的態度是非常重要的。因為如果你的態度很友好，你會給別人留下平易近人的印象。而用戶也會因此向你尋求幫助或參與到你的項目中來，做出貢獻。這也正是開源運動的精髓所在。
2、不要為項目設置太過復雜的規則
除非你的項目很龐大，否則你不用太擔心貢獻者的編碼風格。為你的項目設置過于復雜的規則將阻礙開發者參與到項目中來。空格、縮進等等這些編碼風格所造成的問題都可以很容易的通過人工來修改。因此你無需為貢獻者的編碼風格不同而煩惱。相反，你應該感到高興并接受這些真正優秀的貢獻。好了，現在你該知道如何改進你的開源項目了吧？這很簡單，接受這些優秀的貢獻，做出改變，然后 pull request。我一點都不擔心編碼風格、測試會帶來問題。我很樂意看到這些貢獻。
3、開發文檔的編寫是關鍵
雖然我沒有證據證明這一點，但我可以毫不夸張的說：所有首次使用 Vagrant 的用戶表示他們之所以選擇 Vagrant，是因為它的文檔很優秀。雖然世界上最煩人的事可能就是編寫開發文檔，但如果你不能及時的編寫文檔，那么項目就會存在失敗的風險。此外，別忘了開放文檔的權限，以便于開發者能方便參與。
4、有明確的溝通方式
IRC（互聯網中繼聊天）、郵件、論壇……交流方式不限，但你需要為用戶提供一個明確的、能得到及時回復（通常在 48 小時以內效果較好）的溝通方式用以表達他們的觀點。對于 Vagrant，我總是通過一個 IRC 頻道和郵箱來和用戶保持聯系，并且效果很好。同時，如果用戶和你溝通的方式越多，他們就會越信任你的項目。
5、你并不是什么都懂
有時候，你不可避免的會收到一些功能改進的請求，即便這些功能沒有用。對于項目管理者來說，重要的工作是為這個項目指明發展方向，而不是專注于某些微觀的具體的功能。這項功能是否于項目的發展相適應？它對用戶有用嗎？甚至是它對你有用嗎？你需要思考這些問題來指導項目的發展。因此，你需要打開思路。因為你的用戶比你清楚他們真正想要的功能是什么。但是，別忘了，你比其他人更清楚項目的發展方向。
二、和市場推廣相關的心得
現在，你完成了一個軟件項目的開發。但是如何讓用戶了解你的項目呢？下面是我關于市場推廣方面的一些心得：
1、Hacker News
Hacker news 社區喜歡嘗試新鮮事物，而且那里有很多的開發者。因此，你可以把項目提交到那里，同時標明你已經準備好回答任何問題。態度友好一些，因為你可能會被用戶詰難。
2、和優秀的博客站點接觸
幾乎在每一個社區，特別是 Ruby 社區里有很多優秀的博客。它們樂于分享用某項特殊的語言或方法開發的很酷的項目。找到這些博客，并和博主聯系，邀請他們參與到你的項目中來。這樣做會有 2 個益處：如果他們愿意參與，那么你的項目不僅能得到更多的關注，而且你的想法也能得到更好地檢驗。
3、在聚會上做演講（參加正式會議之前）
參加一些當地對你的項目感興趣的聚會，并發表演講。如果你是第一次參加，可以提前為演講做好準備。不要通過在項目里添加手冊的方法來宣講你的項目，你應該把這個項目的發展方向當面展現給公眾。如果你是第一次做演講，就不要立即參加某些正式的會議，因為公眾會記住你出丑的樣子，下一次想要再做演講就會變得困難。選擇在聚會上做演講則是一個比較好的方式。而且，在聚會上，你可以從真正關心項目的開發者那里得到一些重要的反饋。
4、在正式會議上做演講
參加過一些聚會之后，就可以在區域會議上發言了。這些會議通常規模較小，但是主題很好，而且與會人員不會因為你糟糕的談吐而輕視你。同時，大型會議也不可能允許你就一個新的項目發表演講。好了，現在你有機會站在眾人面前發表一場 40 分鐘的演講。在演講之前，要確保你做好了準備。演講時注意微笑，向公眾展示你的理想并記下你收到的建議。
5、在大型會議上做演講
現在，我要討論的是像 VelocityConf 或 QCon 這種類型的大型會議。主辦方將會讓你在更多的人群前發表演講（通常在 500 人以上），而且聽眾都是極其優秀的業內人士。如果你的項目對于聽眾來說較為陌生的話，你最好準備一個成功的案例來說明。而且這個案例最好來自于用戶，這樣才能證明項目的優秀性能。這些大型會議通常都會吸引一些重量級人士的參與（CIO、技術副總裁等等）。
三、有關軟件工程方面的知識
在軟件發布之前，有很多工作要做，一下是我關于軟件工程方面的心得：
1、測試
我不認為這個有必要詳說，但因為它是如此的重要，所以我還是要再發表一下看法。測試不是可有可無的工作。你必須及早的進行，并經常測試。此外，不要忘了集成測試。我曾做過很多的集成測試，而它們在 Vagrant 發布之前都是最有價值的測試。雖然單元測試能很快的捕獲基本的錯誤，但是集成測試卻能在版本發布之前找到最重要的錯誤。
2、支持 Windows ASAP
Vagrant 對 Windows 系統的支持非常棒。雖然 Vagrant 現在功能很強大，但之前它卻是一個噩夢。因為最初有很多開發者都不在 Windows 平臺上工作，代碼中多處函數都無法在 Windows 上運行。當時我簡直不敢想象為了支持 Windows 我們要做多少工作，因為你要在基礎代碼中做出大量的修改。此外，還有很多 Windows 的開發者想要使用 Linux 風格的工具。
3、避免使用外部函數調用接口（FFI）
這更多是 Ruby 方面的事。Ruby 的 FFI 庫沒有C標準庫那么簡單。我曾經在 FFI 上花了 18 個月的時間。或許我是最頻繁使用 FFI 的一員？讓我頭疼的是 FFI 庫定期升級更新，甚至更行到發布的補丁版本。有時候我清醒的發現僅僅是由于 FFI 的編譯問題，Vagrant 就不能在 Windows 上正常運行了。此外，我還發現在使用 FFI 的時候，callback 函數的運行和內存管理變得很困難。在 Vagrant 0.9 版本以前，都存在嚴重的內存泄露問題。最后，我放棄了 FFI，改用其它更好的庫，現在，Vagrant 又可以調用C標準庫了。
4、和參與維護的開發者交朋友
每一個對某個函數庫了解甚深的開發者都會在那個函數庫里找到 Bug。縱觀整個 Vagrant 的開發歷程，我曾在每個使用過的 dependency 里發現過 Bug。我和所有的參與維護的開發者都有良好的朋友關系，因此，當出現問題時，我能很快的問：“這是你的 Bug 嗎？要多長時間才能修復它？”。最壞的結果可能是在一個 dependency 里有一個 Bug，但維護者既不修復它也不發布更新后的版本。
雖然我依然有很多知識要學習，但希望這些點滴經驗能幫到那些正在做開源工作的開發者。