從開源軟件開發中體會到的心得
Mitchell Hashimoto 是一名開源軟件工程師。由他托管到 GitHub 上的開源項目 Vagrant，是一個用于創建和部署虛擬化開發環境的工具。近日，Mitchell撰文講述了在開發 Vagrant 的過程中學到的有關開源軟件開發的一些心得。
以下為原文文章：
把 Vagrant 做成一個相當成功的開源項目，這花費了我不少時間。但我從中也學到很多。此前，我并沒有看過很多關于開源項目學習的文章，但由于這些知識很重要，因此我想和大家分享一下我的一些關于開源軟件的心得。這些心得不僅和軟件開發有關，還包含了作為一個開源項目的維護者，如何做好市場推廣等方面的內容。
一、和軟件開發相關的心得
下面這些是關于軟件開發方面的心得：
1、態度友好
這一點是最重要的。有時，你可能會聽到一個糟糕的創意，收到的pull requests里面盡是劣質的代碼，甚至還要忍受用戶的抱怨，盡管他們沒有花一分錢。當你遇到這些情況，請記?。杭词褂脩舨灰欢ㄗ鹬啬?，你也要尊重用戶。我曾經只因為一件事情而大動肝火，但是現在，我可以很自豪的說：無論遇到以上哪種情況，我的態度都會很友好。對用戶有一個友好的態度是非常重要的。因為如果你的態度很友好，你會給別人留下平易近人的印象。而用戶也會因此向你尋求幫助或參與到你的項目中來，做出貢獻。這也正是開源運動的精髓所在。
2、不要為項目設置太過復雜的規則
除非你的項目很龐大，否則你不用太擔心貢獻者的編碼風格。為你的項目設置過于復雜的規則將阻礙開發者參與到項目中來?？崭瘛⒖s進等等這些編碼風格所造成的問題都可以很容易的通過人工來修改。因此你無需為貢獻者的編碼風格不同而煩惱。相反，你應該感到高興并接受這些真正優秀的貢獻。好了，現在你該知道如何改進你的開源項目了吧？這很簡單，接受這些優秀的貢獻，做出改變，然后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個月的時間?；蛟S我是最頻繁使用FFI的一員？讓我頭疼的是FFI庫定期升級更新，甚至更行到發布的補丁版本。有時候我清醒的發現僅僅是由于FFI的編譯問題，Vagrant就不能在 Windows 上正常運行了。此外，我還發現在使用FFI的時候，callback函數的運行和內存管理變得很困難。在Vagrant 0.9版本以前，都存在嚴重的內存泄露問題。***，我放棄了FFI，改用其它更好的庫，現在，Vagrant又可以調用C標準庫了。
4、和參與維護的開發者交朋友
每一個對某個函數庫了解甚深的開發者都會在那個函數庫里找到Bug?？v觀整個Vagrant的開發歷程，我曾在每個使用過的dependency里發現過Bug。我和所有的參與維護的開發者都有良好的朋友關系，因此，當出現問題時，我能很快的問：“這是你的Bug嗎？要多長時間才能修復它？”。最壞的結果可能是在一個dependency里有一個Bug，但維護者既不修復它也不發布更新后的版本。
雖然我依然有很多知識要學習，但希望這些點滴經驗能幫到那些正在做開源工作的開發者。
