事實上，有無窮無盡的方法來為開源做貢獻，其中一個簡單的方法就是回答我們的投票問題。

你是如何參與開源貢獻的呢?我們組織了一個投票，結果如下：

• 提交錯誤報告 - 67 票(35%)
• 解答用戶的問題 - 39 票(20%)
• 寫作(指南、故事、文檔等) - 73 票(38%)
• 其他 - 12 票(6%)

我的第一次開源貢獻可以追溯到 20 世紀 80 年代中期，當時我們的機構第一次連上了 UseNet，在那里我們發現了貢獻代碼，以及在其開發和支持過程中和別人分享的機會。

在今天，我們有無盡的貢獻開源的機會。無論是貢獻代碼，還是制作一個視頻教程，都是貢獻的一種途徑。

不過，我將直接跳過整個貢獻代碼的部分。誠然，我們中有許多寫代碼但不認為自己是開發者的人，他們也可以 貢獻代碼。但是，我更想提醒大家，還存在很多 非代碼形式可以貢獻開源。接下來，我會談到其中的三種。

提交錯誤報告

有一種重要而具體的貢獻形式，它可以被描述為“不要畏懼 提交一個像樣的錯誤報告”以及 與此相關的所有后果。有時，要 提交一個像樣的錯誤報告 是很有挑戰性的。比如說：

• 某些錯誤可能很難記錄或描述。當計算機啟動時，屏幕上可能會出現又長又復雜的信息，其中包含各種不能理解的代碼。或者屏幕上可能顯示有一些“異常行為”，但是卻沒有提供具體的錯誤信息。
• 某些錯誤可能很難重現。它可能只發生在某些特定的硬件/軟件配置上，或者它可能很少被觸發，或者錯誤的產生場景不明確。
• 某些錯誤可能與一個非常特殊的開發環境配置有關，但是這個配置龐雜混亂，無法分享，需要先耗費大量精力創建一個精簡后的例子才行。

當向發行版報告一個錯誤時，維護者可能會建議將該錯誤提交給上游，這有時會需要付出大量的工作，因為發行版所提供的版本不是上游社區感興趣的主要版本。(當發行版提供的版本落后于官方支持的發布和開發版本時，就會有這種情況發生)。

盡管如此，我還是鼓勵那些潛在的錯誤報告者(包括我)繼續努力，并嘗試讓錯誤得到完整的記錄和確認。

但如何開始呢?你可以使用你最喜歡的搜索工具尋找類似的錯誤報告，看看它們是如何描述的，它們被歸檔在哪里，等等。你也可以留意你使用的發行版(例如，Fedora、openSUSE、Ubuntu)或軟件包(LibreOffice、Mozilla)的錯誤報告頁面，它們定義了正式的報告機制，你可以按步驟為他們報告相關錯誤。

解答用戶的問題

我潛伏在各種郵件列表和 論壇 里，偶爾也會冒個泡，例如 Ubuntu 質量控制團隊 和 論壇、LinuxQuestions.org，以及 ALSA 用戶的郵件列表 等。在這里，我的貢獻可能與錯誤報告的關系不大，更多的是記錄復雜的用例。不過，看到有人熱心幫助他人，解決他人在某個問題上的遇到的麻煩，對每個人來說，這都是無疑一種很棒的體驗。

從事開源相關的寫作

最后，另一個我非常喜歡貢獻的領域是 撰寫 關于使用開源軟件的文章。無論是使用指南，還是對某一特定問題的不同解決方案進行比較評估，或者只是籠統地探索一個感興趣的領域(就我而言，是使用開源音樂播放軟件來享受音樂)。一個類似的選擇是制作一個教學視頻。你很容易就可以做到邊演示一些復雜的桌面操作(比如用 GIMP 創建一個絢麗的標志)，邊錄制桌面。而那些精通兩種或多種語言的人，也可以考慮將現有的使用指南或視頻翻譯成另一種語言。