現在非常多的人都想涉足開源的，但不知道從什么地方入手。這里有幾種方法可以幫幫忙，即使你缺乏信心，你但仍然能夠讓你挑起技術大梁。
開源軟件改變了計算乃至整個世界，也許你也想為這樣一件事做出貢獻。但不幸的是，很多人認為參與這樣的項目具有很高的門檻。我經常聽到人們說，他們很樂意貢獻但不能的原因有三個：
我從開源代碼的新手中觀察到最有害的想法是，想要做一名優秀的有貢獻的開源編程人員必須具有極高的天賦，這是不正確的。當然，還有那些在開源世界誰被認為是搖滾明星的，他們可能確實是天才程序員。然而，我們中的絕大多數都不是，但我們仍然為改變世界做著自己的貢獻。
在開源代碼的一切涉都及到其他人。如果你想加入一個團隊，這意味著了解社會，了解它是如何工作的。進入一個項目中，并說：“這是我認為這個項目應該做的事”，這通常不視為一件好事。有些項目可能會喜歡這樣的想法，但是如果項目已經運行了一段時間，那這種態度被接受的可能性就很小。聽是要知道這個項目需要以什么樣加入方式為最佳。
對于許多項目，郵件列表都是關于項目開發溝通的主要渠道。在大型項目中，有許多郵件列表可供選擇。例如，PostgreSQL的項目有不少于12個面向用戶的列表和6個開發人員的郵件列表。我建議主要從面向用戶的列表和核心開發者的郵件列表開始聽。
由核心開發人員維護的博客往往會給出在將來的版本當中出現的一些信息，以及什么時候能夠得到那些信息等等。
很多開源項目都有專門的互聯網中繼聊天（IRC）的渠道，開發人員和用戶掛出問題以及討論項目的進展等等。
代碼是任何開源項目的核心，但編寫代碼并不是幫助入門的唯一途徑。代碼以及周圍代碼系統的維護通常都容易被忽視，這些地方不僅能修正錯誤而且能夠創新功能，可以從這些地方入手來參與一個項目。
診斷和篩選一個錯誤可以幫助開發人員節省更多的時間來找出問題的細節。如果用戶反映到，“當我做x工作的時候軟件不工作”，那么這時候你應該檢查這個問題的細節。是否這個問題是重復的，如果是你可不可以創建一組解決這類問題的步驟，將此類問題縮小。即使你不知道是什么原因造成的問題，你可以把問題的范圍縮小從而減少其他人員解決問題的時間。
錯誤往往是固定在代碼庫的，清理這些東西可能非常的耗費時間，但是對整個項目非常有價值。檢查項目發布的更改日志，看看錯誤是否是固定的，如果是可固定的，注意版本號并將其關閉。
所有有經驗的程序員都可以在整個項目的代碼當中起到很大的作用，你不必認為只有天賦異稟的程序員才能對項目起到作用。每個項目都有自己的工作流程,所以在提交代碼之前詢問清楚如何做。當你修改代碼時，請確保你作為項目當中的一員，并保持你的代碼風格和代碼庫的其他代碼是相匹配。
任何項目運行在多個平臺都可能遇到各種各樣的兼容性問題。當測試版或候選版發布后，該項目負責人希望它會由很多不同的人在不同的平臺進行測試，你可以負責這個工作來幫助項目能夠順利的完成。
這通常都是代碼工作者剛開始想從事的工作，這很簡單：在interesting-sounding系統中找到錯誤并且嘗試修復代碼，并檢查代碼的放置是否合適。同時添加測試的套件來測試那些固定的代碼。有些項目需要bug修正并且測試。
大多數項目都有一個測試套件的測試代碼，但很難想象一個測試套件不能附加給它更多的測試。使用類似于gcov或者C的測試工具來檢測到未通過測試套件的源代碼領域，然后添加一個測試套件來掩蓋它。
構建許多以C為基礎的項目往往會在屏幕上出現奇怪的編譯器警告標志。這些警告通常是沒有問題的指向的，這時你應該檢查是否該代碼實際上有隱藏的錯誤。
當你開發過的代碼你感到疑惑時，別人也可能在同樣的地方感到疑惑。此時你應該記錄這樣的代碼同時提交一個補丁。
文檔在一個項目中往往是遭到冷遇的一部分。文檔可能是以熟悉項目的角度來編寫的，而不是以一個剛接觸項目的角度。因此很多項目的試用文檔并沒有被重視起來。
沒有一個項目有太多的示例，無論是web API，還是一個GUI應用程序都沒有使用的較好的示例，也沒有可以更明顯和迅速解釋正確使用的程序的示例。對于一個API或庫，創建一個使用的示例程序，這甚至可以從你寫的代碼提取出來。因此我覺得創建一個使用的示例是非常必要的。
