ブラウザエンジン Servo のブログに、少し珍しい種類の記事が出た。新機能の発表でも大きな技術刷新の告知でもなく、寄付で支えられた1人分の業務が、1年で何を生んだのかを振り返る内容だ。こういう話は地味に見えるが、オープンソースの現場ではかなり重要だと思う。コードそのものよりも、誰がレビューし、誰が詰まりをほどき、誰が新しい協力者を増やすかで、プロジェクトの体力は大きく変わるからだ。
Servo のプロジェクトは昨年9月、長年の maintainer である Josh Bowman-Matthews、GitHub では @jdm として知られる人物が、月額寄付だけを原資にしてパートタイムで働くと発表した。担当は「Servo の contributor experience を改善すること」、つまり新しく入ってくる人や、すでに関わっている人が活動しやすくなるように整える役回りだった。今回の記事は、その最初の1年を本人の言葉で振り返ったものだ。
本人はまず、OpenCollective と GitHub で支援している人たちに強い感謝を述べている。寄付のおかげで、自分が大事に思っているプロジェクトにかなりの時間を割けたという。そのうえで、具体的な成果としていくつかの数字を挙げている。新しい maintainer を8人推薦し、pull request の review は1150件に達した。さらに、新しい contributor 向けの issue を114件起こし、そのうち92%はすでに解決されたという。borrow hazards、experimental features、AI policy、作業の見つけ方、stable と intermittent の test failure の直し方について、新しい documentation も書いた。
仕事はそれだけではない。ほかの人の pull request で予想外の失敗が起きたときに原因を探り、何度も出たり消えたりする flaky tests を直して、merge しやすくする役割も担ったという。印象に残った仕事としては、JavaScript engine integration の大規模な書き換えを支える中で、garbage collection に関係する intermittent panic の対処に関わったこと、test failure の調査のなかで window.open の壊れた挙動を見つけたこと、そして多くの flaky tests を安定化させたことが挙げられている。別の contributor が Servo で作業するための grant proposal を通す支援もした、と書いている。
締めくくりでは、この役割が自分にとって大きい意味を持つと述べている。家族との時間を確保しながら、Servo に意味のある貢献を続けられるちょうどいいバランスが見つかった、と本人は感じているようだ。そして、今後もプロジェクトをもっと参加しやすい場所にしていきたい、来年に何ができるか楽しみだ、と前向きに結んでいる。
この話でまず目を引くのは、成果の中心が新機能の派手な発表ではないことだ。1150件の review や 114件の issue、そして flaky tests の修正は、どれも地味に見える。だが、プロジェクトの現実に近いのはむしろこちらだと思う。大きな機能追加はたいてい、レビュー待ち、設計のすり合わせ、失敗テストの切り分け、初学者向けの説明不足といった「速度を落とすもの」に阻まれる。@jdm が埋めていたのは、その詰まりだ。
特に、114件の issue のうち92%が解決されたという数字は印象的だ。issue を積むだけなら簡単だが、解決率が高いということは、単なる棚卸しではなく、後続が実際に動ける形へ落とし込んでいたことを意味する。新しい contributor 向けの文書を書いた点も同じで、これは単なる説明書作りではない。参加の入口を増やす作業だ。オープンソースはコードが公開されているだけでは回らず、「何を触ればいいか」「どこで躓くか」を先回りして示せるかどうかで参加人数が変わる。Servo はそこにお金を払ったわけで、かなり現実的な使い方だと見える。
記事の中で、本人が複数回触れているのが intermittent failures と flaky tests だ。これはテストの結果が毎回安定せず、同じコードでも通ったり落ちたりする現象で、開発者をかなり消耗させる。しかも厄介なのは、実装のバグとテスト基盤の不調が混ざって見えることだ。レビューする側からすると、何が本当の問題なのか分からない。結果として pull request が止まり、修正の優先順位も崩れる。
だから、こうした作業に人手を割くのは非常に理にかなっていると思う。window.open の壊れた挙動を見つけた話も面白い。test failure の調査が、そのままブラウザの実装不具合の発見につながっているからだ。つまり、テストを直す仕事は、しばしば仕様理解や実装の品質改善と地続きになっている。見えないインフラの手入れが、結果として製品の信頼性を押し上げる。こういう部分は外からは評価されにくいが、Servo のような基盤技術ではかなり本質的だと感じる。
この1年で @jdm がやったことを見ていると、本人は単にコードを書いたというより、周囲が働きやすい状態を整えた印象が強い。新しい maintainer を8人推薦したのも、その延長線上にある。保守の仕事は、1人が頑張って抱え込むより、信頼できる人を増やしたほうが持続する。しかも Servo のような長期プロジェクトでは、最初から全員が同じ温度で深く関わる必要はない。入口を広くして、徐々に責任を渡せる状態が大事だと思う。
ここで面白いのは、寄付の使い道が「派手な開発者採用」ではなく、「既存のコミュニティの摩擦を減らす人件費」になっていることだ。オープンソースへの寄付は、しばしば「大きな機能が増える」ことを期待されるが、実際にはレビュー待ちの短縮、ドキュメント整備、失敗原因の切り分けのほうが効く場合が多い。Servo はその現実をかなり正直に示している。資金が増えると、必ずしも花火が上がるわけではない。ただ、止まりかけていた歯車が回り出す。今回の記事は、その事実を淡々と伝えているように読めた。
最後に、本人がこの役割を「家族との時間を保ちながら、意味のある貢献ができるバランス」と表現している点に触れたい。これは単なる私生活の話ではないと思う。オープンソースは、情熱だけで回すと長続きしない。燃え尽きたり、生活に無理が来たりすると、結局プロジェクト側の損失になる。だから、寄付で支えられたパートタイムの役割が、個人の生活とプロジェクトの継続性を同時に支えている構図はかなり重要だ。
しかも、このモデルは「フルタイム雇用ができる大企業」だけのものではない。月額寄付を集めて、維持管理や参加導線の整備にお金を回す。大きく見せるより、地味なボトルネックを減らす。そのほうが、Servo のような基盤プロジェクトには合っているのではないかと思う。新機能より先に、入ってきた人が迷わないこと。速度より先に、失敗がノイズにならないこと。今回の振り返りは、そうした優先順位をはっきり示した記事だった。
参考: Your Donations at Work: One Year of Sponsored Servo Development
