コンピュータベンダーからメーカーまで、ほぼすべての企業がオープンソースコミュニティへの参加に躍起になっています。しかし、多くの企業が失敗し、コミュニティに幻滅しています。デイブ・ニアリー氏は、こうした失敗を研究することで、私たちに何ができ、何ができないかを教えてくれる教訓をまとめました。現在、オープンソースソフトウェアコミュニティの開発者は、カジュアルな服装をしたギークだけでなく、評判の良いLinux企業の従業員も含まれています。以下の結論は、これらの事実に基づいています。

Linuxカーネルコードに貢献している企業に関する最近の分析では、Novell、IBM、Intel、Nokia、Texas Instrumentsといった企業がオープンソースソフトウェア開発に正式に関与していることが結論付けられました。また、LiMo Foundationはメンバーに対し、アップストリームのコミュニティプロジェクトへの参加を奨励しています。これは、孤立するのではなく、コミュニティと協力することで、数百万ドルもの資金が潜在的な影響なしに無駄に浪費されるのを防ぐことができることを示唆しています。

オープンソースプロジェクトの長期的な存続には、コミュニティ開発者の多様性が不可欠です。しかし、企業が権限を委譲してしまうと、コミュニティ開発者をそれぞれのプロジェクトに集中させたり、コミュニティメンテナーの開発方向性に影響を与えたりすることが難しくなります。LinuxカーネルとGNOMEがその好例です。誰もが協力し、誰も支配することはありません。SunとAOLはコミュニティ開発を全面的に受け入れましたが、コミュニティ開発者との相互に有益な関係を築くことができませんでした。他にも多くの例があります。企業がコミュニティ開発に実験的に参加しただけで、その後孤立したり、コミュニティ開発への多額の投資を放棄したりするケースは滅多にありません。もちろん、反例もあります。例えば、Xaraは2005年にコアLinux製品「Xara Xteme」の一部をオープンソース化しましたが、2006年後半にはコミュニティプロジェクトへの投資をひっそりと放棄しました。

一体どこで間違いが生じたのでしょうか？企業が投資戦略を地域開発へと転換する際に、最も多く犯しがちな、そして致命的なミスは何でしょうか？どうすればこれらを避けることができるのでしょうか？そして、これらのミスを避けたからといって成功が保証されるわけではありません。ただ、彼らのような失敗を防げるだけです。

どこから始めましょうか?

オープンソースに対して過度に高い期待を抱き、盲目的かつ性急にオープンソース プロジェクトに参加することは、企業が犯す最も一般的な致命的な間違いです。

オープンソースソフトウェア開発の歴史は、商業企業がコミュニティ開発に当初失望した物語で溢れています。中には、自分たちのチームが何ヶ月もかけて開発した機能をコミュニティプロジェクトが受け入れない理由が理解できないテクニカルリーダーもいました。経営陣は、製品のリリース時に外部の開発者がすぐに追いつくことを期待することさえありました。クリス・グラムズ氏はかつて、この問題はコミュニティエンゲージメントにおける「製材所のトム」モデルに起因すると述べました。これは、企業が常に他者に仕事を任せようとするものです。まず、こうした罠に陥らないように注意しましょう。

優れたコミュニティソフトウェアを構築するには忍耐が必要です。すべてをうまくできる時もありますが、それでもうまくできないことがいくつかあるものです。

では、どこから始めれば良いのでしょうか？コミュニティ開発に取り組む前に、まず本当に何を達成したいのかをじっくり考える必要があります。オープンソースは、製品の成長、リリースチャネルの拡大、そして最終的には業界のリーダーシップ獲得に貢献できるでしょうか？システム開発者をプラットフォームに取り込む必要があるでしょうか？コスト削減のために既存のオープンソースプロジェクトを製品に取り入れる必要があるでしょうか？それとも、ニーズを満たすために独自のプロジェクトを開発する必要があるでしょうか？これらすべての目標、つまりオープンソースプロジェクトに参加する理由を実現するには、成功を左右する具体的な戦略とツールが必要です。実際、成功は目標次第なのです。

一般的な選択肢は 2 つあります。企業が既存のオープンソース コミュニティに参加するか、自社製品に関連する独自のコミュニティを構築するかのいずれかです。

コミュニティに参加する

コミュニティに参加し、信頼と評判を得るには忍耐が必要です。コミュニティ活動に参加する前に、まずコミュニティの組織構造を理解する必要があります。リーダーは誰で、彼らの優先事項は何でしょうか？コミュニティの文化があなたのビジネス目標と一致していない場合、参加するかどうかの判断に間違いなく影響を与えるでしょう。

自分の目標と合致する（あるいは少なくとも全く異なるわけではない）仕事を見つけたら、熱心に取り組み始めるべきです。例えば、HPは早い段階からLinuxのサポートを開始しましたが、これは自社のプロプライエタリUnix-HPUXのサポートの一環でもありました。10年後、HPが販売するLinuxサーバーの40%をLinuxサーバーが占めるようになりました。一方、2005年、Sunは独立したコミュニティを立ち上げ、GPL準拠（Linuxカーネルライセンス）のオープンソース版であるOpenSolarisをリリースすることを決定しました。設立からOracleに買収されるまで、Sunは真に独立した開発者コミュニティを築くことはありませんでした。2010年、OracleはOpenSolarisプロジェクトを事実上終了させました。

参加を決めた時点で、既に取り組みたいプロジェクトは決まっています。次に重要な決定は、社内から誰がこのプロジェクトに参加するかです。これは経営陣が見落としがちな決定です。参加するエンジニアは会社を代表する存在です。彼らの役割は、プロジェクトメンテナーの信頼を得ること、プロジェクトの開発ロードマップを導くこと、自分の仕事が受け入れられることを確実にすること、そして会社のビジネス目標を保証することです。

プロジェクト参加者の選定は極めて重要です。GNOME Foundationの元エグゼクティブディレクター、ストーミー・ピーターズ氏はかつてこう述べています。「企業は個人ではない」。言い換えれば、企業はソフトウェア開発コミュニティの一員になることはできませんが、個人はそうできるのです。企業はプロジェクトの組織的枠組みにおいてパートナーとなることができます。ビートルズとカール・フォーゲルの例を考えてみてください。お金で感情（あるいはコミュニティの支援）を買うことはできません。

コミュニティプロジェクトにエンジニアが参加するようになったら、次は何をするでしょうか？エンジニアの関与について、Havoc Pennington 氏は 1999 年に優れたアドバイスを書いています。一言で言えば、「郷に入れば郷に従え」ということです。

多くのコミュニティには独自の行動規範文書があります。例えば、LinuxカーネルやGNOMEモジュールプロジェクトには、ソースコードドキュメントに「HACKING」というファイルがあり、開発者が参照できるメーリングリストのガイドラインもあります。ほとんどのコミュニティにとって、これらのガイドラインは「慣習に従い、それを破らない」と要約できます。GNOMEプロジェクトの創設者であり、Novellの開発プラットフォーム担当副社長であるミゲル・デ・イカザ氏は、これらのガイドラインの背景にある理由を説明する記事を執筆しました。

開発者間のコミュニケーションにおいて、会社が介入するのは避けるべきです。そうすることで、プロジェクトにおけるエンジニアの孤立化を招くだけです。

社内の経験豊富なコミュニティ開発エンジニアをチームに迎え入れ、新メンバーのメンタリングやコミュニティのプロセス教育に役立てましょう。ただし、これらのベテランエンジニアがゲートキーパーの役割を担い、チームをコミュニティから孤立させてしまうような事態は避けてください。ゲートキーパーが去った後、他者が提出したコードがコミュニティガイドラインに準拠していないことがコミュニティで発見されるなど、予期せぬ問題が発生する可能性があります。

コミュニティを確立する

さて、2つ目のシナリオ、つまりコミュニティの構築方法に移りましょう。ソフトウェアを標準的なフリーソフトウェアライセンスでリリースすることに決めた場合、まずプロジェクトをコミュニティプロジェクトにするかどうか、そしてどの程度オープンにすべきかを決める必要があります。

Simon Phipps氏は、オープンソースソフトウェアプロジェクトから生まれる様々なタイプのコミュニティについて記事を書きました。彼はコミュニティ開発者を、コア開発者、非コアプラグイン開発者、リリースと設定を担当するが開発には関与しない統合担当者、そして最終的にはソフトウェアユーザーに分類しました。これらのメンバーはそれぞれ異なるニーズを持ち、異なるアプローチを必要とします。

プロジェクトを中心にコミュニティを構築したい場合は、次の優れたガイドラインに従う必要があります。

- 制御：これには、製品コードに追加できるコードを確実に決定するためのルールを導入することが含まれる場合がありますが、コミュニティプロジェクトの多くの利点は失われます。他の例としては、コア製品に組み込まれるコードの著作権を管理したり、メインブランチのコア製品コードを変更できるのは従業員のみにすることを保証したりすることが挙げられます。これは、コアコードの著作権を維持するための良い方法です。これは確かにコアコミュニティ開発者の妨げになりますが、プラグイン開発者やインテグレーターなど、他の種類のメンバーの参加を妨げることはありません。

- 参入障壁: コミュニティ開発者は、開発前に、一般的でないツールの使用、複雑でわかりにくいバグ報告プロセス、機能要求の送信方法、パッチの受け入れ方法、法的ビザ手続きなどの障壁を設けることを避ける必要があります。

- ツールとアーキテクチャ：モジュールやGitorious、Bazaarなどのコード管理プラットフォームなどを通じて、ユーザーが自分の作業を他のユーザーに配布できる機会を確保しましょう。プロジェクト内でのコード変更をソーシャルな活動にしましょう。

- コミュニティによる処理：誰も二級市民とみなされない環境を作りましょう。バグレポートの管理権限、メインブランチへのコードのコミット権限、プロジェクトウェブサイトの編集権限など、権限の付与方法を文書化します。

- 適切な予算: 適切なリソースの投資 - コミュニティの構築には時間と労力がかかり、主に人的リソースへの投資が必要になります。

コミュニティの日常業務を担当するマネージャーを1名任命します。意思決定を行い、関係者全員の利益を守るため、10名程度で構成される常設の中核法人グループを設立します。ジョシュ・バーカスによるPostgreSQLに関するレポート「コミュニティを潰す方法」にあるように、コミュニティのメンバーは軽視されていると感じれば離脱してしまいます。

コミュニティプロジェクトの立ち上げは、新製品の立ち上げに似ています。開発者コミュニティの獲得は、ユーザー獲得よりも時間がかかり、困難です。企業が新製品のSAC（開発者獲得コスト）を追跡するのと同様に、開発者獲得コスト（DAC）は、コミュニティの活性化を測る重要な要素です。

開発者は多くのプロジェクトから選択できるため、コラボレーションが当たり前になれば、プロジェクトへの参入が加速するでしょう。この時点で、参加者の経験を頻繁に考慮し、外部開発者の価値を評価する必要があります。

明確で説得力のあるブループリントと、多数の開発機会、および比較的低い参入障壁を組み合わせることで、開発者を引き付けるコストだけでなく、新規ユーザーや有料顧客を引き付けるコストも削減できます。

非伝統的なパターンを避ける

もしあなたが近道を採用し、近道を試みたとしても、コミュニティの膨大な証拠がその近道が間違っていることを証明したとしても、その近道の背後にある理由が誤解されていれば、望む結果は得られないでしょう。まるで太平洋貿易カルトのように、多くの空港を建設しながらも大きな市場を持たず、飛行機が着陸することを期待するようなものです。味付けはあくまで味付けであり、やりすぎると料理全体が台無しになってしまいます。

まとめ：コミュニティ内またはパートナー間で以下のパターンが見られる場合、対処する必要があります。これらのパターンは、いわゆる「***戦略」であるため、一般的で魅力的ですが、時代遅れです。いずれもコミュニティの健全性を弱めてしまいます。

次のような非標準的なパターンは避けてください。

1. 統制と命令 – コミュニティのメンバーはパートナーシップ関係にあります。しかし、企業と製品の関係は統制関係です。コミュニティソフトウェアとして開発したい製品にこの企業のような関係性を適用しようとすると、冷淡な反応しか得られません。なぜなら、他者は二級市民になりたくないからです。同様に、自分が統制権を持たないコミュニティに参加するのは非常に困難です。影響力を拡大するためには、統制権を譲渡しなければならない場合もあります。

2. ウォータークーラー - チームが個人的な仕事に過度に集中していると、コミュニティの他のメンバーからあなたの動機や優先順位を疑問視される可能性があります。公開メーリングリスト、フォーラム、その他の公開プラットフォームを利用する際は、社内の従業員と社外の人が同じ勤務スケジュールで作業していることを確認する必要があります。

3. バイクシェッドでの議論 – 比較的些細な決定について長々と議論する。コミュニティのメンバーがあなたの足を引っ張っていると感じたら、いつ議論を終わらせて仕事に取り掛かるべきかを知るべきです。

4. ブラックホール - プロジェクトに貢献してもらいたいスキルを持っているという理由で、コミュニティ内の既存の開発者を採用したくなることがあります。しかし、注意が必要です。コミュニティ開発者を採用すると、かえって状況が悪化する可能性があります。彼らは既にコミュニティ内で活動しており、その仕事は本質的に私利私欲に基づいていないからです。

5. クッキーを舐める子 - たくさんのクッキーを持っている子供を想像してみてください。でも、全部食べてしまう前に1枚だけ残しておきたいのです。だから、お皿から1枚取って、他の人に食べられないように何度も舐めます。コミュニティプロジェクトにも似たような問題があります。コミュニティを率いる人は、重要な機能を自分の開発のために独占してしまい、他のメンバーが貢献する良い機会を奪ってしまうことがよくあります。その結果、一部のメンバーは貢献しすぎて、他の人は飢えてしまうことになります。開発ロードマップの中で、他の人にタスクを割り当てましょう。自分がやりたいこととやりたくないことを明確にしましょう。

コミュニティを育てて幸せに

コミュニティによるソフトウェア開発は、製品開発の大きな後押しとなり、貴重な資産となります。既存のコミュニティプロジェクトに取り組むことで、時間とコストを節約し、他の方法よりも迅速かつ高品質な製品をリリースできます。かつて製品開発は「自分で作るか、買うか」という二者択一でしたが、今では「自分で作るか、買うか、共有するか」という三者択一になっています。Android、MeeGo、Linaro、Qtなどで開発を行っている方なら、コミュニティ開発の重要性をご理解いただけるでしょう。オープンソース運動を受け入れることで、リソースが拡大し、評判が向上し、良好なギブアンドテイクの関係が育まれ、誰もが恩恵を受けられます。重要なのは、コミュニティのメンバー全員を製品開発のパートナーとして扱うことです。

危険な誘惑を避け、適切な時間と労力を費やせば、最終的には目標を達成できるでしょう。庭師が適切な肥料、道具、そして資源を使って植物を育てるように、春が来れば花が咲きます。

[編集者のおすすめ]

1. オープンソースコミュニティ開発イノベーションメカニズムを確立する
2. 詳細レポート：中国のLinuxオープンソースコミュニティの緩やかな成長
3. オープンソースコミュニティの仕組み – KDE編

[編集者：李静、TEL：(010)68476606]