NISHIO Hirokazu[Translate]
オーナーのいないOSS
>dmikurube 公式パッケージレジストリとビルド済みバイナリ配布というやつが OSS に妙な責任感を発生させているのかもしらんな。だって (まだ open source という言葉が定義されてなかったくらい) 昔の公開ソフトウェアなんて、各自がパッチ集めてきたり自分でビルドしたりして使うのが当たり前だったじゃない?
>dmikurube公式ビルド」とか「公式リリース」という概念と「オーナーシップ」は強く結びつきがちで、オーナーシップを持つ (持たされる) とそこに責任 (感) が発生しがちなんではないか
>dmikurube 近年はたいていのプログラミング言語に、公式 (OSS) パッケージレジストリとそれを用いるビルドシステムが存在するけれども、実はあれ、善意で舗装された地獄への道だったりしないだろうか
>dmikurube fork と patch があちこちに乱れ飛ぶ乱世のほうが開発者にとって平和だったのかもしれぬ
>dmikurube つまり semver とか敵
>dmikurube GitHub みたいな中央ソースコードリポジトリも同様だよな。 GitHub みたいなものがあるにしても /user/repo じゃなくて /repo しか存在せず、みんなが勝手に branch を push しまくれる世界観。使う方はリリースとかバージョンを指定するのではなく commit hash をしいして使う
>dmikurube 実際こっちのが Linus オリジナルの git 観に近いかもしらん
>dmikurube 以上の話はもちろん極論として言っているわけですが、オーナーシップ概念がもたらした悪い側面は間違いなくあると思う
>dmikurube こちらで言っておられる考え方に近そう
> >takiuchi: 専門のメンテナを置かずに使用者がパッチを送ればいいんじゃないかな。PRを半自動でmergeしてブロックチェーンのようにパッチが一番多いブランチがmainになるとか


>nishio 社会の共有財に対して「支払わなくてもコピーして使えるから」と誰もが支払いをしなかった結果、希少な財を生み出していたOSSメンテナーが破壊されるの、いわゆる「共有地の悲劇」だな、どうしたらいいものやら
>takiuchi 専門のメンテナを置かずに使用者がパッチを送ればいいんじゃないかな。PRを半自動でmergeしてブロックチェーンのようにパッチが一番多いブランチがmainになるとか
>takiuchi 力を合わせて助けようみたいなのはプログラマーWayじゃないんだよな。もっと怠惰に自動的にうまくいく方法を考えたい

ブロックチェーンと違ってブランチAに対するパッチがそのままブランチBにも適用できたりするな
各ブランチにAIがいて、他のブランチの修正を見て、自分の目的に対して有用だと思ったら自動でマージする
Devinくらいの能力があれば仕組みをつくりさえすれば可能

> Linus オリジナルの git 観
o3-mini-high
Linus Torvalds が最初に Git を設計した際の狙いは、中央集権的な公式リポジトリに依存せず、各開発者が自由に自分のリポジトリを持ち、コミットハッシュという一意な識別子で状態を管理する分散型システムを実現することでした。

具体的には、Linus はLinuxカーネルの膨大な変更を効率よく管理するため、パッチを個々の開発者がローカルで自由に作業し、後で必要に応じて統合(マージ)できる仕組みを求めました。これにより、公式ビルドやリリースに伴う重い責任感を排除し、むしろ各自のコミットハッシュが真の「バージョン」の指標となる世界観を目指していました(​Git - Wikipedia)

現代のGitHubのように、リポジトリが中央に集約され公式リリースが強調される運用形態は、こうしたLinusの本来の設計思想とは異なり、開発者に余計なオーナーシップ意識や管理責任を生む可能性があるという指摘につながっています。


"Engineer's way of creating knowledge" the English version of my book is now available on [Engineer's way of creating knowledge]

(C)NISHIO Hirokazu / Converted from [Scrapbox] at [Edit]