如何參與到開源專案中去
編者：開源專案是程式設計師學習的一個途徑，面對那些發展多年的程式碼，我們到底該如何才能參與其中？
如果你想參與到開源專案中去，卻又不知道從何入手，這裡提供一些參考方法或許能給你提供一些幫助，哪怕你對你目前的技術還缺乏自信都不要緊。
開源軟體已經改變了IT，甚至整個世界，正是因為有了你們，樂於奉獻在開源事業中。不幸的是，很多人把參與到開源專案中想象成一個難以跨越的障礙一樣，因此而退縮。我通常聽到人們說他們很想參與到開源專案中來，但是因為以下的3個原因而打消了念頭。
l 我還不足夠優秀
l 我沒有足夠的時間
l 我不知道什麼樣的專案適合我
尋求機會參與到開源專案中去，你應該知道的三個基本原則：
l 專案需要各種能力層次的專業人才。
l 哪怕是微不足道的貢獻也比沒有好。
l 從你正在使用的專案作為參與到開源的第一步
我從開源專案中所觀察到最要命的想法是那些新人總認為要成為某種型別的天才程式設計師才能參與到開源中去，其實根本就不是這回事。當然，某些專案中的成員看起來就像搖滾明星，沒錯，他們確確實實是一個極具天賦的程式設計師，然而，我們中的絕大部分不是的。我們僅僅是那些只要把任務完成的人。有時我們做的付出的不需太多，有時我們需要花大把的時間，有時它就是程式設計，而有時它不是。
0. 加入郵件列表：
對於大多數專案，郵件列表仍然是專案開發溝通主要的渠道。在一個規模比較大的專案中通常有很多郵件列表可以選擇，例如：PostgreSQL專案就有不少於12個面向使用者的郵件列表和6個面向開發者的。我建議你關注最主要的幾個面向使用者郵件列表以及核心的開發者列表。
1. 關注部落格：
部落格一般由核心開發者維護，通常部落格中包含項在未來版本的一些資訊。如何獲取這些資訊呢？通常一個星級站點有包括來自很多相關專案的新聞或者部落格詞條，如果有一個星級站點，如：http://plant.gnome.org 或者 http://planet.mysql.com ,那麼你要做的僅僅是用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)，每個人都要行動起來，專案如果要變得強大起來的話每個人需要動員起來。
12. 寫部落格：
如果你有部落格，寫下你使用專案的一些經驗，記錄你碰到的問題及解決的方法。你可以通過兩種方式來提供幫助，一個是記住你身邊幫助過你的人，另一個是記錄下你將來可能會碰到的問題。
13. 改進網站：
很多程式設計師在圖形設計方面顯得非常糟糕，尤其是那些不能從設計部門得到幫助的專案網站。如果你有網頁設計方面的技能，不妨改進下網站，網站作為專案的招牌，是值得花時間的。或許專案介面需要徹底改造，抑或僅僅是一個logo，這些是社群缺乏的技能，如果我能提供一些圖形設計上的幫助，我會非常喜歡的。
有太多的方式參與到開源專案中，哪怕是我們寫一個新產品的特性的歷史回顧。每個使用開源專案的人都可以把技術帶到社群和幫助開源成為IT產業中重要的一部分。
在知乎上看到一個回覆覺得挺實用的，希望大家可以借鑑一下！
連結：http://www.zhihu.com/question/19963263/answer/13546308
來源：知乎
著作權歸作者所有，轉載請聯絡作者獲得授權。
首先，刻意的找開源的專案來參與是一種比較低效的方式。一個比較好的方法是多參與實際的專案。這麼做一是可以提高自己的能力，二是在此過程中可能會用到一些第三方的庫。有時候這些第三方庫可能會不太滿足的自己的需求，或是在使用期間遇到 一些 bug，這樣，我們就可以找到那些專案的原始碼，幫助作者修正 bug 或增加功能。
比方在用 Flask 做 web 開發的時候，我就遇到過幾個第三方外掛可以勉強滿足自己的需求，但是做的不夠好的情況。於是我就試圖把這些功能加上，並提 pull request 給作者。有時候作者會合並你的提交，有的時候會無視掉，不過沒關係，畢竟專案是作者說的算的 :) 。類似這樣的外掛專案基本上都是幾千行的長度，對新手來說，很方便入手。比起龐大的專案，這是一個非常好的切入點。
另外，附上一封大學時期的郵件：
上大學的時候接觸了 Linux，也問過這個問題。當時我給 Ubuntu Tweak 的作者 TualatriX Chou 發了郵件。這是他的回覆，希望對你有幫助。
Hi,
不好意思郵件回遲了，前幾天釋出UT 0.5消耗了大量元氣，沒來得及處理郵件。
作為一個過來人，對於“如何參與開源專案”，這個我有自己的理解。在讀書時，我也沒有太多的經歷，畢竟我真正的參與還是比較少的，更多的是自己去做，所以在學校的時候我開發了Ubuntu Tweak。
當然現在我在業餘也參與了一些其他開源專案，做一些力所能及的事情，比如Gloobus Preview，就是我負責完善打包和維護其PPA源。另外前段日子也接手維護OSD Lyrics這個軟體的Ubuntu源。
主要都是維護工作軟體的釋出工作，一是自己用Ubuntu，比較熟悉，二是自己對打包方面稍微有點經驗，因此這兩項都是跟打包有關的。
所以你可能有認知了，所謂“參與開源專案”，並不一定是參與開發，任何跟專案有關的，包括打包，翻譯，或者寫文件，甚至單方面的宣傳，都可以說是參與吧。
既然是參與，肯定是拿出自己比較拿手的方面，或者感到某個專案有哪些不足，哪裡需要人手，恰好自己又會，就順其自然地參與進去了。
問題就變成了，哪裡有需要幫助的，而且我能做什麼？很多人不知道如何參與開源專案，就是沒搞清楚這一點吧，因為都想是為了“參與”而去“參與”了。
所以，我想你先要問問自己，自己擅長什麼，或者想學習哪方面，平常用Linux時碰到過哪些不如意的地方？
對於你所擅長的：
假如你擅長UI設計，那麼你可以改造一下你覺得UI有待改進的軟體，然後發patch給開發者，他們覺得可以的話，就會接受。以前我也發patch給過GMLive，後來被他們接受了，這是一個例子。
對於你想學習的：
學習最好的辦法是，自己寫個小軟體，然後通過學習同類軟體的原始碼來達成目標。我自己的UT就不說了，剛開始我也是學習其他專案的原始碼來一步步寫起來的。說說最近的OSD Lyrics吧，http://code.google.com/p/osd-lyrics/，它出來沒多久。
你可以看到它主頁下面的：致謝，列舉了其他參考過的開源專案。一個全新的開源專案的誕生基本都是參考其他專案的設計、程式碼或其他，以便做的更好的。
所以，你即可以通過自己來寫個軟體來達到學習目的，也可以主動研究一款或者改進一下你覺得不滿意的地方。
大概說這麼多，希望你能明白。