2 ポイント 投稿者 GN⁺ 2024-02-18 | 1件のコメント | WhatsAppで共有
  • オープンソースのエコシステムには多くの人や企業が依存しているが、メンテナーが商用機能・大企業への就職・投資調達で生計を立てようとすると、まず批判が向けられるという矛盾がある
  • ここでいう オープンソース は、OSI・FSF の厳密な定義より広い意味で使われており、ソースコードを読み、修正し、改変版を配布できるものであれば、Polyform、JSON license、BSL も含む
  • 持続可能性 とは、ガバナンスやコミュニティの健全性だけでなく、メンテナーが住居・食費・医療といった基本的な必要を満たし、無理なく暮らせるかどうかを指す
  • Django は毎日数十万人に使われているが、Django 自体に専任で有給で取り組んでいるのは DSF のフルタイム Fellow 1 名とパートタイム Fellow 1 名だけであり、Python も毎日数百万人に使われている一方で、有給のメンテナーは 12 名未満しかいない
  • Patreon、GitHub Sponsors、VC、Open Core、非 OSI ライセンスにはいずれも欠点があるが、怒りが メンテナー個人 に向かってしまうと、オープンソースの社会的価値を広げることは難しくなる

メンテナーが報酬を得ることはなぜ良いのか

  • オープンソースのメンテナーが報酬を得ることは例外ではなく、祝うべきこと だという観点から出発する
  • 生計を立てる方法を見つけたメンテナーを非難するのではなく、お金を受け取りにくくしている構造やシステムを批判すべきである
  • オープンソースの作業で生きていきたい人は、基本的な必要を満たし、無理なく暮らせるべきである
  • オープンソースは誰にとっても利益のある協業であり、オープンソースのない世界は今よりはるかに悪いものになる、という前提がある

広い意味でのオープンソースと持続可能性

  • オープンソース と free software は、厳密な OSI・FSF の定義ではなく、広い意味で使われている
    • ソースコードを読み、修正し、改変版を配布できるソフトウェアを指す
    • OSI・FSF ライセンスだけでなく、Polyform licensesJSON licenseBSL も含む
  • 「OSI 承認ライセンスだけがオープンソース」あるいは「GPL だけが本当の自由ソフトウェア」といった狭い定義は、問題の一部だと見る
  • ライセンスの実験や多様性が必要であり、「誰でもどんな目的でも利用可能」であることより制約が多くても、オープンソースの範疇に入ると考える
  • 持続可能性 とは、メンテナーが自由ソフトウェアを書きながら、まともあるいは快適な生活を送れるかどうかを意味する
    • 最低基準は、住居、食事、医療のような基本的な必要を満たすことである
    • より理想的には、オープンソースの作業だけで快適あるいはぜいたくな生活も可能であるべきだ

現在のオープンソースは持続可能ではない

  • 自由ソフトウェアを書くことだけで生計を立てている人は、ソフトウェアエンジニア全体の中で実質的に 0 に近い 水準である
  • Canonical、Red Hat、Hashicorp、Mozilla のようにオープンソースの開発者を雇用している企業はあるが、プロプライエタリソフトウェアを書く数百万人のエンジニアと比べると規模は非常に小さい
  • こうした組織の全エンジニアがオープンソースだけを書いているわけでもなく、多くの組織は製品の一部がプロプライエタリであるビジネスモデルに依存している
  • Django と Python の数字

    • 毎日数十万人のエンジニアが Django を使っている
    • Django 自体に有給で専任しているのは、DSF が雇用するフルタイム Fellow 1 名とパートタイム Fellow 1 名、つまり 1.5 人 である
    • 毎日数百万人が Python を使っているが、Python の作業で報酬を得ている人は 12 名未満である
    • これには PSF Developers-in-Residence や、Google、Microsoft のような企業で業務として Python に関わる少数のメンテナーが含まれる
    • 持続可能な状態であれば、Django には業界中央値に近い報酬を受けるフルタイムの担当者が約 12 名必要であり、Python には数十名いるべきである
    • PyPI だけを見ても、その範囲、規模、重要性を考えれば最低でも 10〜15 人のチーム が必要だと考える
    • 「ネブラスカ州にいるどこかの無名の誰か」 が中核的な依存関係を一人で保守している状況であっても、その人が十分に暮らし、休暇を取れるようにするには同僚が必要であり、それが持続可能性につながる

公的支援という理想と現在の隔たり

  • 自由ソフトウェアが公共財として認められ、社会や政府が適切に資金を支援するのが理想的な姿である
  • 医療、住居へのアクセス、公共交通、社会的セーフティネットのような問題もあわせて解決されるべきだという見方がある
  • しかし、こうした変化はすぐには起こらず、生きている間に起こるかどうかも確かではないと見る
  • 「政府が支援すべきだから民間企業がメンテナーにお金を払うべきではない」という主張は、現実に政府が支援しない限り、「メンテナーは報酬を受け取るべきではない」という結論に縮小されてしまう
  • 今の世界では、メンテナーが報酬を得る必要性を認めなければならない

報酬を得るあらゆる方法はひとまず勝利である

  • 現実におけるオープンソースの持続可能性とは、メンテナーに 実際にお金が支払われること を意味する
  • メンテナーが家賃を払いながら自由ソフトウェアを書ける方法を見つけたなら、それ自体が前向きな事例である
  • 前向きな事例と見なせる方法はさまざまである
    • Microsoft に雇用されて Python の作業をする
    • 助成金を受ける
    • Patreon で持続可能な支援水準に達する
    • 自由ソフトウェア開発のために VC 投資を調達する
    • Open Core モデルで持続可能なビジネスを作る
    • Hashicorp のような会社で働く
    • 有料ホスティングオプションでオープンなプロジェクトを支える
    • Amazon 的な搾取を避けるために非 OSI 承認ライセンスをうまく使う

繰り返される批判とその限界

  • メンテナーが報酬を得るたびに、資金調達の手法ごとの批判がついて回る
    • 非 OSI ライセンスはオープンソースではないという批判
    • Microsoft に雇われた人は企業の利害に従属していて信用できないという批判
    • Patreon は物乞いだという批判
    • GitHub Sponsors は Microsoft のレントシーキングを助けるという批判
    • VC 資金は rug pull や enshittification につながるという批判
    • Open Core は bait and switch だという批判
  • 実際、あるメンテナーは T シャツを販売したという理由だけでも批判されたという
  • それぞれの方法には現実の問題がある
    • VC 投資には条件が付き、後になって問題につながることがある
    • Patreon、GitHub、Stripe は支援金の一部を受け取る
    • PolyForm や BSL の追加制約は、Freedom 0 の理想と衝突する
    • Open Core ツールで欲しい中核機能が有料ライセンスにしかないと、フラストレーションを感じることがある
  • こうしたシステムは批判できるが、お金を受け取った メンテナー個人 を攻撃するのは怒りの向け先を間違えている
  • 利用しやすい店が Dollar General しかない人に、そこで買い物したと怒鳴るようなもので、問題は個人ではなく構造と政策にある

純粋性の要求はオープンソースの社会的価値を制限する

  • もっと多くの人が自由ソフトウェアを書き、報酬を得るべきである
  • そのためには、純粋ではない、あるいは不完全な資金調達手段も受け入れる必要がある
  • 資金調達の仕組みや社会的不平等は、引き続き批判し、変えていくべきである
  • メンテナーが報酬を得る方法を見つけたときには、その人を祝福するほうがオープンソース全体にとって有益である

1件のコメント

 
GN⁺ 2024-02-18
Hacker News の意見
  • OSI 承認ライセンスではないもの」をオープンソースの範疇に入れる部分には同意しにくい
    OSI 承認ではない理由は、ずっと前にコミュニティが定義したし、今でも妥当な意味でオープンソースではないから
    そのほかにも、性格の異なるさまざまなものをすべて勝利と見なそうという主張には惹かれない。たとえば「Microsoft に雇用されて Python に取り組む」というのも、職務の細かい条件次第では勝利というより罠かもしれないし、https://ghuntley.com/fracture/ を見ればよい

    • 彼はすでにその反論を予想して答えているので、同意しない自由はあるが、その点を考えていなかったわけではない
      この記事全体が、OSI の定義を意図的に拒む理由を説明するものなのに、反対側の根拠は、彼が明示的に拒否したOSI の定義への訴えだけに見える
      彼は小文字の “open source” / “free software” を意図的に使っており、OSI の Open Source™ や FSF の Free Software™ ではなく、「読んで修正し、条件付きで派生版を配布できるソースコードがあるソフトウェア」という広い意味で使うと明らかにしている
      だから OSI/FSF ライセンスだけでなく、Polyform、JSON license、BSL まで自分なりの “open source” に含めるという
    • 著者がオープンソースの意味を独自に定義するなら、本当にオープンソース作業にお金を払おうという主張なのかは曖昧だ
      むしろ、お金をもらって作業するいろいろなものを「オープンソース」と見なそうという主張に近いのではないかと思う
      たとえば RHEL が今もオープンソースなら Red Hat のプログラマーは有給のオープンソース開発者だが、RHEL が今やプロプライエタリソフトウェアなら、オープンソース作業でお金を受け取る人の数は減ることになる
    • 「OSI がずっと前に定義した」という点に異論はない
      ただし「その定義が今でも最も妥当なのか」がまさに議論の核心だ
      おそらく妥当なのかもしれないが、その定義を問い直すこと自体も十分に有効な問いであり、今人々がやっているのはそれだと思う
    • OSI のオープンソースの定義は満たしているが OSI 承認は受けていないライセンスは、何と呼べばよいのか?
      OSI は今では、新しいライセンスが既存の OSI 承認ライセンスでは埋められない空白を埋めると判断した場合にだけ承認するため、定義のすべての基準を満たしていても承認されない可能性のあるライセンスは無数にある
      [1] https://opensource.org/osd/
  • 数週間前、米国には独立エンジニアや小規模な FOSS プロジェクトへの政府支援がまったくないという内容で上院議員に手紙を送った
    EU の NLNet は素晴らしく、米国にも NLNet のようなものが本当に必要だ

    • 政府が、道路のように利用者へ直接課金しにくい価値を生むインフラを補助すべきだと考えるなら、ソフトウェアも論理的な延長線上にある
      ただ、交通プロジェクトの執行を直接知る立場から、その中の甚大な無駄を見ると、こうした支援がかえって状況を悪化させる可能性もありそうで、判断がつかない
    • OSTIF がだいたい近く、記憶では米国拠点だったはず
  • 同意したい気持ちはあるし立場も理解できるが、「常に」という言葉を使うとニュアンスが消える
    会社が誰かにオープンソース作業の費用を出しながら、プロジェクトを他のユーザーの利益に反する方向へ引っ張っていくなら、それは良いことなのだろうか? そうではないと思う
    人の生計には賛成だが、「ある程度自由な」ソースコードが生まれるからといって、悪い行動まで好ましいとは言えない

    • 記事でもこの部分を扱っているようだ
      要点は、完璧さが良いことを妨げないようにしようということだ
      オープンソースのコードベースで働きたいすべての人が相応の公的資金を受けられるよう努力すべきだが、その間は企業が一部の FLOSS コードに資金を出す現実も受け入れなければならない
      政府が支援すべきだという話はよさそうに見えるが、実際に政府がやらないのなら、結局「オープンソースのメンテナーはお金を受け取ってはいけない」に行き着きかねない
    • だからオープンソースコミュニティが自分たちのプロジェクトを直接支援すべきだ
      コミュニティとユーザーが資金を出さなければ民間企業が資金を出し、そうなれば彼らが発言権を持つ
      オープンソースが大企業に吸い上げられる、外注化された「無料労働」になってはならない
      WordPress エコシステムのように、無料の GPL2+ 版を維持しながら、高度なアドオンのダウンロード、アップデートライセンス、サポートを販売するフリーミアムモデルが最もうまく機能してきた
      オープンソースは政治に似ていて、資金を出す側が決定権を持つ。コミュニティが経済的に自立できなければ、外部資金が方向性を決める
      多くのオープンソースへの貢献は誇らしく称賛に値するが、日中は多くの人が、市場シェアと経済的支配力を拡大しようとする民間企業で働いている
      片方の手でオープンソースに貢献しながら、もう片方の手では民間企業での仕事によって、その効果の一部を打ち消しているようなものだ
      だからオープンソースは自ら資金を調達し、独自の経済的・政治的勢力にならなければならない。そうでなければ常にルールを受け入れる側にとどまり、民間ロビーがオープンソースを損なおうとする試みと戦い続けることになる
    • だから助成金は本当に重要だ
      通常は一定期間内に納品物が生まれ、そのときオープンソースはフルタイムの趣味ではなく職業へと格上げされる
    • それもまた暗黙の「常に」だ
      会社がプロジェクトを引っ張っていく方向が良い可能性は低いが、常に悪いとも言い切れない
      会社が望む方向に潜在ユーザーがはるかに多く、既存の少数ユーザーはフォークできる、という状況も考えられる
  • Open Source Initiative とその定義の起源を思い出すのに適した文脈である
    OSI は 2007年の自らの歴史の中で、かつて「free software」と結び付いていた道徳主義的で対立的な態度を捨て、Netscape を動かした実用的でビジネス上の根拠として売り込むことにし、「open source」という用語と、Raymond が発展させた実用主義と市場に親和的なレトリックを採用した、と説明していた
    数十年後、大企業による搾取を防ごうとする非OSIライセンスの利用者たちが、「本物のオープンソース」ではないという理由で、非常に道徳主義的に非難されている状況は少し滑稽である
    http://web.archive.org/web/20071115150105/https://opensource...

    • 企業も OSI承認済みコードベースと SSPL/BUSL ライセンスのコードベースの違いを気にする
      後者は、BUSL ライセンスのコードを使うサービスをホスティングできない場合が多く、ビジネス上のリスクが生じる
      特定のユースケースが許可されるのか弁護士に相談すべきなのか、今は問題なくてもいつ境界を越えるのかどうやって分かるのか、売上のあるサービスの場合なのか、それとも顧客に直接提供される場合だけなのか、といった疑問がついて回る
      IBM や Collins のように、社内チーム間のサービスにも内部課金が付くコンサルティング型の会社なら、外部顧客が料金を払っていなくても問題になり得る
      アップストリームがバグや機能要望に反応しないときに開発者を雇って貢献できるのか、社内インフラやツールに統合できるのか、より大きなプロジェクトに自由に混ぜられるのかも不明確である
      こうしたライセンスの道徳的側面とは別に、ビジネスの観点だけでも OSI には適合せず、したがって精神的にも「オープンソース」ではないと見なされる懸念を説明できる
  • ここ数年で最も深く関わってきたコミュニティは R/tidyverse だった
    一部の開発者は RStudio(現在の Posit)や R Consortium などの組織から、ソフトウェア、ドキュメント、コミュニティ活動のために報酬を受け取っている
    この分野でのプログラマーとしての経験は素晴らしいものだった。フルタイムで資金提供を受ける OSS 貢献者がいると、非常に大きなレバレッジを持つ人がプロジェクトに多くの時間を注ぎ、何千人もの R 愛好家が恩恵を受ける
    tidyverse パッケージ、Shiny、RMarkdown のようなライブラリを使うと、ドキュメントが非常によく整理されていて、例もシンプルで優れている
    だいたいこう動くだろうと推測してもすぐに当たることが多く、関数やパッケージがそもそもそう設計されている場合も多い
    専任者が少なくとも1人いるだけで OSS の品質は大きく向上するようで、それは小さな貢献をする何十人もの人々をまとめる助けになるからかもしれない
    オープンソースプロジェクトは、ドキュメントやユーザー体験のような重要領域への関心が薄いことが多い。好きな OSS プロジェクトの中にもユーザー体験がひどいものがあるが、貢献者は機能追加は好む一方で、ユーザーにとって一貫したパッケージとして整理したり、不要で混乱を招く貢献を取り除いたりする役割はあまり引き受けないからに見える
    フルタイムで資金提供を受ける OSS 貢献者がほとんどいない、またはまったくいないコミュニティと比べると、ライブラリ、相互運用性、特にドキュメントにおける小さな不便や不整合がはるかに多い
    R コミュニティは、何十人ものフルタイム OSS 人材に報酬を支払うことが、コミュニティに長期的にどれほど大きな利益をもたらし得るかを示す驚くべき例であり、こうした謙虚な巨人たちの肩の上に立てることに感謝している

  • 「メンテナーが報酬を得る方法を見つけるたびに勝利だ」という言葉に同意する
    こうしたことはより一般的になっており、祝うべき事例も多い [0]
    [0] https://fossfox.com/

  • 複数のオープンソースプロジェクトに寄付している
    Linux カーネルのように自分の寄付がなくても大丈夫そうに見えるプロジェクトもあるが、必要だと信じればためらわず寄付するつもりだ
    それ以外のプロジェクトについては、オープンソースの定義を妥協するくらいなら失敗する方を喜んで見届ける。自分にとっては両者は同じ意味である

  • FOSS がいつから「言論の自由のように自由なもの」ではなく「無料のビールのようにタダのもの」と理解されるようになったのか分からない
    開発者の報酬に関する多くの議論は、この2つを混同しているように見える
    オープンソースとは、ソースが公開されていて見たり変更したりする自由があるという意味であって、費用が0円という意味ではない
    コードに関しては、ソフトウェア製品を販売しながらコードを自由に公開するモデルは、あまり現実的なビジネスモデルではないかもしれないが、それでもオープンソースの定義には合致する

    • 常にその両方だったと思う
      ハックして変更する自由は、常に 0円のライセンス費用と切り離せなかった
      初期の自由/オープンライセンスがソースへのアクセスと変更は認めつつライセンス料を取っていたり、初期の FOSS が無料で利用できる一方で変更を禁止していたりしたなら、今のような成功はなかっただろう
      「free software」の2つの自由は昔から結び付いていた
    • 認めたがらない現実は、ほとんどの人が FOSS を使い支援する理由が無料だからということに尽きる
      自由には関心がなくても、費用には誰もが関心を持つ
      それどころか、多くの FOSS 開発者でさえ報酬を受け取ることを拒み、報酬を受け取る人を排斥する。彼らにとってお金はクリプトナイトのような存在だ
      人の時間を含め、あらゆるものには対価が必要だという極めて根本的な法則に反するこの哲学が、FOSS を商用およびプロプライエタリ/クローズドソースのソフトウェアに後れを取らせている大きな原因の一つだと思う
    • 人気のない意見かもしれないが、0円の費用こそ OSS 利用者の99%が気にしている部分だと思う
      利用者が投資しなくてよいため、有料だった場合に可能な範囲よりもはるかに大きな潜在市場へ拡大する
      無料という事実には、人の判断を狂わせる何かがある
      チョコレートを無料と0.01ドルで提示した研究でも、0.01ドルのチョコレートの方がはるかに高級で価値が高くても、無料の選択肢の方がずっと人気だった
      多くの利用者は、ただ何かをダウンロードして数分使って終わりにしたいだけだ。あるいは少なくとも試してみて、最悪の場合は無料版に戻れることで、悪い投資をしたという感覚を避けたいのだ
  • この記事は「それでもオープンソースではないよね」という言葉を、さまざまなソース公開型ライセンスでソフトウェアを配布することへの批判のように解釈している
    そういう意味で言う人もいるかもしれないが、自分にとっては、明確な意味を持つ用語を薄めないようにしようという意味にすぎない
    ときにはソース公開型ライセンスの方がビジネスに適しており、企業がそうする理由も理解できる
    より寛容ではない選択ではあるが、それでも良いことだ。すべてのソフトウェアのソースコードを公開しないことも理解できるのと同じである

  • 協同組合型の技術組織こそが未来だと思う
    人々は無償で働こうとはしないため、オープンソースソフトウェアへの貢献は常に民間企業に後れを取らざるを得ない
    収益化して貢献者に報酬を支払うオープンソースプロジェクトがあるのか気になる
    いつか成功したスタートアップを作ることになったら、このモデルを探ってみたい