実際、オープンソースに貢献する方法は無限にあり、簡単な方法の 1 つは投票の質問に答えることです。

オープンソースへの貢献にどのように参加していますか？アンケートを実施したところ、次のような結果が出ました。

• エラーレポートを送信する - 67票（35%）
• ユーザーの質問への回答 - 39票（20%）
• ライティング（ガイドライン、ストーリー、ドキュメントなど） - 73票（38%）
• その他 - 12票（6％）

私が初めてオープンソースに貢献したのは、1980 年代半ば、私たちの組織が初めて UseNet に接続したときでした。そこで、開発とサポートの過程でコードを貢献し、それを他のユーザーと共有する機会を発見しました。

今日、オープンソースに貢献する機会は無限にあります。コードの提供でも、ビデオチュートリアルの作成でも、これらはすべて貢献の方法です。

ただし、コードの貢献に関するセクションは省略します。確かに、コードを書いていても自分を開発者だとは思っていない人も多く、彼らもコードを貢献することは可能です。しかし、オープンソースに貢献する方法はコード以外にもたくさんあることを強調しておきたいと思います。以下では、そのうち3つについて解説します。

エラーレポートを送信する

貢献の重要な具体的な形は、「適切なバグレポートを提出することを恐れないこと」と、それに伴うあらゆる結果です。適切なバグレポートを提出することは、時には非常に困難な場合があります。例えば：

• エラーによっては、ログに記録したり説明したりするのが困難な場合があります。コンピュータの起動時に、画面に様々な理解しがたいコードを含む長く複雑なメッセージが表示されることがあります。あるいは、具体的なエラー情報が提供されずに、何らかの「異常な動作」が画面に表示されることもあります。
• 一部のエラーは再現が難しい場合があります。特定のハードウェア/ソフトウェア構成でのみ発生する場合や、まれにしか発生しない場合、あるいはエラーが発生する状況が不明瞭な場合があります。
• 一部のエラーは、非常に特殊な開発環境の設定に関連している可能性がありますが、この設定は複雑すぎて共有できません。まずは簡略化された例を作成する必要があり、多大な労力を要します。

ディストリビューションにバグが報告されると、メンテナーはそれをアップストリームに送信することを提案することがありますが、ディストリビューションによって提供されるバージョンがアップストリーム コミュニティが関心を持つメジャー バージョンではないため、これは時には非常に面倒な作業になることがあります。(これは、ディストリビューションによって提供されるバージョンが、公式にサポートされているリリースや開発バージョンよりも遅れている場合に発生します。)

それでも、潜在的なバグ報告者（私自身も含む）には努力を続け、バグが完全に文書化され、確認されるように努めるよう奨励します。

でも、どうやって始めればいいのでしょうか？お気に入りの検索ツールを使って、類似のバグレポートを探し、その説明やアーカイブ場所などを確認することができます。また、使用しているディストリビューション（Fedora、openSUSE、Ubuntuなど）やパッケージ（LibreOffice、Mozillaなど）のバグ報告ページをチェックするのも良いでしょう。これらのページには、関連するバグを報告するための正式な報告メカニズムが定義されています。

ユーザーの質問に答える

私は様々なメーリングリストやフォーラムに潜入しており、Ubuntu品質管理チームとフォーラム、LinuxQuestions.org、ALSAユーザーメーリングリストなど、時折顔を出して自分の考えを共有しています。ここでの私の貢献は、バグ報告というよりも、複雑なユースケースのドキュメント化が中心かもしれません。しかし、誰かが熱心に他の人を助け、問題を解決しているのを見るのは、間違いなく誰にとっても素晴らしい経験です。

オープンソースについて書く

最後に、私が本当に貢献したいと思っているもう一つの分野は、オープンソースソフトウェアの使い方に関する記事の執筆です。ユーザーガイド、特定の問題に対する様々なソリューションの比較評価、あるいは単に興味のある分野全般（私の場合は、オープンソースの音楽プレーヤーソフトウェアを使って音楽を楽しむこと）の探求など、様々な記事を書くことができます。似たような方法として、チュートリアルビデオの作成があります。複雑な操作（GIMPで凝ったロゴを作成するなど）を説明しながら、デスクトップを録画するのは簡単です。また、2言語以上に精通している方であれば、既存のユーザーガイドやビデオを他の言語に翻訳することも選択肢の一つです。