オープンソースソフトウェアを開発する日々をハッピーに ― あるいは、OSSコントリビュータに感謝を伝えるためにできること

この数か月、複数の人たちがオープンソースから手を引いたり、オープンソースで燃え尽きないよう苦慮したりするのを見てきました(1234)。matplotlibプロジェクトを率いる1人であるThomas Caswellに、私がどのようにオープンソースへの貢献にうまく取り組んでいるかを話したところ、彼はその話を気に入ったと言いました。そこで、私が前向きな気持ちをキープし、オープンソースに貢献し続けるためにどのようにしているか、また、他の人の仕事に感謝の気持ちを表すために何ができるかを共有することにしました。

燃え尽きる理由

しかし、まず初めに、なぜ人はオープンソースで燃え尽きるのかを説明したいと思います。コントリビュータ自身以上にユーザを抱えるプロジェクトの管理に参加するとき、ユーザのことを考えるのは非常に容易になります。普通の人たちが実際にあなたの作品を「役に立つから」と使っているのが分かれば、言いようもない達成感が得られるからです。そしてさらに人々がコントリビュータとして参画し始めるほどあなたのプロジェクトを気に入ってくれれば、さらに満足度は高くなります。

けれども、関心を持たれるということは、ネガティブな要素も、やすやすと拡大されてしまうことを意味します。誰かがプロジェクトにやって来てネガティブな態度を示し始めたら、あなたはひどく傷つくでしょう。こうしてネガティブな要素は、「ここをこのような設計にしたのはなぜ?」といった非常に小さくてささいなことから、「これ作った奴、バカだろ」のレベルにまで一気に幅が広がります。実際のところ、ネガティブ視されるのは簡単です。特に、オープンソースを通して作品を公開し、誰でもアクセスできるようにした場合はなおさらです。さらにほとんどのコミュニケーションはテキスト上なので、文化的な機微は失われたり理解されなかったりもします。

このネガティブさは時間がたつにつれ、オープンソースの寿命を縮めるやっかいな存在になっていくのです。新規プロジェクトを始めるときは、新しいものを作る楽しみが十分に継続の原動力になります。新しいプロジェクトへの貢献を始めるなら、プロジェクトにお返しをすることで影響を与えられるという興奮が、怒涛のように貢献し続ける助けになるでしょう。しかし、プロジェクトがより成熟し、参加期間が長くなってくると、新しいコードを出しにくくなり、最初のパッチを当てるような喜びは減り、ただのメンテナンス作業になっていきます。気づけば、バグを直したり、質問に答えたり、決して魅力的でなく、プログラミングの「お楽しみ」部分でもない作業で終わっているわけです(こう考えてみましょう。つまらないと感じる仕事を思い浮かべ、それからそのつまらない仕事を、余暇に家で「お楽しみ」を楽しむためにやるのだと考えてみてください。オープンソースプロジェクトのメンテナンス作業がどういうものか想像できるのではないでしょうか)。つまり、プロジェクトのメンテナンス作業を行っている人々にとって、達成感は過ぎ去ったものでしかないのです。時間がたつと、かつては貢献によって得ることができた個人の内面の前向きな気持ちはいとも簡単に外部のマイナス要素に押しつぶされてしまうのです。

私の対処法

いちプロジェクトとしてのPythonに関わることができた私はとても幸運でした。Alex Martelliが私のレシピの1つPython Cookbookの初版に収録してくれたとき、私は学部と大学院の間に、1年間の休みをとろうとしていました(まだ修士課程に在学していませんでした)。そこで私はその期間、Pythonに取り組むことを自分の「仕事」と決め、自作のレシピを自分流に使い、試行錯誤してPythonに貢献しました(これは最終的に、Pythonのtime.strptime()になりました)。それが2002年のことで、Pythonはほとんど知られていませんでしたが、上り調子にありました。私は地上階でそれに飛び乗ったと言えるでしょう(とはいえ、GuidoがオープンソースとしてPythonを初公開したのは1991年ですから、私が参加した当時で既に10年を経過したプロジェクトだったのです)。

話を早送りすると、それから今日まで、私はある程度のレベルで13年間Pythonに貢献し続けています。 ACKS fileに自分の名前が載っているのは大きな喜びです。長年にわたり、私は膨大な新規コードを寄与してきました。Python開発チームの殿堂メンバーにはなれたと思いたいです。

どういうことかと言うと、かつて私がプロジェクト参画で感じたような大きなスリルを今は感じないのです。誰かのためにバグを直すのは私にとっては新しい経験ではないので、以前のような達成感は得られません。Pythonの設計に関する議論に参加しても、言語の複数のパーツを作り出し、影響を与えるほど長く携わって得た爽快感は戻ってこないのです(現時点で私は16 PEPsの(共同)開発者です)。

言い換えれば、私はネガティブさに屈しやすいたちです。ネガティブな人がいれば、それだけでオープンソースに幻滅してしまいます。仕事としてオープンソース開発に時間を使えるようにとMicrosoftが給料を出してくれたのは良かったのですが、自分がもっと上を目指したいがため、貢献する代わりに支払いを受けているのだ、と自分に言い聞かせなければなりませんでした。そしてそれは、ただ自分がやりたくて仕事以外の時間に貢献していた時のレベルには及ばないのです。つまり、私は明らかに、「ネガティブさに打ち砕かれ、かつての向上心は勢いを失った」長期オープンソースコントリビュータのカテゴリに陥っています。

そこで私は、直面したネガィブさを何とかするために対処メカニズムの開発に乗り出しました。2015年度のPyConの開会のあいさつで、「私は当初、言語が参加の動機でしたが、今はこのコミュニティのために参加しています」と言いましたが、今でもこれは本心です。私が試そうと選んだ方法は、自分の関わっているプロジェクトは、こんなにたくさんの人を集結させ、楽しませているんだと実感するためだけにPythonカンファレンスに参加することでした。Pythonカンファレンスに参加してくれた人がオンラインで出会ったネガティブな人よりも圧倒的に多かったことも、私に力をくれました。

今は、オープンソースについて落ち込みそうになったり、自分の時間と感情的なエネルギーを見ず知らずの他人―つまり、私がプロジェクトとはいえネガティブな人を救い出すために仕事やゲームや妻と過ごす時間を断念していることを知りもしない人々―に費やし続けなければならないのかと疑問を抱き始めたりするたびにPythonカンファレンスに参加する必要はなくなりました。カンファレンスに参加する代わりに、Python(ニシキヘビ)をあしらったカナダ造幣局が発行している記念コインを買うことにしました。オンラインでネガティブな人に出会ったときは、コインを買いに行くことを思い出すようにし、世界中のPythonコミュニティの象徴として思うようにしました。どれだけ多くの人たちがPythonを心から楽しみ、どれほどPythonコミュニティが素晴らしいものかを考えるようにしたのです。

救済法

全ての人が、会場にいるだけで達成感を感じ、ポジティブさに応じてネガティブさを消費できるようなカンファレンスを持つプロジェクトで働けるわけではありません。正直なところ、事実を正しく見ることが役立つ一方で、頭を空っぽにし一歩下がって物事を考える必要があります。私もいつも自分がしっかりできているという自己認識があるわけではありません。

何が言いたいかというと、周りのポジティブさはとても役立つということです。オープンソースに疲れ果ててしまわないために人を助ける最大の防御策は、オープンソースのプロジェクト/開発者に対してネガティブな人々に立ち向かうことです。ネガティブな人に対抗することは、とても骨の折れることです。しかし他の人が一歩踏み込んで落ち着いて説明し、サポートしてくれたとしたら、それは大きな助けになるでしょう。基本的にコミュニティでは、ネガティブな人はいないことを知っておくべきでしょう。ネガティブな人はとても不合理な手段としてみなされます(つまり、ネガティブさに対し、ポジティブさを持って対応する必要があるのです。というのもネガティブに対してネガティブに振る舞うことは相当なネガティブさを伴います)。

それからオープンソースに関わる誰かに、シンプルに肯定の意を伝えることです。メールや、あるいはIRCを通して、はたまたプロジェクトの貢献者に直接会うなど、手段を問わず文字通り誰かに「ありがとう」と伝えることは、とても大きな意味を持つのです。これが取るに足らないことだとは承知していますが、長い時間をかけてオープンソースに貢献している人たちは、基本的にネガティブな人、あるいは誠意はあるけれども人から何かをしてもらおうとする人たちに相対してきたことを忘れてはいけません。人にずかずかと要求せず、「ありがとう」と言ってくれる人がいることは、バグ修正などの要求に応えたからのお礼ではなく、プロジェクト全般が感謝されていることが分かるはずです。この2つの感謝の違いは、愛する人のために何かをしてあげ、相手があなたに感謝の気持ちとしてハグをしてくれることと、同じ人がただ単にあなたが好きだからという理由で不意にハグをくれる、この2つのハグの違いと同じなのです。前者のハグもすてきですが、後者のハグはあなたをより特別な気持ちにしてくれます。

Bratt Cannon