Book review
Working in Public――The Making and Maintenance of Open Source Software
GitHub以後のオープンソース開発を、少人数のメンテナー、コミュニティ、資金と雇用から捉え直した本。
全体のサマリー
GitHub以後のオープンソース開発を、少人数のメンテナー、プロジェクトとコミュニティの違い、プラットフォーム、資金と雇用の問題から捉え直す。
感想メモ
Working in Publicは、オープンソースの開発とメンテナンス、資金についてよく調べられた書籍です。
ここでのオープンソースは主に GitHub 以後に焦点を当てて書かれていた気はします。
オープンソースのアマチュア化
GitHub から始めた世代は、Open Source と Free Software のような違いのような部分に強い問題意識を持ってるわけではなく、ただ作りたいものがあって GitHub が便利だったから使ってるという話。 これを「オープンソースのアマチュア化」と呼んでるのが面白かったです。
特に JavaScript は、npm の小さなモジュールが多いため、この「オープンソースのアマチュア化」が進んでいるという話もありました。 JavaScript で有名な開発者は、Linux の Linus のように有名なプロダクトを紐づけて知られているのではないケースも多い。 たとえば、Sindre Sorhus や Kent C. Dodds のように特定のプロダクトというよりも、その人自体で有名になっているケースが多いという話。
オープンソース 「プロジェクト」
オープンソースコードじゃなくてオープンソースプロジェクトと呼ぶのは、コードだけではなく、コミュニティ、コード、コミュニケーションツール、開発者ツールの組み合わせ全体を指すという話。 これは確かにと思った。自分が OSS じゃなくてオープンソースと言うようにもなったもの少しにた感覚から来てます。多分扱う範囲が広がっているんだと思います。
オープンソース
タイトルを OSS からオープンソースに変更したのは、Software じゃないこともオープンソースでやることが増えているというのもあります。 — 今年のオープンソース活動振り返り @ 2020 | Web Scratch
オープンソースプロジェクトの分類
Node.jsを例にして、オープンソースの成熟への段階として次の3つがあるという話がありました。
- CREATION
- EVANGELISM
- GROWTH
Growthまでくるとアクティブユーザーが多くなり、プロジェクトはユーザー支援に時間がかかるようになるという話。
また、ユーザーの増え方とコントリビューターの増え方によって、オープンソースプロジェクトを次の4つのモデル分類できるという話もありました。
| High User Growth | Low User Growth | |
|---|---|---|
| High Contributor Growth | Federations(e.g. Rust) | Clubs(e.g. Astropy) |
| Low Contributor Growth | Stadiums(e.g. Babel) | Toys(e.g. ssh-cat) |
これがだいぶ面白い感じで、それぞれのモデルで次のような特徴がある。
- Federations: ユーザーも多く、コントリビューターも多い
- RustやNode.jsなどの言語に近いレイヤーに多いモデル
- n:nの構造になってる
- Stadiums: ユーザーは多いが、コントリビューターは少ない
- webpack、Babel、Bundler、RSpecなどユーザーは多いが、開発者は少ないモデル
- 1:nの構造になってる
- ユーザーからコントリビューターになるときのコストが高い(そもそものユーザーが多い)ため、コントリビューターが増えにくいという問題があります
- また、知識を外部化せずに長く続けるほど、新規参入が難しくなります
- Clubs: ユーザーとコントリビューターが重複してる
- ニッチな分野のツールに多く、ユーザーがコントリビューターであるケース
- ユーザーの増加率が高くないが、コントリビューターが多い(相対的に)
- Toys: おもちゃ的なもの
この4つのモデル間での行き来はできるので、ClubsだったものがStadiumsになったりもする。
コンセンサス
コンセンサスという言葉はオープンソースプロジェクトでよく見るようになったけど、これが機能するにはコントリビューターがある程度いないと機能していないという指摘が良かった。 具体的な例としてはLernaのICEライセンス問題で、スタジアムモデルだと「コンセンサス」はあってないようなものであるという話
コンセンサスを求める モデルは、連合であろうとクラブであろうと、より大きな貢献者コミュニティを持つプロジェクトで機能します。これらのコミュニティでは、メンバーシップの強い感覚を育むことが依然として可能であり、それは社会的規範、規則、および新規参入者が黙認することが期待される制裁につながります. しかし、スタジアムなどの集中型コミュニティには、分散型 コミュニティ のようにアクティブな「メンバー」がいません。積極的に関与する人が少ないことを考えると、スタジアムはコンセンサスを求めるものよりも「慈悲深い独裁者」の統治モデルに適しています。
これは確かに、少人数だとコンセンサスはコンセンサスでもないなーとは思った。
メンテナンスとコスト
オープンソース開発者の仕事は、作成の初期費用を超えています。開発者はものを作り、作ったものを共有せずにはいられないかもしれませんが、そうするたび に、そして成功を見つけるたび に、小さな目に見えない時計が 動き始め、彼らはケアと給餌を管理する任務を負っています。永久に。
ソフトウェアの配布はzero marginal costなので、いくら利用者が増えてもほとんど無料で配布できるという特徴がある。 そのため配布したら、そこからは初期費用よりずっと上がり続ける特徴を持っているという話。
この対応として、オープンソースプロジェクトはモジュール化される傾向がある。 RailsとMerbの統合やBabelのプラグインなどはこれにあたるとおもう。
静的コードは時間の経過とともに変化しませんが、アクティブな状態のコードは依存関係、つまり一緒に実行される他のコードと密接に絡み合っています。 …… 時間が経つにつれて、コードはその依存関係と同期しなくなり、それらの依存関係の新しいバージョンと互換性がなくなります。コードが変わらなくても、その周りのすべてが変わります。 5年間 触れられていないコードは、開発者がコンテナーやエミュレーターなどのツールを使用して正確な状況(開発者の環境とも呼ばれます)を再現しない限り、最新のマシンでは更新なしでは実行できません。 開発者は依存関係の古いバージョンを使い続けることを選択するかもしれませんが、それらの依存関係を更新すると、何かが壊れて、すべてを一緒に実行するために変更が必要になる可能性があります。
これ結構好きな話。ソフトウェアのコード自体は変化なくても依存関係があると勝手に壊れることがある。 そのため、依存関係があると脆くなるが、一方で依存がモジュール化されていると交換がしやすいという特性を持つようになる。
成長段階ではプロジェクトのメンテナーとしての名声はあるが、成熟してくるとそこが一定になっていく。 一方でユーザーは増え続けるため、コストは上がっていくという構造の問題についての話。
また、メンテナーが利用可能なattentionは有限なので、それをどうやって管理するかというパターンの話も良かった。
- 初期費用を減らす: CI/Bot/Lint/Check List
- 利用可能なattentionを制限する: Issueを閉じる
- コストの分配: モデレーション、ユーザーサポートを任せる
- 利用可能なattentionの総量を増やす: コントリビューターを増やす、収益を増やす
オープンソースにおけるお金の役割
この本を読もうと思った理由でもあり、この本が書かれた理由でもある。
cURLの話、Trivagoがwebpackのスポンサーしたら何故かそれを理由に求人への応募が増えた話など色々。
Homebrew の主任開発者で あるMike McQuaid が 「ステッカーマネー」 の問題と呼ぶものにつながります。つまり、開発者が熱心に消費するステッカーなど のマーケティングスワッグに支払うには十分なお金ですが、仕事を辞めて仕事を辞めるには十分なお金ではありません
この話が特に面白かった。
コードやライブラリといったオープンソースのプロジェクトに対してお金を払うというよりも、そのメンテナーに対して支払うという傾向があるという話。
先ほどもあったけど、プロジェクトのユーザーが多くなると、評判は一定になるけど、プロジェクトメンテナンスのコストは上がっていく。 なので、そのプロジェクトのメンテナーが新しい評判を作るのが難しくなって、止まってしまうという問題が指摘されていた。 このサブスクリプション的にその人を支援する形式だと、支援された人が新しいものを作るインセンティブ(より評判を集めるため)になるので、より創造的なものを継続的に作る仕組みになって良いのではないかという話。
これは、最初のアマチュア化とも関係しているなーと読んでて思った。 特定のプロジェクトではなく、特定の人のファンが増えているという現象とも繋がっている感じがした。
📝 NAISTのGitHub Sponsorsの利用を調査したレポートによると、GitHub Sponsors利用者のうち約80%の人は1か2人をスポンサーしている
プロジェクトベースじゃなくて人ベースであるのは、プロジェクトに縛られないという点で、メンテナーにとってはいい点も多いとは思う。 プロジェクトベースだとメンテナンスが強くなりがちだけど、人ベースなら新しいものを作ってみるとかもやりやすくなる。
自分もプロジェクトに縛られすぎないようなことは考えてGitHub Sponsorsやってるのでこの辺の話はだいぶ面白かった。
一方で、誰でもこの状態になるのは難しいよねって話もあった。 また、あまりにもオープンソースプロジェクトは多すぎて、だれを支援すればいいのかわからないという問題もある。
これが読もうと思ったきっかけのcore-jsの話とも似ていて、特にJavaScriptは依存関係が膨大で誰を支援するべきかわからなくなるような問題がある。 自分が依存してるライブラリのメンテナーのSponsorできる選択肢をhttps://github.com/sponsors/exploreで見れるが、膨大な数が出てくる。 なので、実際にスポンサーできる選択肢が多すぎると、どれをサポートすればいいのかわからなくなってしまうという問題は実際にあると思う。
この問題に対しては、「ハイコンテキスト、ローディスカウントレート」を取るのがいいのではという話だった。
一つ例として出していたのは、無料で公開してる本のアクセスを調べてみたら、特定のサイトからのアクセスが多かったので、そのサイトの読者に向けて本を売るという話だった。
core-jsやferossがかつてやっていたターミナルに広告を出すという手法は「ハイコンテキスト、ローディスカウントレート」ではなかったのが、うまくいかなかった理由なのかもと思った(ハイタッチな人を選んで出す仕組みになっていれば、フラストレーションはもっと低くしつつうまくできたのかもしれない)。
または、core-jsのような依存の依存のようなライブラリだと、そもそも使ってることを意識しないのでハイコンテキストとするのが難しいのかしれないと思った。
長々書いてしまって色々飛んだけど、詳細はStripe Press — Working in Publicを読みましょう。 大きく分けて、いわゆるプロジェクトのメンテナー的な深く専門的な方向(プロジェクトとして支援される) と もっとカジュアルで新しいものを創造する方向(人として支援される)の2つがあるよねって感じ。 これをダンベルというのが面白かった。(凹 みたいな形になるからだと思うけど。) (これと同じような話は、ジャーナリズムなどのニュース業界でも起きていたりするという話も面白かった。)
どちらの場合でも、普通の仕事と同じ金額を稼いでも同じではないという問題はある。 普通の仕事とは違って、保険がなかったり、税金的な部分が異なるので、同じ金額を得ても同じ負担にはならないという問題。
そのため、フルタイムのオープンソースメンテナーになるには、色々ハードルがある。 けど、最近Open Source Collectiveが、プロジェクトの資金を使ってメンテナーを雇用できる仕組みを実装したので、この辺の雇用的なハードルも変わってくるかもしれない。