フリーソフトウェアユーザによるコミュニティ支援の方法
最近のLinuxディストリビューションは、限られた上級ユーザだけでなく初めてのコンピュータユーザにも使いやすいものへと変貌を遂げている。しかし、プロプライエタリなソフトウェアやオペレーティングシステムとは異なり、GNU/Linuxの開発は、自らの時間と知識を惜しまず無償でプログラムを書く人々の活動に支えられている。そのため、フリー/オープンソースソフトウェア（FOSS：Free and Open Source Software）の成否は、ユーザからのフィードバックと貢献に大きく左右される。新規のユーザやプログラミングスキルのないユーザは、貢献のしかたがわからなかったり、そもそもその必要性を理解していなかったりするだろう。しかし、プログラマでなくてもFOSSプロジェクトに大いに貢献することは可能であり、そうした活動はほかのユーザのためだけでなく自分のためにもなるのだ。もちろん、あなたにも協力できる。
まずは初心者のために簡単に背景を説明しておこう。Linuxカーネル（Linuxオペレーティングシステムの中核となるGNUソフトウェア）をはじめ、最近のディストリビューションを構成する大多数のソフトウェアドライバやアプリケーションは、フリーソフトウェアである。フリーソフトウェア財団（FSF：Free Software Foundation）では、フリーソフトウェアを 次のように定義している。
フリーソフトウェアとは、ユーザが自由に実行、複製、頒布、研究、変更、改良を行えるソフトウェアである。厳密には、次の4つの自由がユーザに与えられるソフトウェアを指す。
- 用途に関係なくプログラムを実行できる自由（第0の自由）。
- プログラムが動作するしくみを解析したり、自らのニーズに合わせてプログラムを改作したりできる自由（第1の自由）。そのための前提条件として、ソースコードが参照可能でなければならない。
- 周囲の人の助けとなるべくプログラムのコピーを再頒布できる自由（第2の自由）。
- コミュニティ全体の利益のために、プログラムを改良してその結果を公開できる自由（第3の自由）。ここでも、ソースコードを参照できることが前提条件となる。
つまり、Linuxとそのアプリケーション（の大部分）は、ソフトウェアの4つの自由すべてに基づいて作られているわけだ。4つの自由のうち2つでは、ソフトウェアの変更と公開ができる点が強調されている。こうした自由から生まれたのが、利用者に開発者となってソフトウェアの変更、改良、再頒布を行うことを促す協調的開発モデルだ。協調的なオープンソース型開発の威力は、LinuxディストリビューションをはじめとするFOSSアプリケーションが、洗練された強力な対抗馬としてプロプライエタリなソフトウェアの存在を脅かしていることからもわかる。
長年の取り組みを経て、FOSSの開発モデルはきわめて使いやすいLinuxディストリビューションおよびアプリケーションを世に送り出し、多くの新規ユーザを獲得している。しかし、FOSSの開発についてよく知らないユーザは、FOSSの使いやすさ、成熟度、機能の完成度についてさまざまな期待を抱いていることが多い。KDE 4.0のリリースに対するユーザの反応は、ユーザの期待するものが開発者の想定といかに食い違うか（翻訳記事）を示す好例だ。しかし、典型的なFOSSプロジェクトであるKDEは、ユーザからの貢献を頼りに改良に取り組んでいる。
「確かにすばらしい開発の進め方だ。でも自分にはパッチ作成やバグフィックスの方法がわからない。どうすれば役に立てるのだろうか」と思う人もいるだろう。プログラマでない人がFOSS開発への有意義な参加を果たす方法はいくつかある。特に簡単に参加できて自らにとっても非常にためになる方法として、ユーザフォーラムへの参加と、開発者への直接フィードバックの2つがある。
ユーザフォーラムへの参加
Linuxを使っていると、どこかの時点で問題に遭遇する（それはどのオペレーティングシステムでも同じことだ）。ヘルプファイルを参照したりインターネットで検索したりすると、普通は特定のディストリビューションやアプリケーションのWebサポートフォーラムに行き着く。しかし、Webフォーラムの効果は使い方次第で大きく変わってくる。曖昧な質問をして、役に立つかどうかは別にして回答をもらったのにフォローをしない、というのはよろしくない。模範的な利用には少し手間がかかるが、そのほうが質問をしたユーザもコミュニティ全体もずっと大きな恩恵を受けられる。
少し前であれば、同じような質問をするのにメーリングリストやUsenetニュースグループが利用されていた。Usenetでは、何かの方法や問題解決に関する質問に対して「マニュアルをしっかり読みなさい（RTFM：Read The Friendly Manual）」という答えが返ってくることが多かった。これは、初心者に優しい現在のディストリビューションやWebフォーラムでも通用するアドバイスだ。フォーラムで質問をする前に少し調べれば、より的確な質問ができる。次の2つの例を比べてみよう。
「力を貸してください！ Ubuntuで無線カードが使えません」
「教えてください！ Ubuntu 7.10でD-Link製WNA-2330無線アダプタが動作しません。WebにはMadWifiドライバが必要と書かれていますが、どのように入手し、設定すればよいでしょうか」
2番目の例には十分な情報が含まれていて、人々から情報をもらいやすい形になっている。
質問を投稿したら、フォローに備えること。ネットワーク関連の質問をすると、普通はifconfigやlsmodのようなコマンド出力の提示を求めるレスが付く。追加の情報を投稿することで、より熟練したユーザがその問題を診断して的確な回答をくれる可能性が高まる。
肝心なのは問題を修正したあとだ。最低でも、助けてくれた人々への感謝の気持ちを同じスレッドで伝えておこう。もっといいのは、謝意だけでなく、具体的にどのようにアドバイスに従い、その結果どうなったかを詳しくまとめて報告することだ。こうして結果を報告することには、2つの大きなメリットがある。1つは、自分のハードウェアおよびソフトウェアに特有の問題をどのように解決したかの記録が残ることだ。ファイルに保存するなり印刷するなりしておけば、同じような問題が今後起きても自力で解決できる。もう1つは、同様の問題に見舞われた人が、Webで検索してあなたの投稿を見つけ、その経験を直接活かせることだ。
ちょっとしたフォローの有無が、その後に大きく響いてくる。当初の問題を解決したことで貴重なトラブルシューティングのスキルが得られるだけでなく、そのあとほんの少し手間をかけるだけでコミュニティ全体に貢献できるわけだ。やがては、自分自身が有益な助言をする側の1人になっていく可能性もある。
直接的なフィードバック
貢献のもう1つの方法が、プロジェクトに直接フィードバックを返すことだ。開発者は参考になる有益なフィードバックを求めている。彼らが本当に知りたいのは、自分たちのソフトウェアがどのように使われているか、またユーザがどんな問題を抱え、どんな機能を求めているかである。不具合や機能についてのオープンな議論はFOSS開発の基本であり、プログラマ以外の人々が大きな影響力を発揮できる領域の1つだ。
プロジェクトの規模によっては、プログラムの作者にメールやフォーラムの投稿を届けるだけの簡単なバグトラッキングを行っているところもある。より大きなプロジェクトでは、Bugzillaのようなバグトラッキングソフトウェアを利用している。問題の原因になっていそうなプログラムの不具合についてWebで調べると、そうしたバグトラッキングシステムのサイトにたどり着くことが多い。KDE、GNOME、Ubuntu、Scribusなどについては、バグレポート記入用のページがすぐに見つかるだろう。大事なのは、既存のバグデータベースを検索して、同じバグがすでに報告されていないかを確認することだ。検索すれば、自分の遭遇したバグが修正済みでパッチが利用できるかどうかもわかる。一般に、大規模で利用頻度の高いプロジェクトほど、バグレポートが多い。
検索しても同様のバグに関する記録がなかった場合は、コミュニティのガイドラインに目を通してバグレポートを提出する。たとえば、Mozillaのバグ報告ガイドラインには、次のように記されている。
適切なレポートのあったバグは、ほぼ間違いなく修正されます。バグレポートの書き方については、以下のガイドラインを参照してください。
- 正確であること
- 明瞭であること ― ほかの人がバグを再現できるように書く
- 1つのレポートにバグは1件のみ
- どんな些細なバグも報告すること ― 小さなバグに大きなバグが隠れていることがある
- 事実と推論をはっきり分けて書くこと
バグを報告すると、問題の再現またはパッチのテストのために追加の作業を頼まれることがあるが、こうした機会をなるべく活用すること。トラブルシューティング、パッチのテスト、問題の修正について大いに学ぶところがあるだろう。ユーザフォーラムへの参加と同じく、バグレポートの提出は自分のスキルを高めると共に、ほかのユーザにも寄与できるすばらしい方法だ。
次なるステップ
Linuxについて多くを学ぶほど、より大きな貢献ができるようになる。あるアプリケーションに十分詳しくなったら、そのアプリケーションに関するWikiへの貢献や、ハウツー記事の執筆を検討するとよい。良質なドキュメント、とりわけユーザの視点で書かれたものは、常に求められている。お気に入りのアプリケーションまたはディストリビューションでテスト用のダウンロードファイルが公開されたら、入手して積極的に不具合を探してみてほしい。さらに、プログラミングとスクリプト作成についても少し学んでみてはどうだろう。プログラマでなくても、関数や変数の働きは十分に理解できる。また、こうした知識を身につければ、フォーラムへの投稿やバグレポートがより価値のあるものになる。
FOSSの開発は、開発者とユーザの貢献に支えられている。Linuxがより使いやすく支持されるものになるにつれ、一般ユーザが利用ソフトウェアのオンラインコミュニティに参加して開発者に協力することがますます重要になってくる。
Drew Amesはペンシルバニア州ハリスバーグの輸送プランナー。
