解決法を探す
大規模で人気のあるプロジェクトの開発者たちは、このような状況下でジレンマを抱えることになる。つまり、上記のようなユーザの不満がある一方で、ほとんどのフリーソフトウェア開発者たちの興味の対象は機能の追加や拡張だということがある。彼らも時々は、効率のためにコードの整備的な作業も行わないではないが、その作業によってソフトウェアが向上しなければ、開発者のプライドや興味の観点から作業の対象にはなり得ない。しかしこのような開発者の求めるところは、声高なユーザが求めるところとは相容れないのかもしれない。
では開発者たちはどうすれば良いのだろうか。昔ながらのハッカーのように「それなら自分でコードを書け」と叫ぶのは正しい答えではないだろう。またユーザを無視することもできない――不満を持ったユーザは単に、プロジェクトのメーリングリストに投稿してプロジェクトを攻撃したうえ、ブログ上で大げさな熱弁を振るうことになるだけだろう。意見を主張するためのフォーラムが見つからなければ、どこかのフォーラムを乗っ取るだろう。そうしてほどなく、コア開発者はプログラミングよりも批判への応対により多くの時間を費やさなければならなくなってしまうだろう。
とは言え、不平や不満に屈するというのも同じくらい正しくはない選択肢だ。最近の大抵のデスクトッププロジェクトはユーザのフィードバックに注意を払うように努力しているが、変化を望まない人々によるフィードバックについては、聞く耳を持つ程度で十分だろう。開発活動の内容がバグ修正だけになってしまえば、開発者はいなくなってしまう。
ではどうやって解決すれば良いのだろうか。例えば一つのアイデアとして、ユーザが圧倒されてしまわないように、変更を導入する際にはもっと時間をかけるというのはどうだろうか。あるいは、開発段階からのユーザの参加をもっと促して、プロジェクトの目標をより明確に伝えていくというのはどうだろうか。
大規模なFOSSプロジェクトは次のような点に注意すべきだ。ユーザが変更を受け入れることを前提とすることは今やできなくなった。そればかりかむしろ多くのユーザがさかんに反発したり、あり得ないほど敵対的な反応をしたりすることがあるという現実を受け止めることができるようになる必要があるのかもしれない。そのようなことが起こる可能性を無視していると、あなたのプロジェクトも現在のKDEと同じような難局に陥ってしまうかもしれない。
Bruce Byfieldは、Linux.comに定期的に寄稿するコンピュータジャーナリスト。