オープンソースプロジェクトに参加したいな、と思った時、まず最初に問題だと感じるのは英語だと思う。構成員が日本人だけで、日本人に向けてのみ出しているそソフトウェアでない限り、プロジェクトの共通語はふつう英語だ。植山さんの記事には英語で物事を進めることの利点が体験談とともに書かれている。他の記事にも、オープンソースプロジェクトで上手いことやっていくためのひとつとして英語の話が出てくる。一方、英語のせいで参加したくても二の足を踏んでしまう、というのもよく聞く話だ。結論から言ってしまうと、やっぱり読み書きだけでも習得しないと話に入っていくのは難しい。ソフトウェア開発者の多くは多様性に対して寛容なので、英語が不得意という理由で拒絶されることはないだろう。ただ、特別な配慮もしてくれない。
しかし英語の前に、プロジェクトとの距離のとりかたを学ぶべきだと思う。いままでわたしが見てきたり、自分自身がやって良くなかったなと思う例を思い出しながら書いてみることにする。
プロジェクトへ参加したいひとへ
まず、メーリングリストや掲示板など、プロジェクトの開発者がコミュニケーションに使っているところに行こう。いまどきのプロジェクトはメーリングリストを使っていないかも知れないが、便宜上、以降では情報交換の場の代表としてメーリングリストという言葉を使うことにする。あなたはプロジェクトがどういうソフトウェアを作っているのかは、すでに知っているのだと思う。最初に学ぶべきは、「誰が」「何を」やっているのかということだ。プロジェクトは「ひと」で動いているので、自分の興味ある内容を実際にやっている開発者が誰なのかを知らないと、先に進めない。メーリングリストに参加して一カ月もすれば、「ああこの名前は良く見るなあ」というひとが見つかるはずだ。逆に、一カ月経過してもメールが全然流れなかったら、そのプロジェクトは活発な活動がなくなっているか、あなたが間違ったところを見ている。
誰が何をやっているのかが何となくわかったら、自分が何をしたいのかをもう一度考えよう。利用者として情報が欲しいだけなら、参加しているメーリングリストなどで時おり自分の質問を投稿したり、他人の質問にアドバイスしたりする活動が良い。「こう操作すると動作がおかしいんだけど」「こういう機能があると便利だと思うんだけど、何とかならないかな」というような投稿も、プロジェクトにとってプラスであることが多い。開発者が興味がないことは返事がないだろうし、興味があれば反応が来るだろう。返事が来るかどうか気になると思うけれど、あまり過度な期待はしないこと。あなたがプロジェクトに責任を持たなくて良いように、開発者もあなたの発言にいちいち反応しなければならない理由はないからだ。
利用者の立場からプロジェクトに参加しているひとの多くは、そういったコミュニケーションを続けている。コードも何も書いてないけれど、これは立派に参加していると言って良い。「何かを貢献しなきゃ」という意識は、あまり強く持たないことをお勧めする。気合いを入れれば入れるほど、それを受け入れてくれなかった時に落ち込むことになるからだ。自分がつくり出すものは、まず自分が有用だと思えるものでないと続かない。
利用者と開発者の区別は、コードを書くかどうかではなく、「自身の成果をプロジェクトに提供するひとかどうか」ということである。プロジェクトに参加する自らの姿勢の問題であり、実際に提供したものが受け入れられるかどうかは関係ない。プロジェクト側が区別したり、誰かが認めたりするものではないので注意していただきたい。
利用者として参加するときに求められること
端的には、コミュニケーション（メーリングリストを読むとか、掲示板を読むということ）に時間がかけられるかどうかが問われる。もちろん全部読む必要はなく、自分の興味のある部分だけで良い。そのような場所でのやりとりはプロジェクトにおける一次情報なので、まとまっていないしノイズも多い。リリースのときに情報が得られれば十分で、日常的にメールを読むなんて面倒だな、と思うひとは、参加しないほうが良いだろう。ここでひとつの判断基準になるのは、あなたがプロジェクトに興味があるのか、プロジェクトの生み出すソフトウェアに興味があるのか、という点だ。あなたが食事をしたいと思ってレストランに入った時、厨房でどうやって料理しているのか知りたいだろうか? プロジェクトのメーリングリストを読むというのは、そういう行為だ。最終的にできあがるソフトウェアだけに興味があるなら、出来上がるまでの過程を眺めてもしょうがない。
「料理をしているところを眺める気はないけど、食事はしたいからレストランは残ってて欲しい」という立場なら、プロジェクトに対して金銭的な支援ができないか調べよう。寄付を受け付けているところは多いし、もしそういう案内がなければ、開発者のいるところで率直に「寄付をしたいけどどうすれば良いの?」と聞いてみるのもひとつの方法だ。お金の他に、PCなどのハードウェアを寄贈するという方法もある。開発者の輪の中に入らず、もっと遠くからプロジェクトに貢献することは十分可能だ。
一方、「厨房で行なわれる料理を眺めていたい」というタイプのひとは、プロジェクトに興味があるひとだ。利用者の立場でプロジェクトを眺めていれば、説明文書やウェブページの整備という作業がプロジェクトの中ではなかなか進んでいないことに気が付くはずだ。ソフトウェア開発が中心のプロジェクトは、そういった部分に時間を多く割くことができない。「ここ情報が古いので、僕が更新しますよ」と言えば、歓迎してくれるだろう。同じ線上にある作業は、文書の翻訳だ。ただし、この手の作業は終りがなく、モチベーションを維持するのは難しいことをあらかじめ覚悟しておこう。
あなたは自分の作ったものを提出したり、自分の意見を表明することを躊躇するかも知れない。「こんな内容で良いのだろうか」「くだらない、品質が低いと言われたらショックだし、恥ずかしい」、そう思うかも知れない。こういう感情は、あなた以外もみんな持っている。自分のつくったものに対する意見を受け取るのは、誰だってある種の不安を感じることだ。自分で生み出したものには愛着があったり責任を感じるので、それを否定されることは自分や自分の能力が否定されるようで辛い。意識的に考えていなくても、共同社会で「何か独自のものを生み出して外に出す」という作業は辛いのだ。小説家、画家、音楽家、スポーツ選手や芸人といった職業は、常にこの種のストレスに晒されている。程度の差はあっても、人間であれば誰もが感じるストレスだ。どんなに優秀で経験を積んだプログラマであっても変わらない。
この辛さを乗り越えるには、価値基準を自分に置くことと、ひとつのものに拘らないことの 2 点が重要になる。自分のつくったものは、まず自分でその価値を認めてあげなければならない。誰に何と言われても、自分で役に立つと思うものをつくったなら、批判があっても深刻に受け入れる必要はない。また、「どうしてもこれが受け入れられないと嫌だ」というような拘りは、ある程度の範囲までにとどめよう。自分が貢献できる部分は貢献し、受け入れてもらえなかった部分は自分の中にとどめておけば良い。
自分自身が興味のあることをやって、その成果を提供しよう。「これをやればみんなの役に立てる」という発想で何かに取り組むのは、相当の覚悟がない限りは止めよう。続けるのが辛くなり、やがて取り組みに対する批判に耐えられなくなる時が来るからだ。仕事でもないのに、あなたが楽しめないことを続ける理由はない。逆に、あなたが極端に苦しむことなく文書などを成果として継続的に提供できるのであれば、開発者として貢献できる可能性が高い。
簡単にまとめると次のようになる。プロジェクトを理解し、ゴールを共有して参加するのは、開発者でなくても可能だ。
- プロジェクトの開発者がコミュニケーションをとっている場に参加すること。メーリングリスト、IRC、電子掲示板などオンラインの情報交換に加えて、カンファレンスなどのイベントもある。
- プロジェクトとの距離を意識すること。アナウンス用のメーリングリストだけを購読するのか、開発者の意見が飛び交うメーリングリストを読むのか、さらに自分でそこに積極的に投稿するのか、段階はさまざまある。あなたが興味があるのは何だろうか?
- 質問する、質問に答える、意見するというアクションは、利用者として貢献できる方法のひとつだ。メーリングリストを読むのは面倒だけど貢献したいなら、寄付する、宣伝する（たとえばそのソフトウェアのインストール記事をあなたの blogに書く）という手もある。
- 貢献を義務だと思う必要はない。自分のペースでやれることをやれば良い。
プロジェクトが求める人材とは
当然ながら、プロジェクトを動かしているのは「ひと」だ。あなたが開発者として参加したいと思った時にプロジェクトがあなたを歓迎するかどうかは、必ずしも「何らかの能力が秀でているかどうか」という基準で量られるわけではない。IEEE Spectrum 1999年10月号に、“How to be a Star Engineer”（PDF, 英語）という記事が載っている。IEEE はアイ・トリプル・イー（これが現在の正式な日本語表記である）と呼ばれる、米国に本拠地を置く電気工学・電子工学を中心とする技術者の組織である。Spectrumはその機関誌であり、さまざまな話題が載っている。その記事はカーネギーメロン大学のR.E.Kelleyという経営管理論の教授による「優れた技術者になるために必要なことは何だろうか」ということを書いたエッセイだ。日本の電子情報通信学会が 2001 年に翻訳版を「優秀なエンジニアになる方法」(PDF, 日本語)という題名で学会誌に載せている。面白い文章なので、一読をお勧めする。長いな、と思うひとは第1節と第2節までを読めば十分だ。
プロジェクトが求める人材は、第2節に出てくるヘンリとライの両方だ。プロジェクトは技術的な能力が高いひとが欲しい。しかしそれ以上に、みんなと仲良く同じゴールを目指してくれるひとを欲している。たとえばあなたが積極的にメーリングリストで初心者の相手をしてくれることは、プロジェクトにとって大きなプラスになる。プロジェクトやプロジェクトを中心とする開発者のコミュニティに利用者として参加することは、決して価値の低いことではない。あなた自身も、活動を通じてプロジェクトやソフトウェアについて学び、将来的により多様な貢献ができるかも知れない。
利用者としての関わりから、その後に開発者になった人もたくさんいる。すでに書いたとおり利用者と開発者は姿勢の問題なので、利用者が下で開発者が上、というような序列があるわけではない（一方で、このように信じているひとは多いは事実だが）。あなたがソフトウェア開発に興味があるのであれば、プロジェクトに利用者として参加しながら勉強するのもひとつの手だ。わたしは著名なプログラマがどういうコードを書いているのか、共同作業でどう意見交換をして物事を進めているのかにとても興味があった（今もある）。なので、特定の何人かの開発者の変更には目をとおして、そこからいろいろなテクニックを学んだ。本業では莫大な報酬を約束されるような優秀な開発者が書いているコードを無料で読めるというのは、素晴らしいことだと思う。
開発者として参加するときの距離感
コードを書いて貢献したいと思うひとは、利用者としてメーリングリストなどの情報交換の場に参加した後に、すでにいる開発者とコミュニケーションをとろう。コードを書いたら、開発者に伝えれば良い。メールで送るのが良いのか、Git の pull request にするのが良いのか、bugzilla にパッチを入れて PR を投稿すれば良いのか、プロジェクトによって風土が異なる部分が大きい。開発ツールの使い方がわからなければ、まずその勉強が必要だ。これは文書の貢献でも同じである。
自分の成果を提出する時には、「誰に伝えるのか」を意識すること。プロジェクトが小さければ主要な開発者に直接伝えるだけで十分だが、プロジェクトが大きい場合は、自分の変更に興味を持ったり、内容を理解してくれる開発者を絞りこんだほうが良い。メーリングリストを読んでいれば、誰が何に取り組んでいるのか学べるはずだ。それで足りなければ、そのプロジェクトが使っているバージョン管理システムやメーリングリストのアーカイブを使って、過去の変更者を調べよう。どうしてもわからなければ、メールなどで誰が詳しいのか聞いてしまうのが早いかも知れない。
誰が担当なのかを勉強せずに巨大な成果物を送りつけても、無視されるか受け入れるのに長い時間がかかることが多い。プロジェクトにはあなたのコードを受け入れる義務はないし、役所に書類を提出するのと違って、提出されたものが必ず処理されると期待できるものでもない。
どうすれば良いのだろうか。オープンソースプロジェクトは、多くの人が思うよりもっと人間的なものだ。かなり大きな組織であっても、重要な意思決定が飲み会の場で数人が話をして決まるようなことはよくあるし、いつも万人に公平な態度をとるわけではない。同じ目的を達成できるコードが 2 つあったとして、ひとつはいつも貢献している昔からいる開発者が作った少々品質の劣るコード、もうひとつは、どこの誰とも分からないひとから送られてきた品質の良いコードだったとしたら、どっちが採用されるだろうか。品質が良いコードがあるならそっちなのでは、と思うかも知れないが、前者が採用されることも良くある。
ここで重要なのは、将来的にこのコードの面倒を誰が見るのかという点である。プロジェクトの典型的な思考は次のようなものだ。昔からいる開発者であれば、おそらくすぐにはいなくならないだろう。どういう性格なのかも良く分かっている。コードの品質の悪いところは改善可能だ。まずいところを本人に伝えて、改善してから採用すれば良い。
一方、品質の良い、どこかから送られてきたコードは、開発したひととコミュニケーションがとれるかどうかで将来が決まる。送った開発者とメールのやりとりができるなら、「開発者として参加しませんか」と誘われるかも知れない。しかし、開発者と連絡がとれなかったり、最初は連絡がとれてもそのうち消息が分からなくなってしまうような印象があったとしたら、採用を躊躇してしまう。もちろん、すでにいる開発者が、その送られてきたコードの面倒をみることが無理なく可能だと判断すれば、採用するかも知れない。
この背後にあるのは、信頼できるかどうかという評価尺度である。あたりまえのことだが、初対面のひとより、いつもいるひとのほうが仲間意識が強い。共同体においてこれはとても重要だ。いつもいてプロジェクトのゴールを共有しているという姿勢を見せ続けるひとは信頼される。たとえば、メーリングリストでの質問に定期的に的確な答えを返しているひとがいたら、開発者の多くは名前を覚えるだろう。そしてそのひとが「コードを書いたんだけど」と成果物を出してきたら、おそらくみんな協力的になる。いつも初心者の相手という大変な作業をし続けている姿を見ているので、どうにか協力してあげたいな、という気持ちになるからだ。この気持ちの源泉は同じコミュニティにいるという仲間意識であり、プロジェクトを良くしていこうというゴールの共有である。そのひとが書くコードは拙く、採用されないかも知れない。しかし、もっと能力の高い開発者からのアドバイスは確実にもらえる。コードを書いた本人のコーディング能力も、活動を続けていればいずれ成長するだろう。
もちろん、当然ながら品質の良いコードを書けるひとは最初から信頼される。しかし、それと同じくらい「こいつは目的を共有した仲間なんだろうか」という村社会的意識があるのだ。つまり、開発者として参加するときのプロジェクトとの距離感というのは、開発者間のつきあいの深さ、目的共有の強さである。初対面という印象を拭える程度のつきあいがなければ、ふつうはまず開発者として認めてもらえない。社の主要事業も知らずに就職面接を受ける学生のようなものである。そして、開発者として参加してたくさんコードを書いたとしても、開発者とのコミュニケーションが欠けていると距離は縮まらない。
この距離のとり方は、自分の匙加減だ。わたしはプロジェクトとの距離を縮めて運営や意思決定というところにまで自分の責任範囲を広げたが、距離を保って、ある特定の部分のコードの開発を担当するという参加の方法もある。開発者としての参加の場合、利用者の場合と異なり「何を貢献するのか」がかなり明確なので、自分の負担にならない距離を保って活動を続けるのは難しくない。距離を縮めて損をすることはないので、コミュニケーションにはなるべく参加することをお勧めする。やりとりすることに嫌気がさしてきたら、たぶんあなたはもうそのプロジェクトへの興味を失っているのだと思う。無理して続ける必要はない。
あなたが、あなたにしかできない突出した技術を持つ優秀なプログラマなら話は別だ。そういった価値を持つ人材なら、プロジェクトは金を払ってでも、あなたをプロジェクトに留めようとするだろう。そうでないなら、開発者コミュニティに参加するということは、最終的に他の開発者とのつきあいを深めていくことだということを理解しよう。開発者コミュニティにはさまざまな形で参加しているひとがいて、コードだけで物事が決まるほど単純ではない。コードだけ提供してなるべく他の開発者に近付かずに関わり続けることも不可能ではないが、距離をとりたいならプロジェクトに参加する意味はないと思う。
「パッチを提供したいけど、後々の面倒はみたくないな」というひとは、面倒をみてくれる開発者を探して頼もう。バグ報告のシステムに登録しただけでは見てくれないかも知れないので、「ひと」とコミュニケーションすることが肝要だ。それさえ覚えておけば、自身が開発者としてプロジェクトに関わり続けなくても、コードで貢献することは可能だ。
プロジェクト運営の教訓
開発者コミュニティで開発者とのつきあいが長くなってきたら、プロジェクト運営の仕事をする機会が出てくる。リリースの作成作業であったり、セキュリティ問題への対応であったりと、特定領域で責任者として振舞う開発者である。形態はプロジェクトによってさまざまだ。FreeBSDは最初は複数の創設者が決定権を持っていて、次に意思決定機関であるコアチームをつくって合議制に移行した。コアチームのメンバは 9 名、任期は2年で、開発者の投票によって決まる。コアチームはプロジェクトの責任者にあたる開発者を指名し、個々の領域に責任を持つチームの編成を指示する。主なものにリリースエンジニアリングチーム、セキュリティオフィサ、ドキュメンテーションエンジニアリングチーム、portマネージャチームなどがある。
プロジェクトの意思決定の立場まで行くと、もうちょっとややこしい話が見えてくる。プロジェクト運営にトラブルはつきものだ。開発者間のケンカ、ルールを守らない開発者、メーリングリストなどで暴れる利用者などは分かりやすい例だが、高い能力を持つ開発者間でもプロジェクトの機能不全に陥るような問題が発生することがある。それらに対処しなければならない。
オープンソースプロジェクトの運営には、過去から蓄積された教訓がたくさんある。比較的最近の話をひとつとりあげると、2008年のGoogle I/O では、“How to Protect Your Open Source Project from Poisonous People”（動画）という有名な講演があった。これは Subversion プロジェクトの開発者であるBrian FitzpatrickとBen Collins-Sussman（もちろん両者とも googler だ）による体験談とオープンソースプロジェクト運営者への教訓話だ。動画は長く英語なので乱暴に要約すると、「プロジェクトに関わろうとするひとのうち、ゴールを理解・共有しないひと、自分で調べようとしないひと、現状の批判ばかりするひと、他人の意見を尊重しないひと、自分でできる内容を自分でやらないひとはプロジェクトに有害なひとなので、やんわり退場願おう」という話である。
この要素の中で一番重要なものをひとつあげるとしたら、すでに繰り返し強調しているように「プロジェクトの目的の共有」である。「BSDは亡びていいのに」という発言をするひとは、ゴールを共有していないので相手にされない（おそらく本人も相手をしてほしいとは考えていないと思うが）。OSSコミュニティの継続性で指摘した「利用者目線の意見に興味がない」という態度には、そうしないとプロジェクトにとって危険だということが背景にある。「BSDは存続すべきか」という議論はプロジェクトを徒に消耗させ、得られるものはほとんどない。
人間は、自分の興味のないものほど多様性の価値を低く見積もる傾向がある。わたしはアイドルグループにほとんど興味がないので、50人以上いるAKB48はもっと人数が少なくてもいいんじゃないかと思ったりする。近くの大型ショッピングセンターに行くと自転車売場があるが、たくさん種類が並んでいるのを見るとどうせ似たようなデザインなのだから数種類でいいのでは、とも思ったりする。一方、興味を持っているものにはこだわる。わたしは自分の使うマシンのキーボードに5576-A01を使っている。キーボードなんてどれも同じなんじゃないの、とは思わないし、一種類に統一されて欲しいとも思わない。Mac の市場シェアは Windows よりもだいぶ小さいけれど、わたしは Mac のほうが好みなので使い続けている。
化粧品、時計、服のブランド、なんでも良い。あなたの日常生活でどれでも良いと思っているものと、こだわっているものの違いは何だろうか。そしてあなたは、自分が「どうでも良い」と思っていることに独自の考えを持っているひとと議論ができるだろうか。あなたは他人からこだわりを力説されても、心変わりしたりはしないだろう。ボランティア開発者が行なっているソフトウェア開発プロジェクトは、そのひとが興味があるからやっているのである。興味を持たないひととの価値観の議論は、そもそも噛み合わない。
合わないひととは関わらない、という簡単な話である。「FreeBSDに関係しているひとはへんなひとばかりだ」「そんな考えだからFreeBSDはダメになったんだ」と思うのも、発言するのも自由だと思う。ただ、わたしも含めてプロジェクトの人間はそういう議論はしないし、発言者を説得することもない。価値観は多様性があるものだし、プロジェクトが求めているのは目的を共有してくれるひとだけだ。プロジェクトを守るためには、そういうひとたちの相手はしないのが正しい。プロジェクトに近付いてきて実害が出るようなことがあれば、露骨ではないにしろ何らかの形で排除しようとするだろう。FreeBSDプロジェクトが目指しているのは、みんなを説得してFreeBSDを使わせることではなく、FreeBSDの品質を向上させることだ。そして品質の向上という目的を共有する開発者・利用者の集団を醸成することである。
この講演では、他にも健全な開発者コミュニティを維持するためにプロジェクトが気をつけるべき内容が説明されている。次のようなものだ。
完璧を求める開発者、自分の作業領域から他人を排除しようとする開発者は、プロジェクトの開発を麻痺させるので注意しよう。
目標を明確に、議論は論点を明確にする。同じ議論は繰り返さず、すべてのメールに逐一返信するような会話は避ける。
議論や意思決定の記録をとり、共有する。
開発者間でコミュニケーションを密にとる。コードの変更は互いにレビューする。
開発の手順を決め、文書化する
投票は最後の手段
このような教訓を実践しなければならない立場になることは少ないと思うが、開発者として大きなプロジェクトに関わるときには、多かれ少なかれ開発者同士の意見の衝突を経験することになるだろう。まともなプロジェクト運営者であれば、上述のような開発者コミュニティの外から来る攻撃からプロジェクトを守る努力をしてくれるはずだ。しかし、内部の開発者同士の意見の衝突は自分で何とかしなければならない。そのときに相談できる相手は、やっぱり同じプロジェクトの開発者だ。実生活にいる友人と同じである。普段から仲良くしている相手なら、トラブルの相談も気軽にできるだろう。コードだけのやりとりでは貴重な人脈形成の機会を失ってしまうので、とてももったいない。
仲良きことは…
オープンソースプロジェクトのメーリングリストを眺めていると、「なんでみんなギスギスしてるんだろう」と思うひともいるかも知れない。拙い質問や品質の低いコードにはマサカリが飛びまくる。遠慮がなく口が悪い開発者がいるプロジェクトも、それなりにある。たとえば2013年にLKMLであった Sarah Sharp による Linus の罵詈雑言批判の一幕が江添さんのサイトにまとめられている。彼女は Linux カーネルの xHCI ドライバのメンテナだったが、その後Linuxカーネルの開発者コミュニティを去った。
ここ数年、さまざまなプロジェクトでコミュニティ内のハラスメントや感情的な衝突が問題になり、行動規範 (Code of Conduct) を定めたところが多い。FreeBSDのCoCもウェブサイトに載せてある。これだけで万事解決とは言わないが、コミュニティの構成員が不快な思いをしないですむような努力は継続的に行なわれている。感情的な衝突が発生したら、双方の意見を聞いたり電話で直接本人と話すこともよくある。技術的正当性をふりかざして正論をぶつけるだけでは、ひとのコミュニティはうまく回らない。プロジェクトの外からはメールでのやりとりしか見えないことが多いが、実際のところ運営側でやっていることはもうちょっと複雑だ。Linuxカーネル開発者のコミュニティは大きく、企業ユーザの政治力学が働くなどオープンソースプロジェクトの中では少々特殊な部類に入るので、残念ながら罵詈雑言が消えることはないのかも知れない。
オープンソースプロジェクトに興味のあるひとは、自分の居心地のよいプロジェクトを探してみよう。大学のサークル活動のようなものだと思っていて良い。そこでの活動は、他では得難い経験や知的な刺激が得られる貴重なものになるはずだが、何の集まりなのかを理解せずに入ってもうまく行かない。ソフトウェアそのものだけではなく、プロジェクトの目的を共有するよう心がけることを強くお勧めする。