オープンソースの未来

xguru · 2024-08-12T10:08:18+09:00

私たちのCOOであり共同創業者でもあるAnneは、ドイツの食品会社DelineroのCEOだったときに訴訟を起こされた。仕入れ先が提供したラズベリージャムを「Himbeermarmelade」と表示していたが、ドイツではマーマレードと表示するには少なくとも20%の柑橘類を含んでいなければならないという『Konfitürenverordnung（ジャム規則）』があったためこれは一般的に使われる言葉の意味とは相反する規則だったが、少数の利害関係者が昔に作った法律であるため、従わざるを得なかった現在の「オープンソース」も、これと似た状態にあると言える。OSIがKonfitürenverordnungのように、一般的な用法とは異なる形に進化した用語を依然として厳格に規制しているでは、どうすれば建設的な方向へ進めるのだろうか？「オープンソース」をしない方法 GitButlerがクライアントコードを「Fair Sourcing」し、OSI承認ではないライセンスで公開したとき、どう発表するかを悩んだほとんどの人は「オープンソース」を「GitHubで公開されているもの」と同一視しており、さらにGPL/コピーレフトライセンスのややリスクのある含意のため、人々はどのライセンスが適用されているかを確認することに非常に慣れているだからといって「Source Avaialable'd」のような曖昧な言い方はしたくなかったし、混乱を避けるために「オープン」という言葉を使ったが、攻撃を受けた少数だが声の大きい人々が、この用語を守り、具体化しようとしていることに気づいた「オープンソース」は「クローズドソース」の論理的な否定ではない。GitHubで公開され参加可能であることと、OSIが独自に規定する「オープンソース」の技術的な10の定義との間には、大衆的理解のギャップが存在するオープンソースの簡単な歴史 1950〜60年代の初期コンピューティング時代には、ソフトウェアはハードウェアに結び付いており、別個に区別する必要がなく、ハードウェア企業が自由に配布していた 1970〜80年代にハードウェアがコモディティ化すると、ソフトウェア自体の価値が生まれ、IBM、AT&Tなどの大企業が、費用をかけて作ったソースコードへのアクセスを制限し始めたこれに対し、Richard Stallmanらは企業の利害から保護された独自のOSやツール群を作り始め、GPLなどの相互主義的ライセンスによって、IBMやAT&Tがそれらを利用するなら、すべてを自由ソフトウェアにしなければならないよう強制した「私たちのおもちゃで遊べないなら、あなたたちも私たちのおもちゃでは遊べません。」彼らはこの運動を「自由ソフトウェア」と名付け、EmacsやGNUコンパイラシステムのような多くの素晴らしいツールを生み出した。これらは今日でも現代コンピューティングの大半における基本ツールである自由ソフトウェア運動の根本的な焦点は、ユーザーがソフトウェアを実行、複製、配布、研究、改変、改善できる自由を保障することにあった。それは当時、彼らを取り巻く企業利益によって奪われていた自由だった 1990年代初頭にはLinus TorvaldsのLinuxカーネルによって完全なOSがそろい、LAMPスタックなど自由ソフトウェアのエコシステムが成長し、企業もそれを使い依存するようになった 1997年、Eric Raymondは、自由ソフトウェアの開発モデルがクローズドなものより優れているとするエッセイ『伽藍とバザール』を発表し、これはNetscapeがNavigator Suiteのソースコードを公開することを正当化する際に引用された Netscapeがソースコードを公開することを決めたとき、パロアルトで開かれた戦略セッションで、Raymondと数名の著名なLinuxおよび自由ソフトウェア開発者は、「オープンソース」という新しい用語を作って使うことに合意した「会議参加者は、Netscapeがコードを公開する動機となった実用的かつビジネス上の根拠が、潜在的なソフトウェア利用者や開発者とコミュニケーションし、コミュニティに参加してソースコードを作成・改善してもらうよう説得するうえで価値ある方法だと考えていました。参加者たちはまた、このアプローチを識別し、哲学的・政治的に焦点を当てた『自由ソフトウェア』というラベルと区別できる単一のラベルがあると有用だとも考えていました。」重要なのは、「自由ソフトウェア」と「オープンソース」の間に実質的な法的または実用的差異はないということほとんどのライセンスは両方の定義で互換性があり、認められている「オープンソース」は、Netscapeのようなより多くの企業にプロフェッショナルなソースコードの公開を受け入れてもらうために、Stallmanとその運動の政治的目標から、ソフトウェア公開の実用性を切り離して、ビジネスフレンドリーにブランド変更したものにすぎないあるいは自由ソフトウェア側の人々が言うように「オープンソースは開発方法論であり、自由ソフトウェアは社会運動です。」オープンソースとGitHub時代「オープンソース」という言葉の定義とマーケティングは1998年、つまり今から25年以上前のものだ。では、過去25年間のコンピューティングとソフトウェア開発において、オープンソースには何が起きたのだろうか？特に過去10年間、GitHubとGitHubスタイルのソフトウェア開発はオープンソースに非常に大きな影響を与えた 1998年には企業にオープンソフトウェアを受け入れてもらおうとしていたが、現在ではほぼすべてのオープンソースソフトウェアが企業によって書かれるか支援されている最大の変化の一つは「開発ワークフローの標準化」であり、とりわけGitHubがそれを主導した以前はオープンソフトウェアのプロジェクトと企業プロジェクトの間には大きな違いがあったが、今ではほとんど差がないみながGitを使うほぼ全員がプルリクエスト（またはマージリクエスト、あるいはこの機能を模倣した別の方法）を使うほとんどのチームはGitHub Flow（Trunkベース開発、GitLab Flowなど）の何らかの形を使っている今やリポジトリが公開かどうかだけが唯一の違いだ。25年前にはプロセスに多くの摩擦があったが、今ではオープンソース化するのにほとんどプロセス変更が要らないオープンソースの次の段階は何かほぼすべての企業がオープンソースソフトウェアを使い、生み出すようになったことで、オープンソース（自由ソフトウェア）運動は成功したのだろうか？オープンソースの世界には現在、二つの大きな問題がある。「開発者の持続可能性」と「商用オープンソースはViableか」だ開発者の持続可能性の問題オープンソースへの依存が非常に大きくなるにつれ、持続可能性と保守の問題が生じている。XZ Utilsのバックドア悪用事件は最近の有名な例だほぼすべてのメンテナーが燃え尽きや嫌がらせに苦しんでいる。オープンソースソフトウェアを書いて保守しながら収入を得るのはほぼ不可能だオープンソースの開発者やメンテナーの大半は、いまや大企業の支援を受けている Linux、Git、Ruby、Reactなどを見れば、重要なオープンソースプロジェクトの主要コントリビューターの多くは、GitHub、Microsoft、Red Hatなどの企業スポンサーによってプロとして雇用されている開発者がXZ Utilsのようなプロジェクトを保守しながら、きちんと生計を立てるのは難しい一社が開発者に支払うのではなく、何千もの企業がプロのメンテナーに少額ずつ支払うのが理想的だろう主な問題は、現時点でそれを実現する良い方法がないことだ GitHub Sponsors、Thanks.dev、Liberapay、Tideliftなど有望な取り組みはあるが、企業が寄付できる適切なインセンティブの問題はまだ解決していない SentryはOSS Pledgeという新しい取り組みを推進しており、GitButlerも10月に公開されれば参加する予定だしかし、このような方法でオープンソースエコシステムにおける開発者の持続可能性という大きく、しかも拡大しつつある問題を解決できるかどうかは、まだ分からない商用オープンソースの問題開発者たちは長らくオープンソースとオープンなコミュニティを愛して育ち、会社やプロジェクトを始めるときには基本的にオープンにしたいと考えるしかし個々のメンテナーと同じように、オープンソースにも企業としての持続可能性の問題がある ElasticsearchやRedisの事例に見られるように、ソフトウェアをプロとして開発するために時間と資金を投じると、Amazonなどの大企業がその成果物を利用して直接競争してくるリスクがある多くのプロの作り手は、ソフトウェアに投資し、後になってそれが自分たちに不利に使われないようにしたいと考えているそれはライセンスを工夫すること、あるいはソースコードをクローズドにすることを意味する私はFair Source運動が、この拡大する問題に対する優れた、そして必要な解決策だと信じており、ここ数年ますます多くの問題と混乱を生んできたオープンソースエコシステムのギャップを埋めるものだと考えているこれは、主として許容的で、ソースが利用可能で、GitHubコミュニティが参加するプロフェッショナルなプロジェクトを指す新しい用語であり、以前は非公開で進められていたプロジェクトがより多く公開されるよう促すために切実に必要な解決策だと考えるコラボレーションの未来オープンソースの未来は、単に「Open Source」とOSIの10のKonfitürenverordnungだけではないそれは、誰にとっても可能で価値のあるOpen Source、安全な投資のために必要なFair Source、そして重要な基盤オープンライブラリやプロジェクトに対する大規模な共同資金調達の組み合わせである重要なオープンソースライブラリの保守を持続可能にしなければならず、持続可能な商用ソース利用可能ライセンスというクラスを受け入れ、常態化させる必要がある可能な限り、すべてを許容するOSIライセンスでオープンソース化すべきであり、何よりもまずクローズドソースを過去のものにしなければならない今あなたにできることはクローズドソフトウェアをFair Sourceにしオープンソースに依存しているならOSS Pledgeに参加すること

(blog.gitbutler.com)

19 ポイント投稿者 xguru 2024-08-12 | 5件のコメント | WhatsAppで共有

私たちのCOOであり共同創業者でもあるAnneは、ドイツの食品会社DelineroのCEOだったときに訴訟を起こされた。仕入れ先が提供したラズベリージャムを「Himbeermarmelade」と表示していたが、ドイツではマーマレードと表示するには少なくとも20%の柑橘類を含んでいなければならないという『Konfitürenverordnung（ジャム規則）』があったため
これは一般的に使われる言葉の意味とは相反する規則だったが、少数の利害関係者が昔に作った法律であるため、従わざるを得なかった
現在の「オープンソース」も、これと似た状態にあると言える。OSIがKonfitürenverordnungのように、一般的な用法とは異なる形に進化した用語を依然として厳格に規制している
では、どうすれば建設的な方向へ進めるのだろうか？

「オープンソース」をしない方法

GitButlerがクライアントコードを「Fair Sourcing」し、OSI承認ではないライセンスで公開したとき、どう発表するかを悩んだ
ほとんどの人は「オープンソース」を「GitHubで公開されているもの」と同一視しており、さらにGPL/コピーレフトライセンスのややリスクのある含意のため、人々はどのライセンスが適用されているかを確認することに非常に慣れている
だからといって「Source Avaialable'd」のような曖昧な言い方はしたくなかったし、混乱を避けるために「オープン」という言葉を使ったが、攻撃を受けた
少数だが声の大きい人々が、この用語を守り、具体化しようとしていることに気づいた
「オープンソース」は「クローズドソース」の論理的な否定ではない。GitHubで公開され参加可能であることと、OSIが独自に規定する「オープンソース」の技術的な10の定義との間には、大衆的理解のギャップが存在する

オープンソースの簡単な歴史

1950〜60年代の初期コンピューティング時代には、ソフトウェアはハードウェアに結び付いており、別個に区別する必要がなく、ハードウェア企業が自由に配布していた
1970〜80年代にハードウェアがコモディティ化すると、ソフトウェア自体の価値が生まれ、IBM、AT&Tなどの大企業が、費用をかけて作ったソースコードへのアクセスを制限し始めた
これに対し、Richard Stallmanらは企業の利害から保護された独自のOSやツール群を作り始め、GPLなどの相互主義的ライセンスによって、IBMやAT&Tがそれらを利用するなら、すべてを自由ソフトウェアにしなければならないよう強制した

「私たちのおもちゃで遊べないなら、あなたたちも私たちのおもちゃでは遊べません。」
- 彼らはこの運動を「自由ソフトウェア」と名付け、EmacsやGNUコンパイラシステムのような多くの素晴らしいツールを生み出した。これらは今日でも現代コンピューティングの大半における基本ツールである
- 自由ソフトウェア運動の根本的な焦点は、ユーザーがソフトウェアを実行、複製、配布、研究、改変、改善できる自由を保障することにあった。それは当時、彼らを取り巻く企業利益によって奪われていた自由だった
1990年代初頭にはLinus TorvaldsのLinuxカーネルによって完全なOSがそろい、LAMPスタックなど自由ソフトウェアのエコシステムが成長し、企業もそれを使い依存するようになった
1997年、Eric Raymondは、自由ソフトウェアの開発モデルがクローズドなものより優れているとするエッセイ『伽藍とバザール』を発表し、これはNetscapeがNavigator Suiteのソースコードを公開することを正当化する際に引用された
- Netscapeがソースコードを公開することを決めたとき、パロアルトで開かれた戦略セッションで、Raymondと数名の著名なLinuxおよび自由ソフトウェア開発者は、「オープンソース」という新しい用語を作って使うことに合意した
「会議参加者は、Netscapeがコードを公開する動機となった実用的かつビジネス上の根拠が、潜在的なソフトウェア利用者や開発者とコミュニケーションし、コミュニティに参加してソースコードを作成・改善してもらうよう説得するうえで価値ある方法だと考えていました。参加者たちはまた、このアプローチを識別し、哲学的・政治的に焦点を当てた『自由ソフトウェア』というラベルと区別できる単一のラベルがあると有用だとも考えていました。」
重要なのは、「自由ソフトウェア」と「オープンソース」の間に実質的な法的または実用的差異はないということ
- ほとんどのライセンスは両方の定義で互換性があり、認められている
- 「オープンソース」は、Netscapeのようなより多くの企業にプロフェッショナルなソースコードの公開を受け入れてもらうために、Stallmanとその運動の政治的目標から、ソフトウェア公開の実用性を切り離して、ビジネスフレンドリーにブランド変更したものにすぎない
あるいは自由ソフトウェア側の人々が言うように

「オープンソースは開発方法論であり、自由ソフトウェアは社会運動です。」

オープンソースとGitHub時代

「オープンソース」という言葉の定義とマーケティングは1998年、つまり今から25年以上前のものだ。では、過去25年間のコンピューティングとソフトウェア開発において、オープンソースには何が起きたのだろうか？
特に過去10年間、GitHubとGitHubスタイルのソフトウェア開発はオープンソースに非常に大きな影響を与えた
1998年には企業にオープンソフトウェアを受け入れてもらおうとしていたが、現在ではほぼすべてのオープンソースソフトウェアが企業によって書かれるか支援されている
最大の変化の一つは「開発ワークフローの標準化」であり、とりわけGitHubがそれを主導した
以前はオープンソフトウェアのプロジェクトと企業プロジェクトの間には大きな違いがあったが、今ではほとんど差がない
- みながGitを使う
- ほぼ全員がプルリクエスト（またはマージリクエスト、あるいはこの機能を模倣した別の方法）を使う
- ほとんどのチームはGitHub Flow（Trunkベース開発、GitLab Flowなど）の何らかの形を使っている
今やリポジトリが公開かどうかだけが唯一の違いだ。25年前にはプロセスに多くの摩擦があったが、今ではオープンソース化するのにほとんどプロセス変更が要らない

オープンソースの次の段階は何か

ほぼすべての企業がオープンソースソフトウェアを使い、生み出すようになったことで、オープンソース（自由ソフトウェア）運動は成功したのだろうか？
オープンソースの世界には現在、二つの大きな問題がある。「開発者の持続可能性」と「商用オープンソースはViableか」だ

開発者の持続可能性の問題

オープンソースへの依存が非常に大きくなるにつれ、持続可能性と保守の問題が生じている。XZ Utilsのバックドア悪用事件は最近の有名な例だ
ほぼすべてのメンテナーが燃え尽きや嫌がらせに苦しんでいる。オープンソースソフトウェアを書いて保守しながら収入を得るのはほぼ不可能だ
オープンソースの開発者やメンテナーの大半は、いまや大企業の支援を受けている
- Linux、Git、Ruby、Reactなどを見れば、重要なオープンソースプロジェクトの主要コントリビューターの多くは、GitHub、Microsoft、Red Hatなどの企業スポンサーによってプロとして雇用されている
開発者がXZ Utilsのようなプロジェクトを保守しながら、きちんと生計を立てるのは難しい
- 一社が開発者に支払うのではなく、何千もの企業がプロのメンテナーに少額ずつ支払うのが理想的だろう
主な問題は、現時点でそれを実現する良い方法がないことだ
- GitHub Sponsors、Thanks.dev、Liberapay、Tideliftなど有望な取り組みはあるが、企業が寄付できる適切なインセンティブの問題はまだ解決していない
SentryはOSS Pledgeという新しい取り組みを推進しており、GitButlerも10月に公開されれば参加する予定だ
しかし、このような方法でオープンソースエコシステムにおける開発者の持続可能性という大きく、しかも拡大しつつある問題を解決できるかどうかは、まだ分からない

商用オープンソースの問題

開発者たちは長らくオープンソースとオープンなコミュニティを愛して育ち、会社やプロジェクトを始めるときには基本的にオープンにしたいと考える
- しかし個々のメンテナーと同じように、オープンソースにも企業としての持続可能性の問題がある
ElasticsearchやRedisの事例に見られるように、ソフトウェアをプロとして開発するために時間と資金を投じると、Amazonなどの大企業がその成果物を利用して直接競争してくるリスクがある
多くのプロの作り手は、ソフトウェアに投資し、後になってそれが自分たちに不利に使われないようにしたいと考えている
- それはライセンスを工夫すること、あるいはソースコードをクローズドにすることを意味する
私はFair Source運動が、この拡大する問題に対する優れた、そして必要な解決策だと信じており、ここ数年ますます多くの問題と混乱を生んできたオープンソースエコシステムのギャップを埋めるものだと考えている
- これは、主として許容的で、ソースが利用可能で、GitHubコミュニティが参加するプロフェッショナルなプロジェクトを指す新しい用語であり、以前は非公開で進められていたプロジェクトがより多く公開されるよう促すために切実に必要な解決策だと考える

コラボレーションの未来

オープンソースの未来は、単に「Open Source」とOSIの10のKonfitürenverordnungだけではない
それは、誰にとっても可能で価値のあるOpen Source、安全な投資のために必要なFair Source、そして重要な基盤オープンライブラリやプロジェクトに対する大規模な共同資金調達の組み合わせである
重要なオープンソースライブラリの保守を持続可能にしなければならず、持続可能な商用ソース利用可能ライセンスというクラスを受け入れ、常態化させる必要がある
可能な限り、すべてを許容するOSIライセンスでオープンソース化すべきであり、何よりもまずクローズドソースを過去のものにしなければならない
今あなたにできることは
- クローズドソフトウェアをFair Sourceにし
- オープンソースに依存しているならOSS Pledgeに参加すること

5件のコメント

bus710 2024-08-13

資本主義の世界で生きている以上、オープンソースだけに没頭するわけにはいかないのが現実ですよね。一方で、本当に重要なライブラリやユーティリティであれば、企業からのスポンサーシップがもっと増えてほしいとも思います。

ユーザースペースのデスクトップ／ターミナルユーティリティは、特にこうした支援を受けにくいです。カーネルなら大企業が多く支援していますし、モバイルならアプリストアで商業化がうまく進んでいます。また、Webやファームウェアなどはある程度マーケット分析をしてから開発するため、まだ心配は少ないのですが、一般ユーザーが知らず知らずのうちに使っているソフトウェアやライブラリは、ハードルの設定自体も難しいので、本当に収益化が難しいように思います。オープンソースはかなり活発ではあるものの、その先へ大きく飛躍するのは簡単ではないですね。

bus710 2024-08-13

オープンソースを愛し、日頃から便利に使っているだけに、見えないところで多くの人のために献身的に開発している人たちも、適切なライセンス設定によって恩恵を受けられるとよいと思います。

chabulhwi 2024-08-13

ドルー・デボールト（Drew Devault）が書いた記事「So you want to compete with or replace open source（オープンソースと競争したい、あるいはオープンソースを置き換えたいのですか？）」に、次の一節があります。

From https://drewdevault.com/2024/07/…:

Nevertheless, the revolutionary economics of FOSS are based on collaboration, and are incompatible with competition.

自由・オープンソースソフトウェアでは、異なる組織に属するコントリビューターが協力するときに共同の利益が生まれますが、フェアソースソフトウェアでは、独占的な地位を享受する個人や組織のために、ほかのコントリビューターが無償で協力する理由はほとんど、あるいはまったくありません。

いずれにせよ、私もフェアソースがクローズドソースよりは良いと思っていますし、オープンソースソフトウェアのメンテナーが自分の努力に対する報酬を得たいのに得られない、という状況を私も望みません。

ただ、フェアソースがオープンソースのように、無償の開発貢献という恩恵を受けられるのかについては疑問です。そして、誰かが自分のソフトウェアをオープンソースとして配布するとき、その人は自分がどの利用者からも金銭的な報酬を受け取れないこと、そしてそのソフトウェアがクラウド大手の「ただ乗り」になる可能性があることを心に留めておくべきです。

xguru 2024-08-12

GitButler は今や Fair Source です