SourceForge.JP: Open Source Software

明らかに、アップルの広報部門は優秀であり、アップルにとって掛け替えのない存在である。アップルが製品を市場に投入するときには、決って、CEOであるSteve Jobsを登場させる。そして、新製品の優れた点について説明させるのだ。それは、ユーザーが理解できる程度に簡潔であり、報道関係者が記事を書ける程度に平易である。これに対して、十分な広報活動を行っているオープンソース・プロジェクトは皆無に近い。

たとえば、GNOME 2.8のリリース・ノートを見てみよ。退屈な言葉が長々と並んでいるだけで、肝心の特徴は一言も出てこない。私はこのリリース・ノートを読んでみたが、正直言って、GNOME 2.8にする必要性が理解できなかった。単に2.6のバグを潰しただけではないのか。それだけのことなら、リリース番号を改めるだけの価値はないだろう。

一例だけでは公平とは言えないだろうから、KDE 3.3の発表文も見てみよう。説明されている特徴の数はGNOMEより多いが、その記述に達する前に、専門用語風の無意味な言葉が延々と続く。それはGNOMEより遙かに長く、「この製品は賞を受けたこともある」などといった空疎な常套句が並んでいる。さらに、どちらのプロジェクトの場合も、前版からの些細な変更点を大げさに取上げている。

これに対して、Mozilla Firefoxのトップ・ページはユーザーの関心を引きそうな点を明確に列挙しており、ユーザーにとって有用かつ魅力的にできてる。無駄な自画自賛などなく（受賞の有無に関心を持つユーザーがいるだろうか。少なくとも私は知りたいとは思わない。私が知りたいのは、それが自分に役立つかどうかである）、肝心な点を射抜いている。

ほとんどのオープンソース・プロジェクトで、こうした点に改善の余地のあることは否定できない。Robin Millerが2004年4月に書いた広報活動を指南する記事"Getting good PR for your open source project"は広報の基礎をわかりやすく説明しており、参考資料へのリンクも多い。

オープンソース・プロジェクトの関係者は広報についてもっと勉強し、魅力的な報道発表文を書けるようにすべきである。Steve Jobsに学ぶことも多い。以下、アップルが行う製品発表の神髄を見てみよう。

タイミングが重要

製品の発表によって噂サイトが立ち往生するほどの圧倒的な旋風を巻き起こす鍵は3つある。すなわち、発表まで秘密にすること、複数の製品を同時に発表すること、「ビッグイベント」――MacWorld Exposディベロッパー・カンファレンス――の会場で発表すること。

もちろん、機密保持契約を身にまとった商用ソフトウェアハウスとは異なり、オープンソース・プロジェクトはその身をベールに包むことはできない。それはオープンソース開発モデルに矛盾するからだ。しかし、他の2つは容易に実践できる。

たとえば、エキスポを開催する。こうしたイベントは今でもマスコミに取り上げられているが、ほとんどの場合は熱気に欠け、記事にしようにも材料を探し回らねばならない体たらくだ。主要な技術系メディアにとってLinuxエキスポの多くが魅力に乏しいのは、大きな記事になるだけの話題がないからだ。しかし、そうしたイベントでGNOME Foundationなどの主要プロジェクトが一斉に新リリースを発表したとすれば、話題を求めるマスコミにとって格好の材料となるだろう。

少しあざといと思うかもしれない。確かに、カーネルなどは、マスコミ対策でリリースを急いだり遅らせたりすべき性質のものではない。しかし、FedoraやOpenOffice.orgなどのプロジェクトではリリースする機能を自由に選ぶことができ、したがってリリースの時機は基本的に任意である。主要なLinuxエキスポに合わせて新しいリリースを発表すれば、手間をかけずに無償で広報でき、プロジェクトを推進することができるだろう。

同時リリース

アップルがイベントで新製品を発表する際、製品が1つだけということは滅多にない。たとえば、新しいiPodと新しいマックとソフトウェア2本を同時に発表したことがあった。これも計算ずくで、確実な広報効果を狙ったものだ。4つの新製品が同時に発表されれば記事になる。しかし、新製品が1つだけでは記事の見出しを飾るかどうかは賭である。

これに倣い、複数のオープンソース・プロジェクトが共同してメジャー・アップデートを同時にリリースすれば、主要メディアが大きく取り上げるだろう。最近の例で言えば、GIMPの新バージョンをLinuxWorldで発表しても、メディアの一面を飾るチャンスは大きくはない（OSTGのサイトぐらいのものだろう）。一方、GIMPとInkscapeとBlenderの新リリースが揃い踏みすれば話題性は大きく、したがってマスコミに取り上げられる可能性は高くなるだろう。

同時発表するのは、関連アプリケーションである必要はない。Mozilla FoundationのThunderbirdとOpenOffice.orgの次期リリースを同時に行えば、個別にリリースするよりも、ニュース価値は高くなる。個別のニュースを合わせれば、そのニュース価値は、それぞれのニュース価値の総和よりも大きくなるのである。

イベントに合わせて同時にリリースすれば、個々のプロジェクトにとっても利点があるはずだ。おそらく、スケジュールはコードの進捗によるべきであり、それ以外のものに引きずられるのはオープンソースの精神に反すると言う人もいるだろう。しかし、リリース・スケジュールを調整しても、現実には何も変わらない。「.0」の正式リリースを待ってソフトウェアをダウンロードする人は、どちらにしても開発プロセスに参加しているわけではない。また、開発プロセスに参加している人は、公式リリースには頓着しない。すでに、テスト・バージョンを入手し使っているからである。

関心を広く集めるためにリリース日を調整したとしても、一点を除いて何も変わらない。その一点とは、関心を寄せる人々の人数である。そうして集まった新しいユーザーはバグを見つけて報告し、開発プロセスに自ら参加することになるだろう。

製品とプロジェクト

製品の広報は、プロジェクトの広報より容易である。「製品」という言葉には、棚から取り出して買える状態にあるという含みがある。一方、「プロジェクト」は何かが進行中であることを意味し、おそらくは次々に変更された挙げ句に未完で終わるということを暗示する。しかし、この2つには言葉以上の違いがある。つまり、あるソフトウェアをプロジェクトとして見るのと製品として見るのとでは、問題が異なるのだ。プロジェクトには要件・バグ・リビジョン・開発日程といった属性がある。一方、製品には市場があり、広報活動を必要とする。生き残るには売らなければならないのだ。

アップルのようなクローズドソース・ベンダーなら実現は容易で、新開発した製品を一度に発表することができるだろう。これは確かだ。しかし、Linuxシステムでは、対応するソフトウェアの改良版は、独立かつバラバラに数か月間にわたって登場してくる。今日はX.org、明日はTrolltechといった具合だ。

しかし、だからといって、オープンソース・プロジェクトが、アップルなどと全く同じように、コードを製品として捉えてソフトウェアを拡販すること――報道向けの発表を用意し、リリース・イベントを開催し、広報対策を行うこと――が不可能なわけではない。Mozilla Foundationは、すでに、それが可能であることを示している。FirefoxとThunderbirdの協調マーケティングに成功しているのだ。つまり、問題は、他のプロジェクトが先達に倣うかどうかにかかっているのである。

原文