以下為原文文章：
把 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，但維護者既不修復它也不發布更新後的版本。
雖然我依然有很多知識要學習，但希望這些點滴經驗能幫到那些正在做開源工作的開發者。
英文原文：Lessons Learned Building Open Source Software