非程式設計天才參與開源專案的14種方式

如果你想參與到開源專案中去，卻又不知道從何入手，這裡提供一些參考方法或許能給你提供一些幫助，哪怕你對你目前的技術還缺乏自信都不要緊。

開源軟體已經改變了it，甚至整個世界，正是因為有了你們，樂於奉獻在開源事業中。不幸的是，很多人把參與到開源專案中想象成乙個難以跨越的障礙一樣，因此而退縮。我通常聽到人們說他們很想參與到開源專案中來，但是因為以下的3個原因而打消了念頭。

1. 我還不足夠優秀

2. 我沒有足夠的是時間

3. 我不知道什麼樣的專案適合我

尋求機會參與到開源專案中去，你應該知道的三個基本原則：

1. 專案需要各種能力層次的專業人才。

2. 哪怕是微不足道的貢獻也比沒有好。

3. 從你正在使用的專案作為參與到開源的第一步

我從開源專案中所觀察到最要命的想法是那些新人總認為要成為某種型別的天才程式設計師

才能參與到開源中去，其實根本就不是這回事。當然，某些專案中的成員看起來就像搖滾明星，沒錯，他們確確實實是乙個極具天賦的程式設計師，然而，我們中的絕大部分不是的。我們僅僅是那些只要把任務完成的人。有時我們做的付出的不需太多，有時我們需要花大把的時間，有時它就是程式設計，而有時它不是。

0. 加入郵件列表：對於大多數專案，郵件列表仍然是專案開發溝通主要的渠道。在乙個規模比較大的專案中通常有很多郵件列表可以選擇，例如：postgresql專案就有不少於12個面向使用者的郵件列表和6個面向開發者的。我建議你關注最主要的幾個面向使用者郵件列表以及核心的開發者列表。

1. 關注部落格：部落格一般由核心開發者維護，通常部落格中包含項在未來版本的一些資訊。如何獲取這些資訊呢？通常乙個星級站點有包括來自很多相關專案的新聞或者部落格詞條，如果有乙個星級站點，如：或者 ,那麼你要做的僅僅是用google搜尋」planet 《專案名》」。

2. 加入到irc頻道：許多開源專案都有專門的網際網路中繼聊天(irc)頻道，用來為開發者和使用者討論開發問題。仔細查詢專案站點中irc頻道叫什麼。

3. **診斷：bug通常很難報告出來，診斷快速處置bug有助於節省開發人員的時間。如果使用者提出報告：「當我操作xx功能時，系統無法工作」，你得花些時間解決這些問題。還是不是會重複出現？例如該類問題是否只是發生在某種瀏覽器

不相容？只在發行版有這樣的問題還是其它的原因。

4. 關閉已修復的bug：通常bug在**庫中修復了，但是在問題追蹤系統中還沒更新。清理掉這些雜亂的東西雖然耗時，但是對整個專案來說是值得的。

5. 測試beta版或者候選版本：任何專案設計用於執行在多個平台時就有可能存在各種相容性問題。當乙個beta版或者候選版發布時，專案帶頭人希望能在不同的人和不同的平台上得到測試反饋結果，你就可以是其中之一。

6. 修復bug：修復bug通常是貢獻者開始接觸**的地方，非常簡單，在問題追蹤系統中找到感興趣的bug，把bug修復，如果合適的話為**的修復撰寫文件。

7. 寫測試：絕大多數專案都有測試套件用來測試**，很難想象測試套件中不能附加更多的測試在其上。使用測試覆蓋工具諸如基於c的gcov、基於perl的devel::cover，用來標識源**沒法通過測試套件測試到的範圍，然後新增乙個套件覆蓋它。

8. 理性對待編譯警告：許多基於c專案的構建過程中經常會出現很多古怪的編譯警告，這些警告通常不是錯誤，但是看起來像，太多的警告讓編譯器聽起來就像在發假警報，仔細檢查**是否的確隱藏有bug。

9. 附上注釋：當你在深入研究**時，你可能發現有疑惑的地方，如果感到疑惑，這對你來是乙個機會，比別人也可能碰到同樣的問題，給他們貼上注釋提交補丁。

10. 建立例子：一般專案都沒有太多入門的例子，不管是web api、普通程式庫、或者是gui應用如gimp、還是命令列工具，比起長篇的文件，乙個恰當的例子能夠更清晰更快速解釋軟體的使用方式。

11. 問題回答：參與到社群最好的方式是幫助別人。回答問題，尤其是那些初次涉及的，這對於乙個專案的成長很關鍵，即使你回答只是簡單地」rtfm」(read the fxxk manual)，每個人都要行動起來，專案如果要變得強大起來的話每個人需要動員起來。

有太多的方式參與到開源專案中，哪怕是我們寫乙個新產品的特性的歷史回顧。每個使用開源專案的人都可以把技術帶到社群和幫助開源成為it產業中重要的一部分。