続: OSSプロダクトとコミュニティの話

先日書いた通りYAPC::Asia Tokyo 2015でOSSの開発とメンテナンスについての私見を話したところ、会場で id:t-wada さんから強烈な質問と、その後にまとまった量のエントリがきた。

t-wada.hatenablog.jp

t-wadaさんの問題意識については上記エントリを読んでいただくとして、これに関連してYAPC::Asia期間中にいろいろな人と話したこと、およびその後に考えたことなどをまとめて書き下しておこうと思う。
明快な結論は無い。無いが、自分にとってのなんとなくの指針のようなものには多分なっており、こういうことを考えて自分はこれからコードを書くんだろうな、という気がする。

なお前提として自分がYAPC::Asia Tokyo 2015で話した内容がベースにあるので、できればそちらを把握しておいてほしい。t-wadaさんのエントリにあるメモは話した内容をよく反映しているし、質疑応答の内容などもあるので動画を見るとよいかもしれない。

コントリビューション vs コードの統一性

ごく当たり前のことだが、ソフトウェアというのは、一人で書いたコードが100%を占めていれば、最も統一性のあるコードになる。ただし人間は2〜3ヶ月も経てば別人に等しい何かに変貌してしまうこともままあるため、ここには「短期間のうちに一人で書いたコード」という制約が付く、こともある。

そのコードに何らかの設計あるいは統一されたスタイルというものが無ければそれはその人の責任だが、それはとりあえず問題外として置いておくことにする。

あるソフトウェアがある。どういった目的のために書かれたのかが明確であり、理解しやすい外部APIを持ち、良い効率で動作する。全体の設計は十分にシンプルで理解しやすく、一瞥すれば統一性があって読みやすいことがわかる。いまこの時に限って言えば、完璧なソフトウェアと言ってよい。*1

さて、このソフトウェアに外部から何らかのコードの貢献がある。それは全く知らない誰かからの機能の追加であったり、(その人にとって)意図しない動作の修正であったり、あるいは数ヶ月後の未来の自分からの仕様の変更であったりする。

このコードの貢献は、元の完璧であったソフトウェアを必ず乱す。当初ありえなかった変更がありえなかったはずの場所に入り、シンプルだった内部APIは拡張された仕様に対応するために醜く引数を足され、ひとつのことだけを正しく行っていた関数はなぜか2つ3つと機能を内包するようになる。
貢献者が未熟だから起きるわけではない。どんなに優秀なプログラマでも他人のコードの統一性に完璧に寄り添うことはできないし、例え変更を加えるのがオリジナルの開発者であっても、数ヶ月あるいは数年も経つと書くコードの癖は変わる。ソフトウェア開発者はリリース後に必要となる変更を全て予期することはできないし、であれば、予期できなかった変更は元の完璧なコードに不可避な変更を押し付ける。

OSSプロダクトの開発と利用の促進を進める上で、これは必ず起きることだ、と思う。

もちろんあらゆる貢献を拒絶すればこの変化の進行を最小限に抑えることはできるが、ユーザとユースケースが広がらずメンテナンスの行われないソフトウェアの先に待つものは、単なる停滞でしかない。

プロダクトにおける沈降 vs コミュニティにおける浮上

最初は十分に小さく美しく軽快だったソフトウェアが、多方面からの多数のコントリビューションにより大きく醜く鈍重なものになっていく。一方OSSコミュニティにおける開発者たちは常に、小さく美しく、気軽にコントリビューション可能で、そして参入しやすいソフトウェアを求めている。

これは不思議でもなんでもないし、矛盾してもいない。誰だって同じことができるならより労力の小さいほうがいいに決まっている。既存プロダクトのコミッタなら既存プロダクトに変更を加えるほうが簡単だろうし、そうでなければ、まだ十分多くの人には使われていないかもしれないがしかし十分に小さく美しいソフトウェアがあれば、そちらに貢献するほうがおそらく合理的だ。

コミュニティはこうして、全体的には小さく美しいコードを志向する。これは個々のプロダクトが必ず肥大化し醜くなるという事実とバランスして動的平衡のような状態を作りだす余地を持っており、おそらく、そのふたつが完全にバランスしていれば、それはコミュニティ全体としては健全なのだろうと思う。*2

だからここまでを総合すると、t-wadaさんの疑問に対する答えを書ける。

健全な OSS 社会ときれいなソフトウェア設計との間には、やはり緊張関係はある、ということになるのだろうか。

ない。適切なバランスが保たれていれば。

プロダクトの長い寿命 vs コミュニティにおける新陳代謝

コミュニティ全体の動向に関係なく、各々のプロダクトはその寿命を可能な限り長くしようとする。これはそのプロダクトに主要開発者として関わっているチームがある限りは自然なことだ。自分が今現在開発しているソフトウェアについて「これはもう使うな」と言える人は多くはないだろう。
また別の事情もある。ユーザは大抵の場合、開発者よりもはるかに長い寿命をソフトウェアプロダクトに期待する、ということだ。今問題なく使えているものを変更する理由は普通のユーザには無い。

既に動いていて長い歴史をもっているプロダクトは、大抵強固な開発者チームをもっている。新規参入はやはり難しい……ケースが多い。長い歴史をもつプロダクトには過去様々なことが起きており、新規参入者にとっては理解不可能な設計やコードも、過去の経緯を知っていれば納得できることもある。
もちろんコアの開発者チームがあまり大きくなるとコミュニケーションにも影響が出る。

こういった事情がやはり、新規の参入者にとっては障壁になる。こうして若く元気のある人達はこぞって小さく美しいプロダクトの開発に夢中になり、長い寿命をもったプロダクトのコア開発者の平均年齢は、毎年ひとつずつ増える。

小さくて美しい vs 活発なメンテナンス

djbという開発者によって書かれた一連のソフトウェアがある。知らない人はぐぐってほしい。……昔は知らない人などいなかったものだが、今ではもしかして、知らない人の方が多いかもしれない。つまり、そういうことだ。
djbwareは小さく美しく、ひとつの目的を果たし、バグも(ほとんど)なく、また小さいツールの集合により機能を実現する形になっていたから、変化に対しても強靭だった。そしてそれ故に外部からの貢献といったものを受け入れず、孤立していた。

これはおそらく、djb本人にとっては本望だったのだろうと思う。そしてユーザから見れば、各OS/ディストリビューションのやり方を無視し、わかりにくい設定と操作方法を押し付け、必要な機能を足してくれないソフトウェアに見えたかもしれない。

世界はdjbwareに支配されなかったし、ApacheやPostfixやBindや、あるいはsupervisordやUpstartやsystemdや、そういった多くのソフトウェアが世界を分割している。

ここでは絶対的な基準や善悪を語っているわけではないから、djbのやりかたでもよいではないか、という意見はあるだろう。もちろん、どういうやり方をとるかはその人の自由だと思う。

All-in-one vs Plugin chaos

ソフトウェアに多くの機能を足しユーザコミュニティと開発者コミュニティを広げつつ、ソフトウェアのコアを小さく美しく保つ方法がある。プラグイン機構の導入だ。
ソフトウェアの機能の多くをプラグインに移譲し、誰でもプラグインを書き公開できるようにしておく。多くのユースケースを組込みのプラグインでカバーしつつ、それ以外に必要なものは必要な人が開発し公開できるようにする。

これはうまくいく。最初の設計が十分にうまく行われていればコアに必要な変更は後々までそう多くはない。多くの人が使いたい機能はもう誰かが過去に必要としたもので、うまくすればプラグインが公開されているからそれを使えばいい。無ければ書いて公開すればいい。
ユーザコミュニティが開発者コミュニティの性質を帯び、多数の機能とユースケースが自己増殖的に補完され、それが更にユーザコミュニティの拡大を後押しする。そしてソフトウェアのコアは小さく綺麗に保たれたままだ。

ではこのやり方をとれば何もかも全てがうまくいくかというと、もちろん、そんなことはない。待つのは膨大な数に膨れあがったプラグインの混沌だ。
目的の実現のためにどのプラグインを使えばよいか分からず、どのプラグインがメンテナンスされているかもわからない。似たような機能のプラグインがいくつも併存し、あまつさえそれぞれ使いかたが異なる……。

これは要するに All-in-one の場合にソフトウェア開発者が負っていた責任を、あらゆるプラグイン開発者に分割しただけとも言える。そしてもしかして、全体的な品質で言えば、悪くなってすらいるかもしれない。中心の開発者たちなら維持できたであろうある一定の品質の保証は、こうした社会では期待できないからだ。

それでもこれは、悪いことではない。コミュニティに多くのアクティブな開発者を供給し、より小さい単位でプロダクトの沈降と新陳代謝を促す。より早くより小さい単位でかかるフィードバックと分散された責任は、ひとつのチームの巨大な責任とそのチームの失敗による巨大なカタストロフの脅威よりは、たぶん我々にとっては扱いやすい。

整備されたガイドライン vs 10年ROMってろ

あるソフトウェアの品質を担保しようとするとき、もちろんコントリビュートされてくるコードの質の高低は非常に重要だ。そしてその質をどうコントロールするかは難しい問題だと思う。

ソフトウェアの変更にはいくつかの種類のものがあるが、最も行いやすいのは、機能を足すことだ。特に似たような機能が既に存在し、それとはちょっとだけ異なる機能を足す、というケースだろう。Linux kernelに新しいデバイスドライバを足す、Dockerに新しいロギングドライバを足す。

しかしこういうケースであれ、コントリビュートされてくるコードの品質には大きな差がある。既に存在する似たような機能のものを参考にすればいいのに、びっくりするくらい独特なコードで書く人は割といる。リポジトリ内のコードを読めばなんとなく受け取れる思想のようなものを考慮だにしないかのようなパッチとか。

この問題に対抗する方法はいくつかあるが、ひとつは、よく整備されたガイドラインを作ることだ。コードスタイル、設計方針、実装方針および使用してよいAPIなどについて詳細なガイドラインを書き、それを強制する。違反するコントリビューションは受け付けない。これにより最低限のコードの品質は保たれる。
しかしこれは非常に大きな手間と長い時間を必要とする。時代の変化や設計の変更に追従するための労力もわずかとはとても言えないだろう。小さく美しいソフトウェアプロダクトには似つかわしくない。

いっぽうもうひとつの方法は、もっとよく周囲のコードを見てそれを真似しろ、というフィードバックを出すことだ。明文化を避け、しかし明らかに空気を読んでいないコードは明確に拒否する。「10年ROMってろ!」
かくして閉鎖的なコミュニティができあがる……。

独裁者 vs 委員会

何を受け入れるべきで何を受け入れるべきでないかの判断は非常に難しい。いくつかの超有名プロダクトには独裁者が君臨していて、受け入れるべきないものを明確に拒否する力を振るっている。LinuxにおけるLinus、PythonにおけるGuidoそしてRubyにおけるMatz。彼らのキャラクターは既に知られているから、言下に拒否するその姿勢は*3おおむね誰にでも受け入れられている。いいなあ。

そうでないコミュニティはApache Foundation傘下あたりに特に多く存在し、それぞれ委員会制とでも言うべき方向で集団での開発を進めている。よく使われているソフトウェアプロダクトにおいてはこれらはほぼ完全にいくつかの企業の勢力争いの場となっているように見える。
業界の巨人たる各企業がイチ押しの変更をゴリゴリ入れつつ境界面で押し引きする姿はそのソフトウェアのユーザとしては頼もしいものの、開発者として参考にできるものがあるかというと、無い。ざんねん。

開発者個人としての自分 vs プロダクトメンテナとしての自分

開発者個人としては、パッチひとつ送るにもあれこれと面倒な手続きを要求されるコミュニティはできるだけ敬遠したい。あれこれのものを使いつつ、できるだけ明快に使える小さく美しいソフトウェアと関わり生きていきたい。それができるだけのフットワークの軽さと、技術的視点でプロダクトの選択ができるだけのものを維持したい。

プロダクトメンテナとしては、ユーザがいる以上はきちんとメンテナンスをしたいし、また使用範囲が拡大すれば嬉しい。機能拡張の提案は真剣に受け取り、ソフトウェアの肥大化を招くかもしれないとしても受け入れることもあるだろう。そのプロダクトに技術的優位性があると思っている限りはどっしりと座りこんで開発を続けたい。

自分がメンテナをしているプロジェクトに自分でパッチを送れなくなる日が来ないようにする、という努力を続けたい、というはかない決意をするのが精一杯だなあ。

まとめ

結局どうするんだよ! というと、あらゆる2項対立のどの極端な点にもどうせ正解はないので、あれこれバランスの取りかたを試しながら、よさそうなやりかたを模索するしかないのだろう。
それでも一番大切なことがあるとすれば、こういったことを絶えず検討しなおすべきだということ、他の開発者とコミュニケーションをとることを絶対に拒絶すべきでないということ、くらいかもしれない。

*1:自分の理解では、t-wadaさんはこういったことを(理想的に)実現する、ということを抽象して「良いソフトウェア設計」と言ったのだと思っている。

*2:ソフトウェアの沈降速度が速くプロダクトの新陳代謝が追い付かなければ全体としてはあまり良くない状態のコードに携わる人数が増え、開発者にとってはストレスフルな状態になる。プロダクトの新陳代謝があまりに早過ぎるサイクルで起きると各々のプロダクトの熟成あるいはユースケースの充実が全く行われず、ユーザにとってはリスキーすぎるコミュニティになるだろう。

*3:時折ネット上のニュースを騒がせることもあるけれど