カネに関する問題
この章では、フリーソフトウェアを開発するためにお金を調達する方法を調べていきます。
ここでは、フリーソフトウェアプロジェクトでお金を貰って雇われる開発者だけでなく、
開発する環境が置かれる社会力学を理解する必要があるプロジェクト管理者も対象にします。
以下のセクションでは、読者(あなたです！) はお金を貰って雇われる開発者か、
開発者を管理する人であることを想定します。
この章でのアドバイスは、両者に当てはまることもありますし、そうでないこともありますが、
対象となる人は文脈の中で明らかにしていきます。
フリーソフトウェアの開発に企業がお金を出すことは新しい現象ではありません。
多くの開発が、いつも非公式に奨励金の対象になってきました。
システム管理者が業務の遂行を助けるためにネットワーク分析ツールを書き、
オンラインにそれを投稿し、
バグ修正や機能追加の貢献を他のシステム管理者から受けた場合、
非公式に団体が設立されていきました。
団体を維持するための資金は、システム管理者達の給料から出ており、
オフィススペースやネットワークの帯域は寄付によって賄われました。
こうした組織は、はじめのうちは制度的に認知されることはありませんでしたが、
もちろん投資することで利益を得ていたのです。
当時と今の違いは、こうした努力の多くが公に認められるようになったということです。
企業はオープンソースソフトウェアから得られる利益に関心を示すようになり、
その開発に直接関わりはじめました。
開発者達も、本当に重要なプロジェクトには少なくとも寄付や、
可能であれば長期のスポンサーを期待するようになっています。
お金があるからといって、
フリーソフトウェアの基本的な開発力学が変わるものではありませんが、
開発者の数や、開発者ひとり当たりの作業量の規模は劇的に変わりました。
お金は、プロジェクトが組織化される方法や、
関係者のプロジェクトでのやりとりの仕方にも影響を与えました。
問題は、単にお金がどう使われるのかとか、
投資に対する見返りをどのように測るか、ということにとどまらず、
プロジェクトの管理やそのプロセスにも及びます。
つまり、企業の階層的な命令系統と、
緩やかに分散したフリーソフトウェアプロジェクトのコミュニティーが、
お互いに生産的に動くにはどうしたらいいでしょう？
そもそも "生産的に" という言葉がどういう意味なのか、
について企業とコミュニティーは一致するのでしょうか？
金銭的な支援を受けることは、
オープンソース開発コミュニティーでは一般的に歓迎されています。
支援を受けることで、
軌道に乗る前に多くのプロジェクトを潰してきたコミュニティーの弱点を無秩序の力に変えることができます。
それゆえに、人々はソフトウェアを世に送り出したいと強く願うようになります。
— つまり、これから向こう6ヵ月間は自分の時間をそこらへんに転がっている何かに使おう、
と人々は考えるのです。結局、何かを信じる心は、ある程度までは他の人に伝染しやすいものです。
たとえば、IBM がオープンソースプロジェクトを支援したとき、
このプロジェクトに失敗は許されないと人々は強く思いましたし、
失敗しないようプロジェクトに注力しようと思う心が、
プロジェクトが実際に失敗しない状況を作ったのです。
しかし、お金を出すことは、人を支配する感覚を生むものでもあります。
注意深く扱わないと、お金はプロジェクトを、仲間内の開発者とそうでない開発者に分裂させてしまうかもしれません。
ボランティアの開発者が、一番お金を出している人が機能追加や設計上の決定を行えるんだと思ってしまうと、
実力志向が強く、それでいて他人の利益のために無給で働くことを好まないプロジェクトに移ってしまうでしょう。
彼らは、決してメーリングリスト上で大声で不平を言ったりはしません。
そのかわり、ボランティア達が真剣に取り組むことをやめてしまうため、
外から口を出す人がどんどん少なくなっていくだけです。
バグ報告や小規模な修正をたまに行う形で活動は続きますが、
大規模なコードの貢献や、設計上の議論に外部から人が参加するといったことはなくなってしまいます。
人々は自分に何が期待されているのかを感じ取り、期待に応えようと動いたり、
それを裏切ったりするのです。
お金は注意深く扱う必要がありますが、
そうしたからといってプロジェクトへの影響力を買えるわけではありません。
ほとんどの場合は、買えるのですが、
プロジェクトに直接影響力を行使できるわけではない、というのがミソです。
単純な商取引では、欲しいものとお金を交換します。あなたが追加して欲しい機能があれば、
契約にサインし、お金を払い、作業をしてもらいます。
オープンソースプロジェクトでは、事はそう簡単ではありません。
あなたは開発者達と契約することが出来ます。しかし、彼らがもし、
お金を払うだけで開発コミュニティーにその有償の成果を取り込んでもらえると保証したのなら、
彼らは — そしてあなたも — 勘違いをしています。
コミュニティーは、成果物そのものの利点と、
それがどの程度ソフトウェアのビジョンに合っているかに応じてそれを受け入れるのです。
あなたはソフトウェアのビジョンについて口を出す権利はありますが、
あなたの意見が唯一の声というわけではないのです。
よって、お金でプロジェクトへの影響力を買うことはできません。しかし、
影響力に 繋がるもの を買うことはできます。
もっとも明快な例はプログラマーを買うことです。
優れたプログラマー達を雇えば、彼らはソフトウェアに関する経験を積み、
コミュニティーで信頼を得るまでプロジェクトに張り付きます。
そうすれば、他のメンバーと同じ手段でプロジェクトに影響を与えることができます。
彼らはそれぞれが投票権を持つ場合もあれば、人数が多い場合にはブロック投票権を持つこともあります。
彼らがプロジェクトで尊敬を得れば、投票権以上の影響力を持つことになるでしょう。
雇われている開発者は自分の動機を偽る必要はありません。
結局、ソフトウェアに変更を加えたい人は誰でも、それぞれに理由があるものです。
企業がソフトウェアを変更したい理由が、他より正しくない、ということはありません。
企業の目標がプロジェクトで重視されるかどうかは、
企業規模や予算、もしくはビジネスプランによって決まるのではなく、
企業を代表している人たちのプロジェクト内での地位によって決まるのです。
Crowdfunding: Kickstarter, etc
24 March 2013: If you're reading this note, then
you've encountered this section while it's undergoing substantial
revision; see producingoss.com/v2.html for details.
poss2 tbd
Kickstarter is the obvious place to start, but there
are other funding systems too. Look at campaigns that have used
indiegogo, snowdrift (if in production by then), ask around for
others. Use Michael Bernstein's tips on how to do it
right.
プロジェクトへの関わり方
オープンソースプロジェクトがお金を出してもらう理由は様々なものがあります。
以下に示す理由は、相互に排他的なものではありません。
つまり、支援を受ける理由は以下の複数、または全てが当てはまる場合があります。
コスト負担を共有する
関連があるソフトウェアを必要とする組織は、
似たようなコードを社内で書いたり、
商用ベンダから似たような商品を購入したりすることで、
同じ目標に向かって重複した努力をしていることがよくあります。
彼らはそれを知ると、
自分たちの需要を調整するため、
オープンソースプロジェクトを作る(または既存プロジェクトに参加する)かもしれません。
その利点は明らかです。
開発コストを分散しつつ、利益は参加したすべての組織が得ることができるからです。
このシナリオは、非営利な組織の場合もっともわかりやすいのですが、
競合関係にある営利組織であっても、戦略的には有意義なものです。
例: ,
サービスを拡大する
企業が販売している複数のサービスが特定のオープンソースソフトウェアに依存していたり、
それによってサービスの魅力を高めている場合、
そのソフトウェアを活発に維持していくことがその企業の関心事になるのは自然の流れです。
例: CollabNet が
をサポートしていること(お断り: これは筆者のルーチンワークですが、これがこのモデルの最良の例です)
ハードウェアの営業をサポートする
コンピューターとその部品の価値は、
それが利用できるソフトウェアの量に直接左右されます。
ハードウェアベンダー — 完成したマシンのベンダーだけでなく、
周辺機器デバイスやマイクロチップのベンダーも含みます —
は、自分たちのハードウェアを動かせる高品質なフリーソフトウェアが存在していることが、
顧客にとって重要であることに気付いているのです。
競争相手を弱体化させる
企業によっては、
競合しているソフトウェアの力を弱めることを狙ってオープンソースプロジェクトをサポートするところもあります。
競合するソフトは、オープンソースであってもそうでなくても構いません。
競争相手の市場シェアを減らすことが、
オープンソースプロジェクトに参加する唯一の理由ではないものの、
そのひとつだったりすることはあり得ます。
例:
(競争相手を弱体化させることが OpenOffice の唯一の存在理由ではありませんが、
このソフトウェアは、少なくとも Microsoft Office に対する答えのひとつです)
マーケティング
人気のあるオープンソースソフトウェアに関わっている企業は、
それだけでブランド管理をうまく行うことができます。
デュアルライセンス
デュアルライセンス とは、
自分のソフトウェアに商用のソフトウェアを組み込んで売りたい顧客向けの伝統的な商用ライセンスと、
ソースを公開して使いたい人向けのフリーなライセンスを同時に共存させてソフトウェアを提供するための手法です。
( の
を参照してください)
オープンソース開発者のコミュニティーが活発なら、
デュアルライセンスされたソフトウェアは、
広く多くの人から開発作業やデバッグをしてもらえるという利益を得られる上、
企業はフルタイムで働くプログラマーを支援することで、
ロイヤリティの収入を得ることができるのです。
このモデルの例として、よく知られているものがふたつあります。
同じ名前のデータベースソフトウェアを作っている MySQL、
そして Barkley DB を配布し、サポートしている Sleepycat です。
これらの例が両方ともデータベースを扱う会社であることは、
偶然の一致ではありません。
データベースソフトウェアは市場でユーザーに直接売るというよりは、
アプリケーションに統合される傾向があるため、
デュアルライセンスのモデルによく合っているのです。
寄付を受ける
広く使われているオープンソースソフトウェアのプロジェクトでは、
オンライン上で「寄付を行う」ボタンを押してもらったり、
コーヒーのマグカップやTシャツ、マウスパッドなどのような、
ブランド化した商品を売ることで、
個人や組織から重要な貢献を受けることができます。
ここで一言注意しておきます。もしあなたのプロジェクトで寄付を受けることにした場合、
お金が入ってくる 前 に寄付されたお金をどう使うかを計画し、
それをプロジェクトのウェブサイトに掲示するようにしましょう。
どうお金を使うかの議論は、実際にお金が入ってくる前の方がうまくいきます。
どちらにせよ、お金の使い方に同意が得られない場合は、
寄付を受けることが非現実的であると判断した方がよいでしょう。
お金を出す側のビジネスモデルが、
オープンソースコミュニティーに対する関わり方を決める唯一の要因ではありません。
お金を出す側とコミュニティーとの歴史的な関係も影響しています。
つまり、企業の方がプロジェクトを始めたのか、
それともあとから既存のプロジェクトに参加したのか、という点です。
どちらの場合も、お金を出す企業はコミュニティーから信頼を勝ち取る必要がありますが、
あとから既存プロジェクトに参加した方が少し信頼されやすい、
ということは驚くべきことではありません。
必ずしもプロジェクトの方向性を支配するためではなく、
導くためであったとしても、
企業はコミュニティーでリーダー的な存在を維持したり、
唯一の発言権を持とうとしているでしょうか。
または、ある程度の人数コミッターを送り込み、
顧客から報告されたバグを修正し、
労せずして製品にそれを取り込みたいだけでしょうか？
このふたつの質問を、
以降で説明するガイドラインを読むときによく覚えておいてください。
これらはフリーソフトウェアプロジェクトに組織が参加するあらゆる場合に適用できますが、
プロジェクトは人間が作るものですので、ひとつとして同じものはありません。
ある程度、なりゆきに任せなければならないでしょうが、
これから説明する原則を理解していけば、
あなたが望むやり方と似たものが出てくるでしょう。
開発者を長期に渡って雇用する
オープンソースプロジェクトでプログラマーを管理している場合、
技術的、政治的にうまくやっていくスキルを身につけるまで彼らをそこに留めるようにしましょう。
— それには最低でも2〜3年は必要です。
もちろん、オープンソースプロジェクトであれ、クローズドなプロジェクトであれ、
開発者を頻繁に入れ替えたりすると利益は得られません。
初心者が仕事のコツを覚えるのに必要なのは、どんな環境であってもそこに留まることです。
開発者を頻繁に入れ替えると、オープンソースプロジェクトではより不利になってしまいます。
なぜなら、出て行くプログラマーはコードに関する知識だけでなく、
そのコミュニティーで得た地位や人間関係も持って行ってしまうからです。
開発者がオープンソースプロジェクトで得た信頼は、人に伝えることができません。
一番わかりやすい例をあげましょう。新たに参加する開発者は、
プロジェクトから出て行く人からコミット権限を引き継ぐことは出来ません。
(この章の後の方にある を参照してください)
コミット権限がないので、新しい開発者はそれが得られるまでパッチを提出しなければいけません。
しかし、コミット権限だけが失われた信頼を測る唯一の要素ではありません。
長期に渡ってプロジェクトに関わった開発者は、
メーリングリストでの雑多な古い議論に関する知識もあります。
新しい開発者にはそうした知識がないので、古い議論を蒸し返そうとするかもしれません。
それによってプロジェクトでの信頼がなくなってしまうかもしれないのです。
つまり、「お前何も覚えてないのかよ？」と思われてしまうのです。
新しい開発者は、プロジェクトにいる個人が持つ政治的な力に関する感覚もないので、
長くプロジェクトにいた開発者ほど、
開発の方向性について、円滑に影響力を発揮することははできないでしょう。
新しい開発者については、計画に基づいて訓練するようにします。
彼には初日から開発コミュニティーと直接連絡をとらせ、
バグ修正やコードを掃除するタスクを始めさせるべきです。
それによってコードベースを学び、コミュニティーで信頼を得ることができます。
しかし、長い時間がかかる、複雑な設計の議論の火付け役にはならないようにします。
いつも新しい開発者の質問に答えてくれたり、
経験を積んだ開発者が普通は気に留めないようなスレッドでも、
彼のメーリングリストへの投稿を読んでくれている先輩の開発者がいるはずです。
こうすることで、新しい人が活躍する前から開発グループを潜在的に刺激することができます。
自分のコードを多くの人からピアレビューされることに開発者が慣れていない場合は、
裏で励ましたり、ポインタを示してあげたりすることも大いに役立つでしょう。
CollabNet が Subversion プロジェクトで働いてもらうために開発者を雇うときは、
一緒に話し合って保留中のバグをいくつか選んでもらい、経験を積んでもらいます。
バグを解決するための技術的な概要を話し合い、
新しい開発者が（公の場に）投稿する修正プログラムを（これも公の場で）レビューするために、
経験を積んだ開発者を少なくともひとり割り当てます。
メインの開発用メーリングリストで公になる前は、
私たちは彼のパッチを見ることさえしません。理由があれば見ることもできるわけですが。
重要なのは、新しい開発者が公の場で行われるレビューの過程を経験し、
全く知らない人から批判を受けることに慣れると同時に、コードベースを学ぶことです。
しかし私たちは、彼のパッチが投稿された後、
自分たちのレビューがすぐに行われるようにタイミングを調整しようとします。
こうして、メーリングリスト上での最初のレビューを自分たちが行うようにすると、
他の人のレビューの口調を抑えるのに役立ちます。
また、新しい人を真面目に扱おうという考え方を浸透させることができます。
適切なメーリングリストのアーカイブを参照したり、説明をすることで、
詳細なレビューに時間を割いているのを外部の人が見ると、
新しい開発者の訓練が行われていて、彼に対して長期に渡って投資を行うことがわかるのです。
こうすることで、開発者が少なくとも質問に答えたり、
パッチをレビューするのに時間を割こうという気にさせることができるのです。
企業の人間としてではなく、個人として振る舞う
あなたが雇った開発者には、プロジェクトの公のフォーラムで一枚岩の企業の人間としてではなく、
個人として振る舞ってもらうようにしましょう。
これは企業が関わることでついてまわる否定的な意味合いがあるからではありません(まぁ多分あるのでしょうが、それはこの本では触れません)。
むしろ個人こそが、オープンソースプロジェクトが構造的に扱える唯一の存在だからです。
個人の貢献者は、議論に参加したり、パッチを提出したり、信頼を得たり、
投票するなどができますが、企業にはそれができません。
それ以上に、分散した個人として振る舞うことで、
反感が一ヶ所に集中するのを避けることができます。あなたが雇った開発者には、
メーリングリスト上でお互いが反目させるようにしてみましょう。
彼らにお互いのコードを頻繁に、公の場で、赤の他人としてレビューさせるようにしましょう。
そして、いつも徒党を組んで投票させないようにしましょう。なぜならそうしてしまうと、
他の人が「こいつらは徒党を組んでいる」と感じますし、道徳的な見地から、
彼らをチェックし続けるために組織的な努力がなされるべきだからです。
実際に個人として振る舞うことと、そうしようと単に努力することは違います。
状況によっては、雇った開発者達に一致した行動をとらせた方が便利なこともありますし、
必要なときは裏で協力する準備をすべきでしょう。
たとえば提案をするとき、合意が形成されつつあることを印象付けるために、
何人かに早い段階から同意の意志を示してもらうようにします。
他の人は、その提案に勢いがあると感じるでしょうし、仮に反対すれば、
その勢いを削いでしまうとも思うでしょう。
よって、理由がある場合だけ、人々は反対するようになります。
反対意見を真摯に受け止めている限り、賛成意見を組織化することは間違っていません。
賛成意見を公の場で明らかにすることは、
たとえそれが事前に協力していたとしても真摯である点は変わりませんし、
反対意見を封殺するのに使われない限り、害はありません。
彼らの目的は、単に体裁を保つためだけに反対したがる類の人を抑えることなのです。
そういう人については、 の
を参照してください。
動機を隠し立てしない
あなたの組織がプロジェクトで目指していることを、できる限り隠さないようにしましょう。
ただし、ビジネス上の秘密は漏らしてはいけませんが。
たとえば、自分の顧客から強く要求されているという理由で、
ある機能をプロジェクトに取り込んでもらいたいのであれば、
メーリングリスト上で率直にそう言うようにしましょう。
顧客から自分のことを秘密にしてほしいと頼まれることもありますが、
その場合は匿名で事例を紹介させてもらえるかどうかを少なくとも聞くようにします。
開発コミュニティーがあなたがやりたいことの 動機 を知れば知るほど、
あなたが何を提案しても違和感が少なくなります。
これは、知識は力であり、他人が自分の目標を知れば知るほど多く干渉される、
という直感に反するものです。
— 直感を受け入れるのは簡単ですが、取り除くのは難しいものです。
しかし、ここではその直感は間違っています。
新機能 (バグ修正でもなんでも) を公の場で主張することで、
あなたは 既に カードをテーブルに置いているのです。
その時点で唯一問題になるのは、目標を共有できるようにコミュニティーを誘導できるかどうかです。
仮に望むことだけを主張して、その理由となる具体例を述べなければ、
その主張は弱くなってしまいますし、隠れた意図があるのではないかと疑われてしまいます。
しかし、現実世界のシナリオを 2,3 述べ、提案している新機能がなぜ重要なのかを示すだけで、
議論する上で劇的な効果があります。
別の視点から考えてみましょう。新機能やプロジェクトの新しい方向性に関する議論は長く、
退屈なものです。人々の主張は「個人的には X が欲しいんだよね」とか、
もっとよくあるのは「ソフトウェア設計を長い間やってきたんだけど、
X は ユーザーにとってもの凄く重要だ / 誰も満足しない余計な飾りだよね」
といったものになります。現実世界での使い方が示されていないと、
議論の短縮や決着に繋がらないばかりか、実際のユーザー体験からは程遠い議論になってしまいます。
そういった議論を止める力が働かない限り、
結局はもっとも口が達者な人や、頑固な人、
あるいは一番の古参によって結論が決まってしまうでしょう。
大量の顧客データを持つ組織として、あなたにはそういった議論を止めるチャンスがあります。
他の人が開発コミュニティーに伝えることができない情報へのパイプ役になれるのです。
あなたが望むことの根拠になる情報は恥ずかしいものでも何でもないのです。
ほとんどの開発者は自分が書いたソフトウェアがどのように使われているのかについて、
広い見聞を持っているわけではありません。開発者はめいめいが、
自分独自のやり方でソフトウェアを使っているのです。そして他の使い方については、
直感や当て推量、そして本能に頼って作っていることを知っているのです。
非常に多くのユーザーの信頼できるデータを提供することで、
あなたは開発コミュニティーに酸素に似た何かを与えることになります。
そうした情報を適切に示す限り、彼らは熱狂的にそれを受け入れるでしょうし、
物事はあなたの望む方向に進むでしょう。
鍵となるのは、もちろん情報を適切に示すことです。あなたが大量のユーザーを抱えていたり、
ユーザーがある機能を必要としている (またはそう思っている) からといって、
自分の解決策を実装すべきだと主張してもうまくいかないでしょう。
むしろ、ある特定の解決策についてではなく、
問題となっていることがらをはじめに投稿するとよいでしょう。
あなたの顧客が経験していることを詳細に記し、できるだけ多く分析しておきます。
その上で、考えられうるだけの現実的な解決策を提示するのです。
解決策がどれくらい有効かを人々が考え始めたら、あなたは彼らの発言を擁護したり、
異議を唱えたりするのに自分のデータを示すことができます。
あなたははじめからずっと特定の解決策が頭にあるかもしれませんが、
はじめからその解決策を選んで特別な配慮をしてはいけません。
これは相手を騙しているのではありません。単に普通の「公正な仲裁者」として振る舞うことです。
結局、あなたの本当の目標は特定の問題を解決することです。
特定の解決策は、そのための手段でしかないのです。
仮にあなたが好む解決策が優れていれば、他の開発者達もそれを結局は認めてくれ、
彼らの自由意志で応援してくれるようになるでしょう。
彼らを威嚇して自分の解決策を実装させるより、この方があなたにとってよいでしょう。
(彼らが自分より優れた解決策を考えているかもしれません。)
これは、特定の解決策を好んでいることを言ってはいけないということではありません。
しかし、あなたが既に内部で終えている分析が、
開発用の公開メーリングリストで繰り返されるまで我慢しなければなりません。
「すべての解決策をみてきたけれども、それは A, B, C という理由でうまくいかない。
突き詰めて考えていくと、結局唯一の解決策は ...」などと発言してはいけません。
問題なのは、こうした発言が尊大に聞こえるということよりも、
むしろあなたがその問題を分析するためにある未知数の (多分大きいと人々は思うでしょう)
リソースを 既に 裏で投入しているという印象を与えてしまうことです。
これは既に物事が進行していて、多分決定もなされていて、
公にはそれについて何も知らされていないように見えてしまいます。
これは人々の怒りを買う原因になります。
当然、あなた はその問題について裏でどのくらい努力してきたかを知っています。
その知識はある意味不利なものです。あなたが雇っている開発者は、
メーリングリスト上にいる他の開発者とは違った精神状態に置かれてしまい、
その問題について考えたことがない開発者の視点から物事を見る能力が欠けてしまいます。
より早い段階で他の人にあなたと同じ言葉で考えさせれば、こうした溝は小さくなります。
この論理は、個々の技術的な状況だけでなく、自分の目標をできるだけ隠さないという広義の要請にも適用できます。
知らないことは知っていることよりも不安定なものです。
あなたがやりたいことの動機を人々が知れば、
彼らはたとえそれに反対であってもあなたと気軽に話してくれるでしょう。
あなたの動機が分からなければ、彼らは物事を悪い方向に考えてしまうこともあります。
もちろんすべてを公にはできないでしょうし、人々もそんなことを期待していません。
すべての組織には秘密があります。おそらく営利組織には多くの秘密があるでしょうし、
非営利な組織でもあるでしょう。ある方向性を擁護する義務があるけれども、
その理由を全く公にできない場合は、
そういった制約の中で出来るもっとも優れた主張をするようにしましょう。
そして、議論の中で自分が望むほど影響力を行使できない可能性がある、
という事実を受け入れましょう。
これは、開発コミュニティー全体に給料を払わないために行う妥協のひとつです。
カネで愛は買えない
あなたがカネを貰って雇われている開発者なら、
カネで買えるものと買えないものに関する基準を早い段階から設定するようにしましょう。
これは、あなたの気高くて侵し得ない性分について、
1日に2回メーリングリストに繰り返し投稿することではありません。
カネが作り出す 可能性がある 葛藤を鎮める機会を探っておくべき、
というだけです。そういった葛藤が既にあるものと考える必要はありませんが、
起きる可能性があることを知っている、ということは態度で示す必要があります。
そういった態度を示した良い例が Subversion プロジェクトで起こりました。
Subversion は、何人かの開発者 (お断り: 筆者もそのうちのひとりです)
に給料を支払っていた CollabNet
が始めたものです。
CollabNet は、プロジェクト開始時からずっとプロジェクトに一番カネを出しています。
プロジェクトが始まってすぐ、CollabNet は Mike Pilato という別の開発者を雇いました。
彼を雇うまでに、コーディングは既に始まっていました。
Subversion はまだ開発の初期段階でしたが、
既に基本的なルールを備えた開発コミュニティーが出来上がっていたのです。
Mike を雇うことで、面白い疑問が出てきました。
Subversion プロジェクトには、
新しい開発者にコミット権限をどうやって与えるかに関するルールが既にありました。
まず、彼は開発用メーリングリストに修正プログラムをいくつか投稿します。
十分な量の修正が彼の修正プログラムによって行われ、他のコミッター達は、
彼が自分がしていることをよく理解していることを知ります。
その後、コミッターの誰かが彼は直接コミットしたらいいじゃないかと提案します( で説明していますが、
この提案は非公式に行います)。
そして提案をした人の一人が彼にメールを送り、既にいるコミッター達が同意するものと見做して、
プロジェクトリポジトリへのコミット権限を与えるのです。
CollabNet は Subversion プロジェクトで専ら働いてもらうために Mike を雇いました。
彼を知っている人達のうち、
彼のコーディング技術やプロジェクトですぐに働けるかどうかについて疑う人は誰もいませんでした。
それに、ボランティアの開発者は CollabNet に雇われている開発者達ととても良い関係を築いていて、
CollabNet が彼を雇った段階でコミット権限を与えてもほとんどの人は多分反対しなかったでしょう。
しかし、CollabNet はそうすることで悪しき前例を作ってしまうことを知っていました。
仮に Mike に CollabNet が独断でコミット権限を与えてしまうと、
CollabNet はプロジェクトに一番カネを出しているという理由だけで、
プロジェクトが設定したガイドラインを無視する権利があると宣言することになってしまいます。
それによる影響はすぐには顕在化しないでしょうが、
カネを貰っていない開発者がコミッターを選ぶ権利を奪われたと感じてしまう事態が徐々に出てくるでしょう。
CollabNet に雇われていない人がコミット権限を得るには、
それなりの努力をしなければなりません。
— しかし、CollabNet はカネを出すだけでコミット権限を手に入れているのです。
こうした理由から、Mike は 他のボランティアの開発者と同様に、
コミット権限がない状態で CollabNet での仕事を始めることに同意しました。
彼は公のメーリングリストに修正プログラムを送りました。
それはプロジェクトのメンバー全員でレビューできる状態にありましたし、
また現にレビューされました。
CollabNet は メーリングリスト上で、
Mike を雇ったにも関わらず わざと コミット権限を与えていないと宣言したので、
行き違いが起こることはありませんでした。Mike は数週間堅実に働き、
誰かが彼にコミット権限を与えてはどうかと提案し、それは受け入れられました。
これは受け入れられるとわかっていたことです。
(提案した人が CollabNet が雇った開発者だったかどうか筆者は覚えていません)
こうした方針を一貫して守ることで、カネでは買えないことがある、
ということを人々は信じるようになります。こういう点で信用されることは、
技術的な議論をしているときでも通用する価値があります。
つまり、あとで蒸し返されることを防ぐことにもなるのです。
議論が白熱してくると、人は技術的でない点で議論に勝つ方法を探すようになります。
プロジェクトに一番カネを出している人は、プロジェクトに深く関わり、
プロジェクトが採る方向性について深い関心があるだけに、
ほとんどの人から格好の攻撃の対象とされます。
プロジェクトを始めてすぐの段階からガイドラインを実直に守ることで、
カネを出す人は自分自身を他と同列に扱っているのです。
(コミット権限に関する似たような話として、Danese Cooper のブログエントリ
を見るとよいでしょう。
Cooper は そのとき サン・マイクロシステムズ の "オープンソースの部署" にいました —
それが彼女の公の肩書きだと思います — このブログエントリでは、
Tomcat の開発コミュニティーが、どのようにして自分たちと同じコミット権限に関する基準を
サン・マイクロシステムズ に守らせたかについて説明しています。)
プロジェクトにカネを出す人が、他の人と同じルールを守る必要があることは、
誰かがカネを出す場合に優しい独裁者モデル (
の を参照してください)
がちょっと機能しにくいことを意味しています。
優しい独裁者がプロジェクトに一番カネを出している場合は特にそうでしょう。
独裁にはルールがほとんどないので、たとえ実際に守っていたとしても、
プロジェクトにカネを出している人がコミュニティーのルールを守っていると証明することは困難です。
必ずしも不可能ではありませんが。それには、外部の開発者と同じ視点から物事を見ることができ、
適切に行動できる人で、かつカネを出せる人がプロジェクトリーダーになる必要があります。
その場合でも、コミュニティーで不満が広がる兆しが明るみに出てしまう場合に備えて、
独裁的ではないやり方で提案をするのはよい考えです。
契約する
契約は、フリーソフトウェアの世界では注意深く扱う必要があります。
理想を言えば、契約を結んで作業した人の成果物がコミュニティーに受け入れられ、
公のリリースに取り込まれるのが望ましいです。理屈の上では、
成果物の品質が良く、それがプロジェクトのガイドラインを満たしている限り、
誰と契約しようが問題ありません。この理屈と実際は一致することもありますし、
そうでないこともあります。
つまり、品質が良い修正プログラムなら、それが全く知らない人が書いたものであっても、
一般的にはソフトウェアに取り込むことが できる ということです。
困るのは、重要な改良や新機能の追加を行う良質の修正プログラムを全く知らない人に作ってもらうのはとても難しいということです。
作業を請け負う人には、プロジェクトでまず議論してもらわないといけません。
議論にかかる時間は正確に予測できません。
もしあなたが時給単位でお金を払っているのなら、
予想以上のお金を支払うことになるかもしれません。
逆に固定給であれば、その人は貰う金額に見合わない量の仕事をする羽目になるかもしれません。
この問題に対処する方法がふたつあります。望ましいのは、
過去の経験に照らして議論にかかる時間を推測し、誤差を少し足しておきます。
その値に基づいて契約するのです。
これは、問題を独立した多くの小さな断片にできるだけ分割し、
それぞれの断片の予測可能性を増やすのにも役立ちます。別のやり方として、
修正プログラムだけを作ってもらう契約を交わし、
それを公のプロジェクトに取り込んでもらうことを別の問題として扱う方法があります。
こうすると契約書を書くのは楽になりますが、
あなたがプロジェクトに依存する間、
またはそれと同様の機能をプロジェクトの本流に取り込んでもらうまでの間、
契約で作られた修正プログラムを維持するのに四苦八苦することになります。
もちろん、前者の望ましい方法をとったとしても、
修正プログラムが取り込まれることを契約の条件には出来ません。
なぜなら、これは状況によっては売っていないものを売ってしまうことになるからです。
(もし、プロジェクトが対象となる機能をサポートしないと決めたらどうなるでしょう？)
しかしながら、変更をコミュニティーに受け入れてもらい、
彼らが承知すればそれをリポジトリにコミットしてもらえるよう、
誠意をもって 努力することを契約の条件にすることはできます。
たとえば、プロジェクトがコード変更に関する基準を持っている場合は、
契約でそうした基準を参照した上で、成果物はそれを満たすように取り決めることができます。
実際、このやり方で契約の当事者全員が望む結果が普通は出てきます。
契約を成功させるために最も良い戦略は、プロジェクトの開発者を雇うことです
— 契約の相手としてはコミッターが望ましいです。
これは影響力を買っているように見えますし、実際そうですが、
見た目ほど破綻しているわけではありません。
プロジェクトの開発者は、主にコードの質が高いことと、
他の開発者と交流しているからこそ、影響力を持っているのです。
開発者があることを成し遂げる契約をしたからといって、
彼のそうした地位を高めることにはなりませんし、傷つけることもありません。
ただ、契約をすることで、周囲の人が彼のことをあれこれ詮索するようになるかもしれません。
ほとんどの開発者は、不適切、または多くの人が嫌っている新機能の導入を支援することで、
長い時間かけて築いてきたプロジェクト内での地位を危険に晒したりはしません。
そういう目的で実際に開発者を雇うときは、
どういう変更がコミュニティーに受け入れられやすいかについて、あなたはアドバイスを貰うはずです。
また、プロジェクト内の優先順位をわずかながら変更させることになります。
プロジェクト内の優先順位付けは、開発者が何に時間を掛けるかの問題にすぎないので、
開発者の時間を契約で買うとすると、彼の仕事の優先度が少し変わることになるからです。
これは経験を積んだオープンソースプロジェクトの開発者にとって避け難い現実ですし、
雇い主が課す仕事を単にそれが 先に片付けられそう だという理由だけで、
それだけに注意を向ける開発者も少なからずいます。
彼らはその仕事を早く片付ける後押しをしてくれます。
彼らは全くコードを書かず、設計について議論したり、
コードをレビューしたりしているだけかもしれませんが、これらはとても役に立つものです。
これまで述べてきたすべての理由から、契約相手になる開発者は、
プロジェクトに既に参加している人をランク付けして選ぶのが一番よいのです。
プロジェクトの開発者を雇うとすると、疑問が二つ出てきます。
契約を公にしない方がいいのでしょうか？ また、仮に公にするとして、
特定の開発者以外の人と契約しないことで、
コミュニティーに緊張関係を作ってしまうことを気にかけるべきなのでしょうか。
可能であれば、契約することを公にするのがベストです。仮にできなければ、
契約した開発者の振る舞いがコミュニティーのメンバーからは不自然に見えるかもしれません—
おそらく、彼はどういうわけか今まで全く興味を示さなかった機能に、
突然高い優先度を設定するようになるでしょう。
彼がその機能を欲しがる理由を尋ねられたとき、
契約をしている事実を話せないのだとしたら、
どうやってその理由をもっともらしく説明したらいいのでしょう？
また、あなたが関わっている作業がさも重要なことのように振る舞ってはいけません。
開発者を雇っているからというだけの理由で、
自分の投稿を重く扱うべきという厚かましい態度をメーリングリスト上でとる人がいました。
こうした態度は、開発者を雇う人が — 契約することで生み出される
コードではなく、契約している事実を重視していることを示していますが、
他の開発者からすれば、コードだけが重要なのです。
どんなときでも、誰が誰にお金を払っているのかではなく、
技術的な問題に注意を払うべきです。
契約にまつわる問題をうまくコミュニティーで処理している、
Subversion の開発者を例に挙げましょう。
彼が自分のコード変更についてIRCで議論しているとき、
彼は小声で (IRC の privmsg というプライベートな会話を使って)
今書いている機能や修正プログラムを書くのに、
お金をもらっていることを他のコミッターに伝えます。
彼はその変更をずっと望んでいたし、
その作業をしてお金を貰えるのが幸せであるかのように一貫して振る舞います。
彼は契約相手の身元を明かすかもしれませんし、明かさないかもしれませんが、
いずれにせよ契約の詳細に立ち入ったりはしません。
契約の話は、どうやって作業を成し遂げるかについての技術的な議論をするときに、
補足的にするだけです。
この例は、契約を公にした方がいいもうひとつの理由を示しています。
契約にお金を出している組織が複数あった場合、
一方が何をしようとしているのかがわかれば、リソースを共同で出資できるからです。
上の場合、プロジェクト最大の出資者 (CollabNet) はこうした出来高払いの契約に関わっていませんが、
誰か他の組織があるバグ修正にお金を出していれば、
CollabNet はリソースを他のバグに振り向けることができ、
プロジェクト全体の効率が上がるのです。
他の開発者は、プロジェクトで契約している人がいることを嫌がるでしょうか？
一般的には NO です。特に、お金をもらっている人がコミュニティー内で地位を確立し、
尊敬されているメンバーであるときは特にそうです。
契約がすべてのコミッターに平等に行き渡ると思っている人なんて誰もいません。
コミュニティーのメンバーは、スポンサーと長期に渡って関係を築くことが重要だとわかっていますが、
不安なのは、一度あなたが信頼できる人を見つけてしまったら、
公平さを保つために他の人に仕事を振りたがらないことでしょう。
これについては次のように考えましょう:
はじめに誰かを雇うとき、必ず 誰かを 選ばなければならないのだから、
反対はでないでしょう — 仮に誰も雇わなくてもあなたの落ち度はありません。
後に、2度目になって同じ人を雇ったとしても、それは常識から外れていません。
あなたは彼を知っていて、直近の仕事は成功しているのです。
どうしてリスクをとる必要があるでしょうか？ こうした理由から、
仕事を皆に平等に振るのではなくて、
コミュニティー内に突出した人がひとりやふたり出てきたっておかしくありません。
プログラミング以外の活動を支援する
プログラミングはオープンソースプロジェクトで行われる活動の一部に過ぎません。プロジェクトのボランティアから見ると、プログラミングはもっとも目立つ、華やかな部分です。このことは、ドキュメントやテストなどのプログラミング以外の活動が、少なくとも独占的なソフトウェアと比較すると残念ながら無視されることがある、ということを意味しています。企業は、自らが持つソフトウェア開発の内部インフラをオープンソースプロジェクトに与えることで、こうした無視されがちな活動を埋め合わせることができます。
内部インフラをオープンソースプロジェクトにうまく与えるための鍵は、企業の内部プロセスをオープンソースプロジェクトのそれに変換することです。この変換にはそれなりの努力が必要です。企業の内部プロセスとオープンソースプロジェクトのそれは一致しないことが多いですし、そうした違いは人間が介入しないと埋められないものだからです。たとえば、企業とオープンソースプロジェクトは異なるバグ追跡システムを使っているかもしれません。たとえ同じものを使っていたとしても、蓄積したデータが全く違うかもしれません。なぜなら、企業のバグ追跡の対象がオープンソースプロジェクトのそれとは全く違うからです。一方のシステムにある情報の断片は、もう片方のシステムに反映させるべきかもしれませんし、企業秘密に関わるものだから削除すべきかもしれませんし、一方にないものをもう片方に追加しなければいけないかもしれません。
ここでは、企業とオープンソースプロジェクトをそうした点で橋渡しする方法を説明します。うまく橋渡しすれば、オープンソースプロジェクトがより順調に動き、コミュニティーは与えられたリソースを理解するはずです。また、企業が自分のエゴのために物事を不適切に進めているのではないかと疑わなくなるはずです。
品質保証 (テストの専門家など)
独占的なソフトウェアの開発では、バグ探しやパフォーマンス、
スケーラビリティのテスト、インターフェイスやドキュメントの確認、
などの品質保証専門チームを置くことが普通です。
フリーソフトウェアプロジェクトのボランティアなコミュニティーでは、
品質保証に関する活動は積極的に行われないのが一般的です。
これはテストのような地味な仕事をやってくれるボランティアの人はなかなか見つかりませんし、
ユーザー数が多いプロジェクトのコミュニティーでは、
テストの網羅率が高くなると人々が考えるということもあります。
また、パフォーマンスやスケーラビリティのテストの場合は、
ボランティアは必要なハードウェアリソースを得られないから、
ということもあります。
多くのユーザーを抱えているプロダクトには多くのテスターがいる、
という考えは全く根拠がないものではありません。一般的な環境で、
基礎的な機能にテスターを割り当てるのはあまり意味がないのは確かです。
なぜなら、そういう状況ではバグがすぐに見つかるのが自然の流れだからです。
しかし、ユーザーはただ仕事をこなそうとするだけなので、
プログラムの動作の限界を意図的に探そうとはしません。
よってある程度のバグが残る可能性があります。
さらに、容易に回避する方法があるバグの場合、
ユーザーはバグを報告せずに黙ってその回避策を使ってしまうことが多いです。
もっとも油断ならないのは、あなたの顧客
(あなたが 関心がある人たちです)
のソフトウェアの使い方が、
そこら辺にいる平均的なユーザーの使い方と違う場合があることです。
テスト専門のチームは、
こうした手合いのバグをフリーソフトウェアでも発見してくれます。
難しいのは、テストチームが行った作業の結果を、
わかりやすい方法で皆に伝えることです。
組織内のテスト専門部署は、
テスト結果を報告する独自のやり方をそれぞれ持っています。
たとえば企業独自の方言や、
特定の顧客や彼ら向けのデータに関する特定の知識などです。
こういった独自の情報は、書式や秘密保持の観点から、
公開されているバグ追跡システムに載せるのは不適切です。
たとえあなたの企業で使っているバグ追跡システムが、
フリーソフトウェアプロジェクトのそれと同じだったとしても、
特定の企業向けのコメントやバグに関するメタデータ
(たとえば、バグに対する内部的な優先度や、
特定の顧客向けに解決するスケジュール) を作る必要があるでしょう。
こうした情報は外部には漏らさないのが普通です—
場合によっては、顧客にすらみせてはいけないものです。
しかし、たとえ秘密でなくても、
それらはフリーソフトウェアプロジェクトにとっては関心がないものです。
よって、そうした情報に気を取られてはいけません。
しかしながら、バグ報告そのもの はフリーソフトウェアプロジェクトにとって重要なものです。
実際、テスト専門のチームからあがってきたバグ報告は、
多くのユーザーから受け取るそれよりもある意味価値があるものです。
なぜなら、彼らはユーザーが調べてくれないことを調べてくれるからです。
テストチームからしかあがってこないバグ報告がある場合、
確実に保存してフリーソフトウェアプロジェクトが利用できるようにしておきます。
確実に保存するには、彼らが直接バグ追跡システムに問題を登録するか、
彼らとの仲介役 (通常は開発者のひとり) が、
内部向けのバグ報告を新しいものに「翻訳」してバグ追跡システムに登録するようにします。
ここでいう「翻訳」とは、単に顧客特有のデータ (バグの再現手順には、
勿論顧客の同意を得た上で顧客のデータを使う場合があります)
を参照せずにバグについて説明することです。
テストチームが直接問題を登録する方がどちらかといえば望ましいです。
こうすることで、あなたの企業がプロジェクトに直接貢献していることをアピールできるからです。
役に立つバグ報告をすると、
技術的な貢献をすることと同じくらいあなたの組織への信頼は高まります。
これは開発者にとっては、
テストチームと直接話をする機会に繋がります。
たとえば、テストチームがプロジェクトのバグ報告システムを見張ってくれている場合、
開発者はスケーラビリティに関するバグ (これをテストするリソースを彼らは持たない場合があります) を修正する作業に注力でき、
その修正が望ましい結果を出しているか検証するよう、
バグ追跡システム上にコメントすることでテストチームに頼むことができます。
開発者から多少の抵抗があることは覚悟しておいてください。
プログラマーは、テストをせいぜい必要悪くらいにしか思わない傾向があるからです。
テストチームが重要なバグを発見し、
理解しやすいバグ報告を行えば、こうした抵抗を振り払うのは簡単です。
一方、彼らのバグ報告の質がユーザーからあがってくるそれと大差ない場合は、
開発者と彼らが直接話をする意味はありません。
どちらにせよ、組織内部のバグ報告が、
外部のバグ追跡システムにいったん登録されたら、
組織内部の情報は、そのバグ追跡システムのものを参照させるべきです。
組織の管理者や雇われている開発者は、
必要に応じて顧客に特有の情報について注釈を付けても構いませんが、
みんなが使えるようにするために、外部の情報を利用するようにしましょう。
こうした作業の過程で、あなたには余計な負担が掛かるはずです。
ひとつしかバグがないのに二重にバグ報告を管理するのは、
ひとつを管理するのに比べて仕事が多くなるのは当然です。
ただ、こうすることで多くのプログラマーがバグ報告の情報を利用でき、
問題の解決に貢献できるようになるのです。
法律上の助言、権利の保護
営利企業であれ、非営利な組織であれ、
法人はフリーソフトウェアに潜む複雑な法律問題に注意を払う機会があるほぼ唯一の組織です。
開発者個人は、オープンソースライセンスの微妙な違いを理解している人もいますが、
著作権、商標、そして特許に関する法律の詳細を理解するためのリソースも時間もないのが普通です。
あなたの組織に法務部がある場合、
プログラムについている著作権の状態を調査したり、
実際に起こりうる特許や商標の問題について開発者に具体的に助言することができます。
こうした点で開発者を助ける正しいやり方は、
で議論しています。
もっとも重要なのは、法務部と開発者コミュニティーがコミュニケーションを取る必要がある場合、
それぞれが全く違う世界にいることを認識した上で話をすることです。
お互いが過去に話したことがある場合もあれば、
一方が全く知らない専門領域に関する知識を持っているものとめいめいが思い込んでいる場合もあります。
一番よいのは、仲介役となる人 (開発者か、技術的な専門知識をもった弁護士) を必要な限り間に置くことです。
ドキュメントやユーザビリティの改善
ドキュメントとユーザビリティは、両方ともオープンソースプロジェクトの弱点として有名ですが、
私は少なくともドキュメントについては、独占的なソフトウェアとの違いが誇張されていると思っています。
とは言っても経験上は、素晴らしいドキュメントやユーザビリティ調査が多くのオープンソースプロジェクトに欠けているのは事実です。
あなたの組織がプロジェクトにあるこれらの穴を埋めたいのなら、
プロジェクトの開発者ではなく、
彼らと建設的に話ができる人を雇うとよいでしょう。
プロジェクトの開発者を雇わない方がよい理由はふたつあります。
ひとつは、プロジェクトから離れてしまうと開発する時間がとれなくなること。
もうひとつは、対象となるソフトウェアにあまりにも距離が近い人は、
第3者の視点からそれを眺めるのが難しいために、
ドキュメントを書いたりユーザビリティを調べるのに普通向いていないからです。
しかしながら、開発者と話をしながらこれらの問題に取り組んでくれる人は必要です。
彼らと話せるだけの技術スキルがあるものの、対象となるソフトウェアに精通しておらず、
普通のユーザーに感情移入できる人を探しましょう。
中級者レベルのユーザーが、ドキュメントを書くのに多分向いているでしょう。
実際、この本の第1版が世に出たあと、
私は Dirk Reiner というオープンソースソフトウェアの開発者から次のようなメールを受け取っています。
「5.カネに関する問題」の「ドキュメントやユーザビリティの改善」についてひと言。
もし人に支払えるだけのお金があって、もっとも必要となっているのが初心者向けの
チュートリアルだという話になったとき、私が実際に雇ったのは中級者レベルのユー
ザーでした。彼はシステムに関する研修を最近受けていたので、何が問題になるのか
を覚えていましたし、問題を乗り越えてきていたので、どう人に説明すればいいかを
分かっていました。このため、彼が書いたドキュメントは、彼自身が理解できなかっ
た部分については、開発者がちょっと修正すればすみましたし、開発者が「自明な」
ものとして見逃していた部分も網羅できていたのです。
もっとも、彼の仕事は多くの人(生徒)にシステムを紹介することでした。よって彼は
自分が教えた人達の経験、つまりほとんどの人が理解できなかったことや、たまたま
うまくできたこと、をうまく組み合わせることができました。
よって、彼が書いたドキュメントはさらに素晴らしいものになっていたのです。
ホスティングサイトや接続回線を提供する
一通りのツールが揃ったホスティングサイト (
の を参照してください) を使っていないプロジェクトに対して、
サーバやネットワーク接続を提供—
もっとも重要なのはシステム管理を手助けすることですが—すると、
プロジェクトが大いに助かる可能性があります。
たとえそれがあなたの組織ができる全てであったとしても、
世間的に良い評価を得るためにそれなりの手段になることでしょう。
但し、プロジェクト全体の方向性に影響を与えることはできません。
ホスティングサイトを提供していることに感謝の意を表すために、
プロジェクトのホームページにお礼の言葉を載せてもらったり、
バナー広告を貼らせてもらえることが期待できます。
ホスティングの設定にあたって、プロジェクトのURLをあなたの企業のドメイン内に設定した場合、
URLだけでプロジェクトとあなたの企業が関係があることを理解してもらえるでしょう。
これによって、あなたの企業が開発に全く貢献していなくても、
ほとんどのユーザーが 何かしらの 関係があると看做すようになります。
問題は、ユーザーがそう考えることに開発者も気づくため、
ホスティングサイトやネットワーク回線以外の開発リソースを提供しなければ、
あなたのドメイン内にプロジェクトを置くことにあまりいい感情を持たない可能性があることです。
何だかんだ言っても、最近はたくさんのホスティングサイトがあります。
コミュニティーは結局、実態に見合わないクレジットを与えるのは、
ホスティングを提供してもらう利点に見合わないと感じて、
プロジェクトを他に移してしまうでしょう。
よって、あなたがホスティングサイトを提供したいなら、そうすると良いでしょう—
但し、すぐにもっと積極的にプロジェクトに関わるプランを示すか、
自分の主張がどれくらいプロジェクトに影響を与えられるかについて、
よく考える必要があります。
マーケティング
ほとんどのオープンソースプロジェクトの開発者は認めたがらないでしょうが、
マーケティングは役に立つものです。マーケティング活動をうまくやれば、
頭の固いプログラマーが理由もよくわからないのに、
そのソフトウェアに対して良い印象を持つくらいにまで、
オープンソース界隈の評判を作り出すことができます。
ここでは、マーケティングにおける競争力学を一般的に分析するわけではありません。
フリーソフトウェアの世界に関わっている企業は結局、企業自体や、ソフトウェア、
そしてソフトウェアと企業の関係をどうやって売り込んでいくか、を考えるようになります。
以下では、こうした努力をするにあたって陥りがちな一般的な落とし穴について解説します。
の も参照してください。
見られていることを意識する
ボランティアの開発者コミュニティーをあなたの味方に付けるには、
はっきりしていない事柄は喋らないことが とても 重要です。
すべての主張を公にする前に注意深く調べ、その主張自体をチェックする手段も公にしておきます。
独自に事実を検証できるのは、オープンソースの重要な部分です。
それはコード以外の部分にも当てはまります。
当然のことながら、検証できない主張をするなと企業にアドバイスする人などいません。
しかし、ことオープンソースの活動においては、
主張を検証する経験に長けた人が非常に多くいます—
なぜなら、広い帯域のインターネット接続回線を持ち、
物事を中傷するために社会的接触を持つ可能性がある人が大勢いるからです。
化学工業の巨大企業が川を汚染している場合、それは検証可能ですが、
検証できるのは訓練を受けた科学者のみです。
彼らは巨大企業の科学者から反論され、
頭をかきむしってどう考えたらよいのか困惑するかもしれません。
一方で、オープンソースの世界であなたがすることは、
目に見える形で記録されるだけではありません。多くの人が独立してチェックし、
独自の結論を下し、それらを口コミで広めていくのです。
この口コミのネットワークは既に定着しているものです。つまり、
オープンソースがどのように影響するかを決める要素であり、
あらゆる種類の情報を伝えるのに使われます。反論は不可能ではないにしても、
特に人々が言っていることが事実である場合は、普通難しいものです。
たとえば、"プロジェクトXを作った" とあなたの組織が言うのは、
実際にそうしたのであれば問題ありません。しかし、
実際にコードを書いたのが外部の人間である場合、
"Xというソフトウェアを作った" と言ってはいけません。
逆に、誰かがリポジトリの中身を覗いてみて、
あなたの組織以外の人が変更を加えた跡が殆どまたは全くない場合は、
ボランティアの開発者コミュニティーが深く関与していると主張してはいけません。
それほど昔のことではありませんが、
とてもよく知られているコンピューター会社が、
重要なソフトウェアパッケージをオープンソースライセンスの下で公開した、
というアナウンスを見ました。はじめのアナウンスが出た後、
私は公開されているバージョン管理システムのリポジトリを見てみましたが、
そこには3つのリビジョンしか存在していませんでした。
言い換えれば、彼らはソースコードのインポートを終えたこと以外は何もしていなかったのです。
それ自体は変な事ではありませんでした。—
だって結局彼らはアナウンスしただけですから。
しかし、すぐに活発な開発が行われると期待する理由は何もなかったのです。
しばらくたってから、別のアナウンスがありました。以下にそれを示しますが、
リリースナンバーとソフトウェアの名前は別のものに置き換えてあります。
Singer コミュニティーによって厳密にテストされた後、
Singer 5の Linux 版と Windows 版が、
製品としての使用に耐える品質になったことを発表します。
"厳密なテスト" によってコミュニティーが明らかにしたことを知りたいと思い、
私はリポジトリを再度見に行って最近の変更履歴を覗いてみました。
プロジェクト自体のリビジョンは3のままでした。明らかに、
コミュニティーはリリース前に修正すべきバグを ひとつも 見つけていなかったのです！
コミュニティーによるテスト結果がどこかに記録されているはずだと考えて、
私は次にバグ追跡システムを調べてみました。そこには確かに6つの問題が記録されていましたが、
そのうちの4つは数ヶ月の間保留状態のままだったのです。
これは勿論信じがたいことです。
テスターが巨大かつ複雑なソフトウェアをそれなりの時間使えば、
彼らはバグを見つけるものです。
たとえそうしたバグが次回のリリースに取り込まれなかったとしても、
テストの結果としてバージョン管理システム上での活動か、
新しい問題がバグ追跡システムに登録されていると期待されるはずです。
しかしながら、どこを見ても、はじめのアナウンスと、
その次のアナウンスとの間に活動の跡はみられなかったのです。
問題は、コミュニティーがテストしたことについて、企業が嘘をついたことではありません。
コミュニティーがテストしたかどうかは私には分からないからです。
しかし、彼らが言っていることがどれくらい嘘っぽいかは明らかでした。
バージョン管理システムだけでなく、バグ追跡システムにも、
厳密なテストが行われたことを示す痕跡はなかったので、
企業はコミュニティーがテストしたという主張をしないか、
目に見える形のテスト結果へのリンク ("278個のバグが発見されました。
詳細はここをクリックしてください") を提供すべきでした。
後者は誰でもコミュニティーの活動レベルを素早く把握できるようにするものです。
実際は、コミュニティーがテストしたことを探すのに2、3分しかかかりませんでしたし、
普通なら記録される場所に、テストの痕跡が全く残っていなかったのです。
検証するのに大した手間はかかりませんでしたが、
手間をかけたのは私だけではないはずです。
透明性と検証可能性は、正確なクレジットを与えるときも勿論重要です。
詳しくは、 の を参照してください。
競合するオープンソースプロジェクトを攻撃しない
競合するオープンソースプロジェクトについて、否定的な意見を述べるのはやめましょう。
否定的な 事実 については一向に構いません。
— 容易に裏が取れる主張は、比較の要素としてよく見られるものだからです。
しかし、あいまいな事柄に対して否定的な評価を行うことは避けた方が良いでしょう。
理由はふたつあります。
まず、それがきっかけで建設的でないフレームウォーが起こりがちだからです。
ふたつめは、もっと重要なことですが、
あなたの プロジェクトにいるボランティアの開発者の中からも、
競合プロジェクトで働く人が出る可能性があるからです。
前者より、後者の方が多く発生する可能性が高いです。
なぜなら、それぞれのプロジェクトは既に同じ専門領域に属していて(それゆえに競合関係にあります)、
その領域で専門知識を持っている開発者は、
それを生かせる場所であればどのプロジェクトでも貢献してよいからです。
直接的には開発者が重複していない状況でも、あなたのプロジェクトにいる開発者が、
関連するプロジェクトの開発者を知っている可能性があります。
彼らの建設的な人間関係を維持する能力が、
否定的なマーケティングのメッセージによって全て壊れてしまう可能性だってあるのです。
ソースコードが公開されていない競合プロジェクトを攻撃することは、
特にその製品がマイクロソフト製である場合は、
オープンソースの世界では広く受け入れられています。
個人的には、この傾向は (単刀直入に事実を比較するのであれば一向に構わないのですが)
残念に思っています。
なぜなら、これは相手に失礼であるからというだけでなく、
プロジェクトが自ら作っているものの誇大広告を信じ、
それゆえに競合相手が実際に優れている点を無視し始めるのが危険でもあるからです。
一般的には、マーケティングのメッセージが、
自分たちの開発コミュニティーにも影響を与えるものかどうかを注意しておくとよいでしょう。
マーケティングにお金が使われると、
開発者は自分達のソフトウェアが持っている本当の強みや弱点を、
客観的な眼で見なくなってしまいます。
このため、企業の開発者はマーケティング上のメッセージに対して、
公のフォーラム上でさえある種無関心な態度を示すのが普通ですし、
むしろそれが期待されています。
はっきりしているのは、企業の開発者はマーケティングによるメッセージに対して、
公の場で矛盾した態度を直接示してはいけない (但し、
それが実際に間違っているというのなら別ですが、
その手の事実は早い段階からわかることでしょう) ということです。
企業の開発者はそうしたメッセージをネタとして扱い、
コミュニティーをマーケティングのメッセージから現実に引き戻す手段にしているのです。
Hiring Open Source Developers
24 March 2013: If you're reading this note, then
you've encountered this section while it's undergoing substantial
revision; see producingoss.com/v2.html for details.
poss2 todo: Not sure this is necessary as a separate section,
but consider it. Ref Fitz's article, obviously. Move material from
above into here. Look at gun.io.
Bounties
24 March 2013: If you're reading this note, then
you've encountered this section while it's undergoing substantial
revision; see producingoss.com/v2.html for details.
poss2 todo: Theory: bounties usually don't work in practice.
Ask around, look for counterexamples. What about gun.io?