現(xiàn)在非常多的人都想涉足開源的，但不知道從什么地方入手。這里有幾種方法可以幫幫忙，即使你缺乏信心，你但仍然能夠讓你挑起技術(shù)大梁。

開源軟件改變了計(jì)算乃至整個(gè)世界，也許你也想為這樣一件事做出貢獻(xiàn)。但不幸的是，很多人認(rèn)為參與這樣的項(xiàng)目具有很高的門檻。我經(jīng)常聽到人們說，他們很樂意貢獻(xiàn)但不能的原因有三個(gè)：

• “我不是一個(gè)很優(yōu)秀的程序員。”
• “我沒有太多的時(shí)間投入進(jìn)去。”
• “我不知道什么項(xiàng)目值得去努力。”

我從開源代碼的新手中觀察到最有害的想法是，想要做一名優(yōu)秀的有貢獻(xiàn)的開源編程人員必須具有極高的天賦，這是不正確的。當(dāng)然，還有那些在開源世界誰被認(rèn)為是搖滾明星的，他們可能確實(shí)是天才程序員。然而，我們中的絕大多數(shù)都不是，但我們?nèi)匀粸楦淖兪澜缱鲋约旱呢暙I(xiàn)。

開始聽

在開源代碼的一切涉都及到其他人。如果你想加入一個(gè)團(tuán)隊(duì)，這意味著了解社會，了解它是如何工作的。進(jìn)入一個(gè)項(xiàng)目中，并說：“這是我認(rèn)為這個(gè)項(xiàng)目應(yīng)該做的事”，這通常不視為一件好事。有些項(xiàng)目可能會喜歡這樣的想法，但是如果項(xiàng)目已經(jīng)運(yùn)行了一段時(shí)間，那這種態(tài)度被接受的可能性就很小。聽是要知道這個(gè)項(xiàng)目需要以什么樣加入方式為***。

1.加入郵件列表

對于許多項(xiàng)目，郵件列表都是關(guān)于項(xiàng)目開發(fā)溝通的主要渠道。在大型項(xiàng)目中，有許多郵件列表可供選擇。例如，PostgreSQL的項(xiàng)目有不少于12個(gè)面向用戶的列表和6個(gè)開發(fā)人員的郵件列表。我建議主要從面向用戶的列表和核心開發(fā)者的郵件列表開始聽。

2.關(guān)注博客

由核心開發(fā)人員維護(hù)的博客往往會給出在將來的版本當(dāng)中出現(xiàn)的一些信息，以及什么時(shí)候能夠得到那些信息等等。

3.加入一個(gè)IRC頻道

很多開源項(xiàng)目都有專門的互聯(lián)網(wǎng)中繼聊天（IRC）的渠道，開發(fā)人員和用戶掛出問題以及討論項(xiàng)目的進(jìn)展等等。

入門工作

代碼是任何開源項(xiàng)目的核心，但編寫代碼并不是幫助入門的唯一途徑。代碼以及周圍代碼系統(tǒng)的維護(hù)通常都容易被忽視，這些地方不僅能修正錯(cuò)誤而且能夠創(chuàng)新功能，可以從這些地方入手來參與一個(gè)項(xiàng)目。

4.診斷錯(cuò)誤

診斷和篩選一個(gè)錯(cuò)誤可以幫助開發(fā)人員節(jié)省更多的時(shí)間來找出問題的細(xì)節(jié)。如果用戶反映到，“當(dāng)我做x工作的時(shí)候軟件不工作”，那么這時(shí)候你應(yīng)該檢查這個(gè)問題的細(xì)節(jié)。是否這個(gè)問題是重復(fù)的，如果是你可不可以創(chuàng)建一組解決這類問題的步驟，將此類問題縮小。即使你不知道是什么原因造成的問題，你可以把問題的范圍縮小從而減少其他人員解決問題的時(shí)間。

5.關(guān)閉修復(fù)的錯(cuò)誤

錯(cuò)誤往往是固定在代碼庫的，清理這些東西可能非常的耗費(fèi)時(shí)間，但是對整個(gè)項(xiàng)目非常有價(jià)值。檢查項(xiàng)目發(fā)布的更改日志，看看錯(cuò)誤是否是固定的，如果是可固定的，注意版本號并將其關(guān)閉。

處理代碼

所有有經(jīng)驗(yàn)的程序員都可以在整個(gè)項(xiàng)目的代碼當(dāng)中起到很大的作用，你不必認(rèn)為只有天賦異稟的程序員才能對項(xiàng)目起到作用。每個(gè)項(xiàng)目都有自己的工作流程,所以在提交代碼之前詢問清楚如何做。當(dāng)你修改代碼時(shí)，請確保你作為項(xiàng)目當(dāng)中的一員，并保持你的代碼風(fēng)格和代碼庫的其他代碼是相匹配。

6.測試一個(gè)測試版或發(fā)布一個(gè)候選版

任何項(xiàng)目運(yùn)行在多個(gè)平臺都可能遇到各種各樣的兼容性問題。當(dāng)測試版或候選版發(fā)布后，該項(xiàng)目負(fù)責(zé)人希望它會由很多不同的人在不同的平臺進(jìn)行測試，你可以負(fù)責(zé)這個(gè)工作來幫助項(xiàng)目能夠順利的完成。

7.修正bug

這通常都是代碼工作者剛開始想從事的工作，這很簡單：在interesting-sounding系統(tǒng)中找到錯(cuò)誤并且嘗試修復(fù)代碼，并檢查代碼的放置是否合適。同時(shí)添加測試的套件來測試那些固定的代碼。有些項(xiàng)目需要bug修正并且測試。

8.編寫一個(gè)測試

大多數(shù)項(xiàng)目都有一個(gè)測試套件的測試代碼，但很難想象一個(gè)測試套件不能附加給它更多的測試。使用類似于gcov或者C的測試工具來檢測到未通過測試套件的源代碼領(lǐng)域，然后添加一個(gè)測試套件來掩蓋它。

9.無聲的編譯器警告

構(gòu)建許多以C為基礎(chǔ)的項(xiàng)目往往會在屏幕上出現(xiàn)奇怪的編譯器警告標(biāo)志。這些警告通常是沒有問題的指向的，這時(shí)你應(yīng)該檢查是否該代碼實(shí)際上有隱藏的錯(cuò)誤。

10.添加評論

當(dāng)你開發(fā)過的代碼你感到疑惑時(shí)，別人也可能在同樣的地方感到疑惑。此時(shí)你應(yīng)該記錄這樣的代碼同時(shí)提交一個(gè)補(bǔ)丁。

使用文檔

文檔在一個(gè)項(xiàng)目中往往是遭到冷遇的一部分。文檔可能是以熟悉項(xiàng)目的角度來編寫的，而不是以一個(gè)剛接觸項(xiàng)目的角度。因此很多項(xiàng)目的試用文檔并沒有被重視起來。

11.創(chuàng)建一個(gè)示例

沒有一個(gè)項(xiàng)目有太多的示例，無論是web API，還是一個(gè)GUI應(yīng)用程序都沒有使用的較好的示例，也沒有可以更明顯和迅速解釋正確使用的程序的示例。對于一個(gè)API或庫，創(chuàng)建一個(gè)使用的示例程序，這甚至可以從你寫的代碼提取出來。因此我覺得創(chuàng)建一個(gè)使用的示例是非常必要的。