Working in Public を読んだ
Working in Public
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 が 「ステッカーマネー」 の問題と呼ぶものにつながります。つまり、開発者が熱心に消費するステッカーなど のマーケティングスワッグに支払うには十分なお金ですが、仕事を辞めて仕事を辞めるには十分なお金ではありません
この話が特に面白かった。
個々の開発者は、企業とは異なり、オープンソースコード に直接お金を払うのではなく、コード の背後にいる人々に資金を提供する可能性が高いようです。これは、プロジェクトの依存関係ではなく、メンテナーの評判によるものです。長期的には、1人のメンテナが プロジェクトから降りない場合 ( これは今日よくあることです )、継続的なメンテナンスを価値あるものにするために別の報酬が 必要です。コンテンツクリエーターの典型的な報酬は評判の向上であり、それを注目 (つまり視聴者)に変えることができます。クリエイターが 何かを作り続けたいので あれば、その関心をお金に変える方法を見つけます。スポンサーは、今日のオンラインクリエイター向けの新たな資金調達システムですが、「寄付」 の概念と混同されることがよくあります。スポンサーは利他主義によって動機付けられるのではなく、現在の評判に基づいて、クリエイターの将来の仕事をフォローすることに関心が あることによって動機付けられます。寄付というより、サブスクリプションのようなものです。個人が オープンソース開発者のスポンサーになる場合、理想的にはコードにお金を払うのではなく、コードを書いている人をより身近に感じることができます。
コードやライブラリといったオープンソースのプロジェクトに対してお金を払うというよりも、そのメンテナーに対して支払うという傾向があるという話。
先ほどもあったけど、プロジェクトのユーザーが多くなると、評判は一定になるけど、プロジェクトメンテナンスのコストは上がっていく。
なので、そのプロジェクトのメンテナーが新しい評判を作るのが難しくなって、止まってしまうという問題が指摘されていた。
このサブスクリプション的にその人を支援する形式だと、支援された人が新しいものを作るインセンティブ(より評判を集めるため)になるので、より創造的なものを継続的に作る仕組みになって良いのではないかという話。
これは、最初のアマチュア化とも関係しているなーと読んでて思った。
特定のプロジェクトではなく、特定の人のファンが増えているという現象とも繋がっている感じがした。
📝 NAISTのGitHub Sponsorsの利用を調査したレポートによると、GitHub Sponsors利用者のうち約80%の人は1か2人をスポンサーしている
プロジェクトベースじゃなくて人ベースであるのは、プロジェクトに縛られないという点で、メンテナーにとってはいい点も多いとは思う。
プロジェクトベースだとメンテナンスが強くなりがちだけど、人ベースなら新しいものを作ってみるとかもやりやすくなる。
自分もプロジェクトに縛られすぎないようなことは考えてGitHub Sponsorsやってるのでこの辺の話はだいぶ面白かった。
一方で、誰でもこの状態になるのは難しいよねって話もあった。
また、あまりにもオープンソースプロジェクトは多すぎて、だれを支援すればいいのかわからないという問題もある。
資金提供者が オープンソースに資金を配分するという考えを受け入れたとしても、すぐにその機会に圧倒されてしまう可能性が あります。1回の依存関係チェックで、何百ものオープンソースプロジェクトを取り込むことができます。機関投資家であろうと個人投資家であろうと、資金提供者はどこに努力を集中すべきかをどのように知っているのでしょうか?
これが読もうと思ったきっかけのcore-jsの話とも似ていて、特にJavaScriptは依存関係が膨大で誰を支援するべきかわからなくなるような問題がある。
自分が依存してるライブラリのメンテナーのSponsorできる選択肢をhttps://github.com/sponsors/exploreで見れるが、膨大な数が出てくる。
なので、実際にスポンサーできる選択肢が多すぎると、どれをサポートすればいいのかわからなくなってしまうという問題は実際にあると思う。
この問題に対しては、「ハイコンテキスト、ローディスカウントレート」を取るのがいいのではという話だった。
オープンソースの資金調達の機会を精査することになると、「ハイコンテキスト、ローディスカウントレート」の機会を求めるという Ostrom の原則がうまく機能します。使用するすべてのオープンソースプロジェクトに資金を提供するのは、企業や個人の仕事ではありません。(…省略…)1 人の開発者が 毎日何千ものオープンソースプロジェクトに依存して仕事をしているのに、それぞれの給与を個人的に賄っていないことは問題ありません(気が遠くなるようなことですが)。しかし、彼らが たまたま気に入った特定のプロジェクトがあれば、それを追求すべきです。同様に、オープンソース開発者の仕事は、大海を沸騰させるのではなく、対象となる一連の資金提供者の頭に浮かぶようにすることです。
一つ例として出していたのは、無料で公開してる本のアクセスを調べてみたら、特定のサイトからのアクセスが多かったので、そのサイトの読者に向けて本を売るという話だった。
Practical Typography という人気の本を書いた Matthew Butterick も、一部の読者をターゲットにすることで 成功を収めました。マシューは自分の本をオンラインで 無料で 提供していますが、お金を求めて「絶え間なく物乞いをする」ことで 本を塗りつぶしたくはありませんでした。365 彼の無料トラフィックの多くが わずか 15 から 20 の Web サイトからのものであることに気づいた後、彼はそれらの Web サイトからの訪問者のみをターゲットにすることに決め、彼らが 本にお金を払うことを提案しました。その結果、その年に直接支払いの数が 2 倍になり、年間60 万人以上の読者に無料で 本を提供し続けることが できました 。
core-jsやferossがかつてやっていたターミナルに広告を出すという手法は「ハイコンテキスト、ローディスカウントレート」ではなかったのが、うまくいかなかった理由なのかもと思った(ハイタッチな人を選んで出す仕組みになっていれば、フラストレーションはもっと低くしつつうまくできたのかもしれない)。
または、core-jsのような依存の依存のようなライブラリだと、そもそも使ってることを意識しないのでハイコンテキストとするのが難しいのかしれないと思った。
長々書いてしまって色々飛んだけど、詳細はStripe Press — Working in Publicを読みましょう。
大きく分けて、いわゆるプロジェクトのメンテナー的な深く専門的な方向(プロジェクトとして支援される) と もっとカジュアルで新しいものを創造する方向(人として支援される)の2つがあるよねって感じ。
これをダンベルというのが面白かった。(凹 みたいな形になるからだと思うけど。)
(これと同じような話は、ジャーナリズムなどのニュース業界でも起きていたりするという話も面白かった。)
どちらの場合でも、普通の仕事と同じ金額を稼いでも同じではないという問題はある。
普通の仕事とは違って、保険がなかったり、税金的な部分が異なるので、同じ金額を得ても同じ負担にはならないという問題。
そのため、フルタイムのオープンソースメンテナーになるには、色々ハードルがある。
けど、最近Open Source Collectiveが、プロジェクトの資金を使ってメンテナーを雇用できる仕組みを実装したので、この辺の雇用的なハードルも変わってくるかもしれない。