オープンソースは誰のため？

オープンソースは、少なくともある程度までは、あなたの問題だ。ここでいう「あなた」とはユーザーのことだ。

オープンソースは「あなたには関係ない」わけではない

言い換えれば、Rich Hickey が『Open Source is Not About You』を書いた時点で、彼は間違っていた。そして私は、彼が間違っていないふりをするのにうんざりしている。

もちろん、彼が完全に間違っていたわけではない。そうでなければ、あの有名な記事がこれほど共感を呼ぶこともなかっただろう。ボランティアのメンテナーに対して、自分個人のユースケースを無償で即座に満たせと要求する横暴なユーザーは、まさに彼らがそうである通りの、袋叩きにされるべき連中だ。自分のインフラを支えているコミュニティから無償サポートを巻き上げてコストを抑えようとする企業ユーザーも同じだ。そうしたコストの外部化で利益を得ている連中も同様だ。

だが「オープンソース」（あるいは「フリーソフトウェア」）の交換は、「ソフトは用意したから使え、文句を言う資格はない」というほど単純なものではない。メンテナーはこの交換のコストと便益を、そしてそこに含まれる倫理的な意味を、正確に理解すべきだ。

現状では、この交換が存在することすらほとんど語られていない。ましてや、それがメンテナーとユーザーの間に長期的で微妙な、暗黙の関係を築いていることなど、なおさらだ。

はっきりさせよう。

メタ倫理についてのちょっとした脱線

「義務」と「権利」、「べき」と「ねばならない」について語るとき、私たちは倫理体系を組み立てている。そうした体系の目的は、社会的な期待と社会的な帰結を形作ることにある。私の気まぐれな助言に従わなかったからお前は超越論的に悪だと言われても、何の役にも立たない。だがそれは、あなたの行為には帰結が伴うべきだと私が示唆しているということだ。同時に、その帰結はおそらくすでに存在していて、ただ文章化されていないだけだとも示唆している。だから、こうした記事で私が、私たちは自分の社会的義務をこう見るべきだと述べるのは、より広い社会的議論の出発点にすぎない。何らかの帰結があるべきだと考えているから、その可能性を指し示している。その帰結とは何か？今のところ、私にもわからない。一緒に考えよう。

オープンソースをやるとき、私たちは何をしているのか？

Hickey と、あの影響力のある記事以降に続いた数多の追随者たちは、「オープンソース」のプロセスをこう断言する。

メンテナーが何かを作り、贈り物としてユーザーに提供する。メンテナーは「チームと一緒に働くのが好き」かもしれない。
メンテナーは「自分たちの仕事を誇りに思う」かもしれない。

ユーザーはその贈り物を受け取り、そこから効用を得る。

（ユーザーは感謝しなければならない。）

ごく少数のユーザーが、今度はプロジェクトに貢献する。

（メンテナーは感謝するかもしれない。）

彼は自分の会社の具体的な事業について何度か曖昧に触れている。その会社は彼のプロジェクトと何らかの緩い関係のあることをやっていて、それで稼いでいる1。だがその事業は一貫して「顧客」向けのものとして語られる——そして「顧客」とは、前述のユーザーの中のごく一部（「1% 未満」）にすぎず、ほとんど別の集団と言っていいほど小さい。

権利のないものを求める厄介なユーザーについての記事の中でこのプロセスをさらっと流されると、大体筋は通っているように聞こえるので、うんうんと頷いてしまうかもしれない。贈り物は良いことだ。私も優れたチームと働くのは好きだし、自分の仕事を誇りにも思う。

だがよく見ると、論理的に綻び始める。コンサルティングの顧客がいて、収入はすべてそこから来ているのなら、なぜ（彼が繰り返し強調するように）「コミュニティのために[何かをする]」必要があるのか？　そもそもこのコードを公開したのは何のためか？　チームと働くのが好きで自分の仕事を誇りに思うことは、いろいろな場面でできる。それだけが目的なら、なぜこの自意識過剰で厄介な大勢を巻き込むのか？　あなたは何を得ているのか？

「メンテナーはなぜこれをやるのか」という根本的な問いを落としているなら、この話は他の重要な部分も落としているのかもしれない。

あなたはなぜこれをやるのか？

オープンソースソフトウェアを公開し維持する動機はたくさんある。どれも微妙で、しばしば重なり合い、めったに明言されない。メンテナーは一枚岩ではないし、誰もが似た理由でやっているわけでもない。とはいえ、誰かが貢献したいと思う理由になりうるものを、いくつか整理してみよう。

評判

ソフトウェアをオープンソースとして公開する動機の一つは、宣伝かもしれない。最も一般的な形は自己宣伝だ。あるオープンソースプロジェクトで目立つ重要な貢献者であれば、そのプロジェクトが属する領域で仕事を見つけるのは自然と楽になる。

コンサルティング会社を経営しているなら——Rich Hickey が例の有名な愚痴記事を書いた当時まさにそうだった——この評判という通貨は、自分のサービスの宣伝に変わる。チームの能力を示す実例になる。

この便益の交換は、オープンソースの比喩としてよく持ち出される伝統的な「贈与経済」に最も近い。あなたはコードをユーザーに渡し、コード自体に価値がある。ユーザーは評判を返す。形は彼らの注目、敬意、そして顧客や雇用主になれば金銭さえも含む。

影響力

インフラはオープンソースで最も人気のある類型だが、それには十分な理由がある。プログラマーはある問題を解こうとするとき、しばしば硬直したアーキテクチャの選択に縛られ、もっと自分が望むやり方で解けない。大規模なインフラ投資は、便益を論証しにくいため、計画プロセスで正当化するのが難しい。時に便益はきわめて個人的なものだ。同じく有効な複数の選択肢に対して、エンジニアごとに美的な好みが異なる。

自分が好む種類の選択肢を開発してオープンソースとして公開すれば、他の人々がどうこの種の問題を解くかに影響を与えられる。個人にとって、こうした影響力のある立場は、雇用主を変わっても持ち運べる専門性をもたらす。自分が開発したツールの使い方は知っているから、速く効果的に使えるし、時間をかけて自分が満足し続ける形に育てていける。

雇用主であれば、他の全員に自分のオープンソースプロジェクト2を使ってもらえれば、採用コストと研修コストを同時に下げられる。求職者はコードを読み、それがよく書かれていると分かり、こうした良いコードを生み出す会社で働きたいと思う。入社前にコードを読んで慣れておくこともできる。つまり、あなたの内部システムがどう動くかをすでに理解している開発者が、いつでも手元にいるということだ。

この利益交換は、贈与経済というより「ソフトパワー」に近い。コードをユーザーに渡すことには価値があるが、ユーザーが返してくるのは、その技術的アジェンダを左右する力だ。最初の方向性を決められるし、その後のメンテナンスでも継続的に彼らの行動を左右できる。

スキル向上

エンジニアとして、自分のスキルを上げたいと思うかもしれない。プロプライエタリで商用のものを書くことは、二つの面でそれを妨げる。

第一に、商業的な関心を引き、実際に競争力を持てるように、自分のスキルの範囲内にあるものを作ろうとする。大きなチームでも同じような理由で、すぐに戦力になれることを望む。それでも、新しいことを学ぶ道は必要だ。

第二に、秘匿された形で作ろうとする。そうすれば生み出した価値はコミュニティに解放されず、自分のものになる。その代わり、外部の専門家からのフィードバックとは切り離される。

組織としても、同じように従業員のスキルを育てたいと思うかもしれない。

この利益交換は、コードと知識の交換だ。コードや変更を公開し、その見返りとして、ユーザーには良いバグ報告を求め、少なくともその一部には共同開発者になってもらうことを期待する。

アウトソーシング

エンジニアとして、一人でできることは限られている。インフラに一定の影響力を持ちたいから自分で書きたい、と思ったとしよう。同時に、自分のインフラを置く公共の場所も欲しい。自分のニーズを満たすために変更を加えられるが、自分が離れても誰かがその変更を メンテナンス し、基盤プラットフォームやハードウェアなどの何年、何十年という変化の中でも使える状態に保ってくれると分かっているからだ。

この公共メンテナンスの仕事は、関心を持つ参加者全員で分担できる。千社が同じツールを必要としているなら、そのうち数十社が共有するだけでも、自分たちの負担は大幅に減る。他の会社の負担は言うまでもない。

この利益交換がより複雑なのは、主要メンテナと、同じくコードを貢献する周辺コミュニティのメンバーの間に対称性がないからだ。主要メンテナが交換しているのは実のところ 名前空間 であり、コード そのものではない。人々が貢献し、調整し、変更をリリースする中心の場だ。彼らはある意味でマーケットメイカーであり、他のすべての貢献者はこの市場のような構造の中でコードをコードと交換している。

実際には、この動機がゲーム理論の問題を生む。メンテナンスがある臨界閾値を下回ると、十分に大きな危機が起き、少なくとも一部のフリーライダーなステークホルダーが貢献を始めざるを得なくなる。

しかし結局のところ、これは すべて の関係者のメンテナンスコストを大きく下げるし、最初からフリーライドせず、より積極的なボランティアには、上述のあらゆる利点が追加で得られる。

勘定科目表についての短い余談

ほとんどの会社は、オープンソースのメンテナンスを進行中プロジェクトの単純な間接費として計上している。CapEx のこともあれば OpEx のこともあるが、本質的には「たまたまこれをメンテナンスしている人がいれば、それが属する適当な製品の勘定に入れる」というだけだ。この計上方法は歪んだインセンティブを生む。上述の利点をどれも認めていないからだ。こうした財務体制の下では、継続的な健全メンテナンスは ZIRP になる。リソースが絞られれば、この表面的な贅沢は真っ先に削られる。

オープンソースが生む副次的な利益は、正しく認識されるべきだ。給与や IT といった科目に埋もれさせるべきではない。より良いエンジニアの採用に役立っているなら、支出の一部は採用コストとして計上すべきだ。顧客層における評判を実際に高めているなら、一部はのれんとして計上すべきだ。顧客である開発者の目に製品を触れさせているなら、マーケティングとして計上すべきだ。何より、あるオープンソースプロジェクトのメンテナンスが実際に全社的なプラットフォームを支えているなら、たまたま最初に採用した小さなチームに押し付けるべきではない。3

これらのコストをどう配分し、部門間でどう交叉請求するかは、あなたの組織と具体的な勘定科目表に大きく依存する。だが「どうでもいい、ソフトウェア製品の一部だし」とか「たぶん DevRel だろう、SDK も入ってるし」といった態度では、次のキャッシュクランチのときに、オープンソース組織が根こそぎにされ、副次的な利益もろとも消えることは請け合いだ。

利点であるべきでないもの

これらのカテゴリは、理性的なトレードオフとして 明示的に設計することもできる。実際には往々にして暗黙的で微妙なものだが。これらは取引だ。メンテナは何かを得て、ユーザーも何かを得る。

だがメンテナとして得るもののすべてを、自分のために 利用していいわけではない。ある責任を負う信頼を託されることは、取引ではない。

「ああ、全部 root shell か」

オープンソースのコードは コードだ。このサンドボックス機構がひどくお粗末な時代には、他人が書いたコードをインストールすることは、その人にシステムの制御を渡すことに等しい。多少間接的ではあるが。

不文律がある。私がオープンソースライブラリを作り、あなたがそれを使うなら、そこにバックドアが隠されていて、私があなたの銀行口座の認証情報を手に入れる、ということはないはずだ。ユーザーとメンテナの間には信頼関係があり、ここでメンテナの最初の義務が生じる。メンテナには、ユーザーのコンピュータを自分の利益のために利用しない 義務がある。

このルールは明白で単純に見える。「不文」と呼ぶのは不公平だと思うかもしれない。実際、いくつかの場所で明文化されている。たとえば npm の acceptable content policy にはこう書かれている。

受け入れられないコンテンツの例： …

コンピュータウイルス、コンピュータワーム、 rootkit、バックドア、スパイウェアなど、悪意のあるコンピュータコードを含むコンテンツ。これには研究目的で提出されたものも含まれる。セキュリティ研究を支援するために明確に設計され文書化されたツールは受け入れられるが、npm registry を https://policies.python.org/pypi.org/Acceptable-Use-Policy/exploit やマルウェアの配布・展開チャネルとして使うものは受け入れられない。

皆さんも同意するだろう——銀行の認証情報を盗み出し、それを僕に送って最高にクールなジェットスキーを買わせるスクリプトは、間違いなく「マルウェア」であって、当然禁止されている。

だが、ここには広大なグレーゾーンも存在する。npm は「支払い方法、寄付、その他の形でのパッケージ開発支援に関する情報」を明確に許可している。そのすぐ後で、「実行時、インストール時、その他ソフトウェア開発ライフサイクルの段階で広告を表示するパッケージ、たとえば npm scripts を通じて表示するもの」を明確に禁止してもいる。4 このグレーゾーンの線はどこで引かれるのか。「npm は、何が許容されるかを判断する際に、引き続き独自の判断を用いる。」

とはいえ……これを禁じているのは npm であって、「オープンソース」そのものではない。自分のウェブサイトで、ユーザーに広告を表示するコードを「贈り物」として配ることは完全にできる。このポリシーの具体的な構造は珍しいものではないが、同種のサイトと完全に一致しているわけでもない。たとえば PyPIは「暗号通貨マイニング」を明確に禁止しているが、npm は禁止していない。暗号通貨マイニングは「オープンソースでない」のか？ここには主観的な判断が大量に絡んでおり、ユーザーに贈る「贈り物」に何を含めてよいかを判断しているのだ。

だが、話が逸れた。

言いたいのは、この概念をめぐるポリシー策定は明確ではなく、周辺部に多くの小さな不一致があるということだ。ただし、一つだけ非常に強い合意がある。ユーザーはここで信頼を差し出しており、それは取引ではない。取引とは「君がユーザーにコードを渡し、ユーザーが君に無限の計算資源と全金融口座へのアクセスを渡す」ことではない。ユーザーは君の評判を頼りに、自分自身を君のコードに晒しているのだ。

そこから一つの義務が生じる。故意であれ過失であれ、このコードを使って悪いことをしてはならない。

セキュリティアップデートは滑稽な帽子をかぶったコマンド・アンド・コントロールにすぎない

ここまではコードの初回ダウンロードの話だけをしてきた。Rich Hickey もそう描写している——まるで君がどこかのウェブページからコードを拾ってきて、デスクトップの好きなフォルダに置くだけのように。だが今日のオープンソースの関係はそういうふうには動いていない——かつてそうだったとしても。

今日の動き方はこうだ。君が自分の pyproject.toml、package.json、Cargo.toml に依存を追加すると、ユーザーは君がたまたまアップロードしたものに晒されるだけでなく、たまたま君のパッケージインデックスの認証情報を持っている人にも晒される。

そこから一つの義務が生じる。ユーザーを悪意ある更新から守るような運用セキュリティ態勢を維持することだ。

ロードマップは他人の人生

ユーザーが君に託すもう一つの信頼は、彼らが君のソフトウェアをどう使うかについて、君が少しでも気にかけてくれるという信頼だ。

理想的には、ユーザーの期待は明確に線引きできる。君が引き受ける継続的なメンテナンス作業は、あらかじめ用意された明確なポリシーに書き込まれる——どんなセキュリティ対応方針を取るのか、メンテナンスの余力がなくなったときにどう外部に伝えるのか、といったことだ。

だが、プロジェクトに関わったことがあり、その成熟度が極端な水準でない人なら誰でも知っているように、エコシステムの 99% は成文規定ではなく緩やかな慣例に依存している。メンテナーはおおむねまだいるだろう、issue tracker でユーザーのバグをトリアージし、GHSA と CVE でセキュリティ報告を処理するだろう、プロジェクトを離れる前には「archived」とマークし、おそらく最後のリリースを一つ出すだろう、ChangeLog を維持し、少なくとも何が起きたかを簡単に説明するだろう——そう想定している。

明確なポリシーに空白があるとき、あるいはポリシーがそもそも存在しないとき、ユーザーはこれらの慣例が依然として守られていると仮定する。この仮定は合理的だ。そうでなければ、誰もオープンソースソフトウェアを使うことなどできない——誰も書く時間のないサービス契約にまず署名しない限りは。

これらの慣例の中で最も強いものはこれだ。まだ活発にメンテナンスされているプログラムは、少なくともおおむね これまでやってきたことを続ける。ユーザーはあるオープンソースソフトウェアを使うと決めた瞬間、その使用という事実そのものによって、そのソフトウェアが変更され壊れるリスクに自分を晒す。使って投入している間、彼らは以下に投入して いない。

自分のニーズを満たす代替ソフトウェアを作ること。
他のソフトウェアが読める形式でデータを 維持する こと。
既存の代替ソフトウェアの 使い方を学ぶ こと。

これらの期待と現実が食い違うと、物事は悪くなりうるし、実際に悪くなる。

物事がどう悪くなるか

あるメンテナーがオープンソースのペイントプログラム、OpenPaint を作ったとしよう。

独特の混合コラージュスタイルで知られるアーティストが、それまで使っていた ProprietaryPaint からこの新しい OpenPaint に乗り換え、文化的に意味のある作品を制作している。ところがメンテナーは「混合」ツールのメンテナンスが面倒だと感じ、OpenPaint 2 でそれを削除した。

数か月後、画師が使っている OS ベンダーがセキュリティ更新をリリースし、OpenPaint が壊れた——旧版の OpenPaint が、あるプラットフォーム API を無自覚に濫用し続けていたからだ。

メンテナーはこの非互換を解決するため新しい OpenPaint 2.0.1 をリリースしたが、1.x にはもう関心がなく、そのバージョンを更新する気も起きなかった。

これで画師は板挟みになった。旧版の OS に留まって全個人データを危険に晒すか、新システムにアップグレードして実質的に生計を断たれるか、画風を根本から変えざるを得なくなるか。

プロプライエタリソフトウェアも同じようにユーザーを同様の絶境に追い込む（実際、これをやるのはプロプライエタリソフトウェアのほうが多い）。だが、オープンソースはこの配慮に関するあらゆる義務を帳消しにするのか？ OpenPaint チームは少なくともそうする理由を説明し、画師に異議を唱える道を残すべきだったのではないか？5

「オープンソース」が唯一実現したのは、画師が法外な金額を払って新しいメンテナンスチームを雇い、fork を作らせることができるようにしたことだけだ。そんなことは個人にはまず耐えられない。

これはひとつの義務を生む：あなたのユーザーが、あなたにどれだけ依存している可能性があるかを、少なくとも考慮すること。

これがすべての義務の中で最も厄介だ。明らかに、ユーザー一人ひとりがメンテナに無期限に働けと要求する権利がある、という話ではない。だが、ユーザーがメンテナの公開時の暗黙の約束を信じたからといって、何も得られないべきでもない。

これは微妙で終わりのない交渉であり、どう決着すべきかについて明確な道徳的直感を我々が持っているとは思わない。だが、これを整理する方法を見つける必要はある。

これは、はっきりさせるべき問いも引き出す。

そもそもなぜ、誰のためにやっているのか？

人はたいてい、ひとつの理由だけで何かをするわけではない。我々が置かれた経済環境は金を稼ぐことを要求するが、その金は役に立つこと、誰かを喜ばせることで稼ぎたいと、ほとんどの人は思っている。

だからそう、我々がオープンソースをやるのは私心からだ：評判を上げ、技能を磨き、影響力を広げ、メンテナンスの負担を分かち合う。そうする以上、我々はある程度の義務を負う——たとえその輪郭がはっきりしなくても、他者の信頼を裏切らないという義務を。

だが、これらのユーザーに奉仕する気がまったくないままこれをやるなら、そうした動機はすぐに空虚に見え始める。ユーザーが何か要望を出すたびに「俺はお前に何も借りがない、お前の意見に価値はない」と返していたら、評判は上がらない。コミュニティの考えを無視するなら、コミュニティへの影響力もへったくれもない。

メンテナとユーザーの間のやり取りの多くは、そもそもこんなに殺伐とする必要がない。もちろん一部はユーザー側の問題で、彼らは期待値を妥当な線に調整すべきだ。

とはいえ：こうしたやり取りが悪化する前に、メンテナ側にもっとうまくやれたはずのことがある——まず耳を傾けることだ。「オープンソースのユーザー」がとりわけ有毒な集団であるはずだという理由はない。今日において、その集団とはほぼ……パソコンを持っている人全員だ。

あの古い言い回しのとおりだ。もし一人の人間にひどい態度を取られたなら、それはその人の問題だ。だが、どこへ行っても出会う全員が敵意を向けてきて、お前が何か間違っていると言ってくるなら、そろそろ自分自身を見直す時かもしれない。

もしオープンソースのユーザーが全員、当然の権利だと信じている嫌な奴らだというなら、そろそろ構造的な問題を探す時かもしれない。

驚き、またしても AI

ため息。6

ユーザーはスロップが嫌いだ。

わかっているとも、親愛なる AI 肯定派の読者よ、君の AI 出力は他人のとは違う、君は考えなしのゴミをコードに放り込んだりしていない——他の連中はみんなそうしているし、それがこれらのツールを使う必然の終着点なのだけれど。君は Claude で「サボって vibe coding」しているのではない、君がやっているのは「責任ある agentic engineering」だ、これは別物だ、君は生まれつき違うから。

それでも、ひとこと言わせてほしい。君のユーザーはそんなことを知らない。彼らが知っているのは、好きな製品にスロップが持ち込まれると何が起きるかだ。彼らはデータが漏洩することを知っている。開発者は個人的に危険にさらされることを知っている。彼らは障害が増えると予想してよく、君のコードが避けがたく質を落とすことも知っている。

つまり、君のユーザーはこれが最後の義務を破ることだと受け取る：ソフトウェアは使える状態を保つべきだ、と。

ユーザーは君にやめろと要求するだろうし、おそらくかなり無礼にやる。おそらく君も、あるいはチームのかなりの部分も、やめたいと思っているかもしれない；君が彼らに同意していないかもしれない。いずれにせよ、この対話を続けていく方法が必要だ——しかも、隣接するあらゆる議論スペースに即座に飛び火しないような方法が。ユーザーはどこかの空間で自分が歓迎されていると感じる必要がある、そうして初めて彼らはその空間で議論するのであって、千ものグループチャットや SNS の投稿に爆発するのではない。

この記事のきっかけは、またある有名なオープンソースコミュニティで論争が勃発したことだ：大勢の怒ったユーザーがなだれ込み、開発者に向かって怒鳴り、LLM 生成コードの受け入れをやめろと要求した。リンクは一切貼らない、この火にこれ以上燃料は要らないから。だが、こうした出来事は一度きりではないし、パターンもますます見慣れてきた。

SNS で——たいていは BlueSky か Mastodon、時にはどこかのユーザーグループのフォーラムで——ユーザーは AI がらみのポリシーを耳にする。彼らは群れをなして開発者のフォーラムやメーリングリストになだれ込み、プロジェクトに AI への断固たる姿勢を取れと大声で要求する7。この圧力は同時多発的だが、まったく調整されておらず、内容はひどく重複し、出所は極めて多様で、しばしば互いに矛盾し、かなり消耗させる——特に、すでに疲れ果て、他にもやることがあり、自分自身は AI がそもそも好きではないかもしれないメンテナにとっては。

信じてくれ、わかる。これを扱うのはとてもつらいことがある。

だが、AI が引き起こすほとんどの問題と同じく、これは実は「AI」の問題ではなく、ずっと前から燃えていたゴミに「AI」がガソリンをかけたようなものだ。ここでネットモブとは、声を上げる場所を持たない者たちの言語だ8。

ユーザーがすでに怒っているなら、たいてい手遅れだ（だが、次に備えることはできるかもしれない）

ある日突然、不適切なチャネルを使って大勢のユーザーからフィードバックが押し寄せる。だが、彼らに適切なチャネルは本当にあったのだろうか？

プロジェクトに、人々が集まって議論する場所はあるか？君が把握できる、秩序ある苦情の窓口は？それとも GitHub Issues のページ——非技術系のユーザーには使い方がまったくわからない——と、ユーザーがルールに不慣れな開発者フォーラムしかなく、怒ったユーザーの群れがなだれ込めば、荒らしで場違いだと見なされるだけか？

自分のガラスの家から石を投げるつもりはない。ここ数年、そういう場所を作るのはどんどん難しくなっている。自分にも実はない。

だが、持てるだろうか？ IRC はゆっくり死につつあり、メーリングリストは不人気で、モデレーションはますます面倒になり、フォーラムソフトは運用コストが高く継続的なメンテナンスが要り、Discord は混乱を極めたカオスだ——その結果、どのコミュニティにもコミュニティ管理とフォーラムモデレーターが必要になる。つまり、自分のような小規模な個人プロジェクトでは、そんなインフラはまず不可能だ、なぜなら専任でもう一人維持する人間が要るから；誰かが手を挙げるまで、これは非現実的だ。自分のより大きなプロジェクトでさえ、人手の薄さには驚くはずだ、専任のメンテナを一人割いてこれを任せる余裕など絶対にない、まして我々自身が slopocalypse の攻撃にさらされているのだから。

オープンソースコミュニティというのはそういうものだ。ほとんどは、こんな仕組みが要らないほど小さく始まり、少しずつ大きくなって、ある日突然、大きすぎるほどになる——昨日にでもこういう場所があるべきだったのに、というくらいに。そして関心が少し冷めると、またたく間に小さくなりすぎる。必要だと感じるようになっても、コミュニティのインフラを立ち上げて維持するのは難しいままだ。

それでも、ユーザーに——メンテナーではなく——専用の場所を与え、互いに交流し、本物のコミュニティを作り、開発者にフィードバックを届けられるようにすることは、成功するコミュニティに欠かせない要素になりつつある。あれば嬉しい追加ではなく。

おわりに

疲れることも確かにあるが、メンテナーである私たちはみな、オープンソースから何かしらを得ている。そしてユーザーに正直であること——自分自身にも正直であること——つまり、自分がそこから何を得たいのかをはっきりさせるのは、良いことだ。このジュースが搾る価値があるかどうかを知るには、ジュースが何なのかをはっきりさせ、同時に搾るコストが何なのかもはっきりさせなければならない。

比喩としての「搾る」の一部は、まさに一連の義務だ。そして義務こそ、最も曖昧に定義されているものだ。この点もできるだけはっきりさせておきたい——自分が何に同意したと思っているのか、そしてユーザーにどんな形で自分をそれに対して責任ある扱いをしてほしいのか、その両方を。行動規範はここでは出発点になるが、最低限の出発点にすぎない。「同僚やユーザーをハラスメントしない」は目指すべき優れた基準ではない。ただの基本的な礼儀だ。

あなたの義務が何なのかを正確に言うことはできない。これまで暗黙のうちに共有してきた、あの曖昧な道徳的直感の輪郭を、おおよそ描くことしかできない。

この線を引くことは、ユーザーのためだけでもない。メンテナーはすでにプレッシャーを感じ、義務を感じている。私たちは義務に押しつけられる感覚が嫌いだ。この嫌悪にはいろいろな理由があるが、大きな理由の一つは、自分自身にとっても義務がどこまでなのかがはっきりしないことだ。「何も約束してない、お前らに何も借りはない！」と悪態をついて吐き出せば、確かにすっきりする。だが本当の問題は何も解決していない。線がそこにあると本気で信じているわけではないのは明らかだ——そう信じているなら、とっくにそこで止まっているはずだから。そもそもそんなことを言う必要を感じないはずだ。

この線が一体どこにあるのかを突き止めるのは、途方もなく大きな共同作業になる。それを始めるのに最適な時期は50年前だった。

だが二番目に良い時期は、今日だ。

謝辞

このブログでの執筆を支援してくださっているスポンサーの皆さんに感謝します。ここで読んだものが気に入り、もっと読みたい、あるいは私のさまざまなオープンソース活動を支援したいと思ったら、私の仕事を支援するためにスポンサーになることができます。