華やかな開発を支える無視されがちな活動：オープンソースソフトウェアの育て方（3/3 ページ）

[Karl Fogel， ]

マーケティング

　ほとんどのオープンソースプロジェクトの開発者は認めたがらないでしょうが、マーケティングは役に立つものです。マーケティング活動をうまくやれば、頭の固いプログラマーが理由もよく分からないのに、そのソフトウェアに対して良い印象を持つくらいにまで、オープンソース界隈の評判を作り出すことができます。ここでは、マーケティングにおける競争力学を一般的に分析するわけではありません。フリーソフトウェアの世界にかかわっている企業は結局、企業自体や、ソフトウェア、そしてソフトウェアと企業の関係をどうやって売り込んでいくかを考えるようになります。以下では、こうした努力をするに当たって陥りがちな一般的な落とし穴について解説します。章6.コミュニケーションの宣伝・広報項も参照してください。

見られていることを意識する

　ボランティアの開発者コミュニティーをあなたの味方につけるには、はっきりしていない事柄はしゃべらないことがとても重要です。すべての主張を公にする前に注意深く調べ、その主張自体をチェックする手段も公にしておきます。独自に事実を検証できるのは、オープンソースの重要な部分です。それはコード以外の部分にも当てはまります。

　当然ながら、検証できない主張をするなと企業にアドバイスする人などいません。しかし、ことオープンソースの活動では、主張を検証する経験に長けた人が非常に多くいます――なぜなら、広い帯域のインターネット接続回線を持ち、物事を中傷するために社会的接触を持つ可能性がある人が大勢いるからです。化学工業の巨大企業が川を汚染している場合、それは検証可能ですが、検証できるのは訓練を受けた科学者のみです。彼らは巨大企業の科学者から反論され、頭をかきむしってどう考えたらよいのか困惑するかもしれません。一方で、オープンソースの世界であなたがすることは、目に見える形で記録されるだけではありません。多くの人が独立してチェックし、独自の結論を下し、それらを口コミで広めていくのです。この口コミのネットワークは既に定着しているものです。つまり、オープンソースがどのように影響するかを決める要素であり、あらゆる種類の情報を伝えるのに使われます。反論は不可能ではないにしても、特に人々が言っていることが事実である場合は、普通難しいものです。

　例えば、“プロジェクトXを作った”とあなたの組織が言うのは、実際にそうしたのであれば問題ありません。しかし、実際にコードを書いたのが外部の人間である場合、“Xというソフトウェアを作った”といってはいけません。逆に、誰かがリポジトリの中身を覗いてみて、あなたの組織以外の人が変更を加えた跡がほとんどまたはまったくない場合は、ボランティアの開発者コミュニティーが深く関与していると主張してはいけません。

　それほど昔のことではありませんが、とてもよく知られているコンピュータ会社が、重要なソフトウェアパッケージをオープンソースライセンスの下で公開した、というアナウンスを見ました。はじめのアナウンスが出た後、わたしは公開されているバージョン管理システムのリポジトリを見てみましたが、そこには3つのリビジョンしか存在していませんでした。言い換えれば、彼らはソースコードのインポートを終えたこと以外は何もしていなかったのです。それ自体は変なことではありませんでした――だって結局彼らはアナウンスしただけですから。しかし、すぐに活発な開発が行われると期待する理由は何もなかったのです。

　しばらくたってから、別のアナウンスがありました。以下にそれを示しますが、リリースナンバーとソフトウェアの名前は別のものに置き換えてあります。

Singerコミュニティーによって厳密にテストされた後、Singer5のLinux版とWindows版が、製品としての使用に耐える品質になったことを発表します。

　「厳密なテスト」によってコミュニティーが明らかにしたことを知りたいと思い、わたしはリポジトリを再度見に行って最近の変更履歴を覗いてみました。プロジェクト自体のリビジョンは3のままでした。明らかに、コミュニティーはリリース前に修正すべきバグを1つも見つけていなかったのです。コミュニティーによるテスト結果がどこかに記録されているはずだと考えて、わたしは次にバグ追跡システムを調べてみました。そこには確かに6つの問題が記録されていましたが、そのうちの4つは数カ月の間保留状態のままだったのです。

　これはもちろん信じがたいことです。テスターが巨大かつ複雑なソフトウェアをそれなりの時間使えば、彼らはバグを見つけるものです。たとえそうしたバグが次回のリリースに取り込まれなかったとしても、テストの結果としてバージョン管理システム上での活動か、新しい問題がバグ追跡システムに登録されていると期待されるはずです。しかしながら、どこを見ても、はじめのアナウンスと、その次のアナウンスとの間に活動の跡はみられなかったのです。

　問題は、コミュニティーがテストしたことについて、企業がうそをついたことではありません。コミュニティーがテストしたかどうかはわたしには分からないからです。しかし、彼らが言っていることがどれくらいうそっぽいかは明らかでした。バージョン管理システムだけでなく、バグ追跡システムにも、厳密なテストが行われたことを示す痕跡はなかったので、企業はコミュニティーがテストしたという主張をしないか、目に見える形のテスト結果へのリンク（“278個のバグが発見されました。詳細はここをクリックしてください”）を提供すべきでした。後者は誰でもコミュニティーの活動レベルを素早く把握できるようにするものです。実際は、コミュニティーがテストしたことを探すのに2、3分しか掛かりませんでしたし、普通なら記録される場所に、テストの痕跡がまったく残っていなかったのです。検証するのにたいした手間は掛かりませんでしたが、手間を掛けたのはわたしだけではないはずです。

　透明性と検証可能性は、正確なクレジットを与えるときももちろん重要です。詳しくは、章8.ボランティアの管理のクレジット項を参照してください。

競合するオープンソースプロジェクトを攻撃しない

　競合するオープンソースプロジェクトについて、否定的な意見を述べるのはやめましょう。否定的な事実についてはいっこうに構いません――容易に裏が取れる主張は、比較の要素としてよく見られるものだからです。しかし、あいまいな事柄に対して否定的な評価を行うことは避けた方が良いでしょう。

　理由は2つあります。まず、それがきっかけで建設的でないフレームウォーが起こりがちだからです。2つ目は、もっと重要なことですが、あなたのプロジェクトにいるボランティアの開発者の中からも、競合プロジェクトで働く人が出る可能性があるからです。前者より、後者の方が多く発生する可能性が高いです。なぜなら、それぞれのプロジェクトは既に同じ専門領域に属していて（それゆえに競合関係にあります）、その領域で専門知識を持っている開発者は、それを生かせる場所であればどのプロジェクトでも貢献してよいからです。直接的には開発者が重複していない状況でも、あなたのプロジェクトにいる開発者が、関連するプロジェクトの開発者を知っている可能性があります。彼らの建設的な人間関係を維持する能力が、否定的なマーケティングのメッセージによってすべて壊れてしまう可能性だってあるのです。

　ソースコードが公開されていない競合プロジェクトを攻撃することは、特にその製品がMicrosoft製である場合は、オープンソースの世界では広く受け入れられています。個人的には、この傾向は（単刀直入に事実を比較するのであればいっこうに構わないのですが）残念に思っています。なぜなら、これは相手に失礼であるからというだけでなく、プロジェクトが自ら作っているものの誇大広告を信じ、それゆえに競合相手が実際に優れている点を無視し始めるのが危険でもあるからです。

　一般的には、マーケティングのメッセージが、自分たちの開発コミュニティーにも影響を与えるものかどうかを注意しておくとよいでしょう。マーケティングにお金が使われると、開発者は自分たちのソフトウェアが持っている本当の強みや弱点を、客観的な眼で見なくなってしまいます。このため、企業の開発者はマーケティング上のメッセージに対して、公のフォーラム上でさえある種無関心な態度を示すのが普通ですし、むしろそれが期待されています。はっきりしているのは、企業の開発者はマーケティングによるメッセージに対して、公の場で矛盾した態度を直接示してはいけない（ただし、それが実際に間違っているというのなら別ですが、その手の事実は早い段階から分かることでしょう）ということです。企業の開発者はそうしたメッセージをネタとして扱い、コミュニティーをマーケティングのメッセージから現実に引き戻す手段にしているのです。

著者：Fogel Karl

翻訳者：高木 正弘

翻訳者：Takaoka Yoshinari(a.k.a mumumu)

製作著作 © 2005, 2006, 2007, 2008, 2009 Karl Fogel, 高木正弘, Yoshinari Takaoka(a.k.a mumumu), under a CreativeCommons Attribution-ShareAlike (表示・継承) license (3.0, 2.1-jp)

よいフリーソフトウェアを作ることは本質的に価値のある目標です。その方法を模索している読者の皆さんが、本連載「オープンソースソフトウェアの育て方」で何かのヒントを得てくだされば幸いです。

原文へのリンク