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