ハクソク

世界を動かす技術を、日本語で。

GitHub以前

11日前原文(lucumr.pocoo.org)

概要

  • GitHub 以前、 SourceForge や自前インフラでOSS活動を展開
  • GitHubは OSSコミュニティの中核 となり、信頼や出会いの場を提供
  • npm等と連携し、 依存性管理やアーカイブ性 を大きく変革
  • GitHubの衰退と 分散化の進行、再び自前運用や多様なプラットフォームへ
  • OSSの アーカイブと記録の重要性、公的な保存機関の必要性

GitHub以前のOSSの世界

  • OSSプロジェクトの初期は SourceForge や自分で構築した Trac・Subversion などのインフラ運用
  • Bitbucketもかつては GitHubの有力な代替候補 として存在
  • 小規模なプロジェクトは大学サーバーや 個人運用、大規模なものは独自の集団やインフラを構築
  • 依存性管理 は慎重で、信頼や歴史、運営体制が重視される傾向
  • OSSプロジェクトは 信頼の積み重ね やコミュニティの繋がりが重要視される文化

GitHub登場とOSSの変化

  • GitHub の登場でプロジェクト作成・発見・貢献が格段に容易化
  • Issueトラッカー・Pull Request・Wiki・API・CI など多機能な共通インフラの普及
  • コードの 公開性・履歴管理 ・コラボレーションの透明性が標準化
  • アーカイブ性 の高さ：廃止プロジェクトも記録・議論・フォークが見つかる
  • npm などのエコシステムと連動し、 マイクロ依存性 や爆発的なプロジェクト数増加

分散化とGitHubの衰退

  • GitHub の製品方針や不安定さ、AIノイズ、リーダーシップ不在への不満拡大
  • 著名プロジェクトや開発者（例： Mitchell Hashimoto や Strudel）が Codeberg 等へ移行
  • 分散化 の進行により、各プロジェクトが自前運用や多様なプラットフォームへ分散
  • 分散化は 自治性や多様性 を促進する一方、記録や社会的文脈の消失リスクも増大

OSSアーカイブの必要性

  • アーカイブや図書館的役割 を果たす、安定した公的保存機関の必要性
  • 依存性・リリースアーティファクト・メタデータ・議論履歴などの 長期保存
  • ビジネスモデルや企業の都合に左右されない 中立的な保存体制 の重要性
  • OSSが分散化・自前運用へ回帰する中で、 記録の消失リスク への対策が急務

OSSコミュニティのこれから

  • GitHub の一極集中から 多様な運用形態 への移行が進行
  • 開発者やプロジェクトごとに 最適なプラットフォーム選択 や自前運用が重要
  • 分散化は 自治性・柔軟性 を高めるが、 アーカイブ性や記録の維持 も両立すべき課題
  • OSS文化の持続には、 社会的な記憶の保存 と アクセス性の確保 が不可欠

Hackerたちの意見

トラックが大好きだった！新しいオープンソースプロジェクトを始めるとき、トラックをセットアップするのが最初のステップだったのは、ほんとに大変だったよ。面白い事実：Djangoは今でもトラック上で動いていて、もう20年以上もそうなんだって！(そのセットアップには関わってなかったけど、前にあったプライベートトラックの立ち上げにちょっと手伝ったかもしれないけど、正直覚えてない！)

└

変なことに、当時は「やりすぎて何も得意じゃない」と思ってたのに、トラックに対してもいい思い出があるんだよね。今はその賞はGitlabに行くんだろうけど、たぶんそれも懐かしく思い出すだろうな。

└

トラックは、PHPじゃなくてPythonでアプリを作ろうと思った理由の一つなんだ。素晴らしいプラグインシステムがあったからね！

└

ビットバケットは好きだった。ちゃんと機能してくれたし、壊れなかったし、マーカリアルが好きだった。雇い主がGitHubを使ってたから移行したけど、今でもGitHubは単なるGitのエンドポイントとして使ってるし、ビルドやデプロイはDockerとシェルスクリプトでやってるから、移行はすごく楽なんだ。仕事のことは、選べないならお金をもらって使うものを使うよ、昔のSVNの時代と同じようにね。

└

トラックは素晴らしかった。でも、最初のイシュー・トラッカーはバグジラだった。セットアップはちょっと面倒だったし、何とも連携が悪かったけど、「Zarro Boogs」を見るのはすごく満足感があった。

これでコード.google.comのことを考えちゃった。Googleがあんなにやらかすなんて信じられない。

└

…Googleに会ったことある？

└

なんか懐かしいな。あのチームにいたけど、閉鎖される前だったよ。

└

思い出…

でも、GitHubがやった中で最も評価されていないことはアーカイブ作業だと思う。GitHubはライブラリになった。放棄されたプロジェクトでも見つけられるから、ソフトウェアのコモンズの大部分のインデックスになったんだ。実際、これは悪いことだと思う。中央集権的だけど99%の時間役立つものが、私たちのアーカイブスキルを衰えさせるんだよね。何かを生かすためには誰かが種をまかないといけないなら、みんなが本当に大事にしているもののコピーを保持するのが上手くなるはず。何かを削除される場所が一つだけあってはいけない。GitHubのプロジェクトがDMCAで削除されると、みんなのフォークも一緒に消えちゃう。2024年に任天堂が人気のスイッチエミュレーターを削除したときのことを見てみて。アーカイブや継続の努力は、誰が最新のリビジョンをチェックアウトしているかを見つけて共有することだったんだ。それができたのは、すごく人気のあるプロジェクトだったからだよね。https://news.ycombinator.com/item?id=40254602 ちなみに、このサイトのスプラトゥーン風のヘッダー/フッターアニメーションが大好き！すごく控えめで、雰囲気を盛り上げてくれるし、スクロールするとすぐに邪魔にならないのもいいね。これ、パクっちゃうかも笑

└

アーカイブは簡単だけど、著作権や知的財産法が邪魔をするんだよね。情報へのアクセスを妨げる障害を取り除けば、権力の集中が減るはずなんだ。

└

これには同意できないな。GitHubは何年も前から存在していて、開発者たちが信頼している理由の一つは、彼らが「アーカイブ」作業をまだマネタイズしていないからだよね（新しいCopilot機能についてはまだ未定だけど）。代わりに、各サイトがそれぞれのDMCAルールを持つことになるとどうなるんだろう？それがより良い選択肢になるのかな？

└

中央集権的だけど99%の時間役に立つものがあると、私たちのアーカイブスキルが衰えてしまう。あと、「GitHubにないものは存在しない」って感じがして、それは良くないことだよね。開発者の中には、コードが他の場所に保存できるってことを知らない人が多すぎる気がする。

これを読んで、mitchellhの投稿も見たら、コードアーカイブサービスに興味が湧いて、いくつかのプロジェクトを見つけたよ。GitHubには自分たちのアーカイブプログラムがあるみたいだね: https://archiveprogram.github.com/ Software Heritageはユネスコが資金提供している非営利団体だよ: https://www.softwareheritage.org/2019/08/05/saving-and-refer... ただ、主にコードやコミット履歴が中心で、イシューやPR、ディスカッション、ウィキなどの周辺メタデータはあまりないんだよね。

私はFlaskを試した最初の人の一人だと思う。AppEngineを無料で簡単に使うためにPythonを学んだから、Flaskが出たときにちょうどいいタイミングだった。Arminのファンで、リンクをクリックする前から彼のドメインを認識してたよ。彼が指摘しているように、あの頃はGitHubがデフォルトじゃなかったんだ。彼の投稿は、数時間前のMitchellの投稿に対するレスポンスだね。彼が長文で質の高い、よく考えられた投稿をすぐに書いたのには感心したよ。

GitがFossilよりも一般的なプロジェクトで勝ったのが未だに悔しい。確かに、GitはLinuxカーネルのような大規模なコードベースに対してはパフォーマンスの利点があるけど、大多数のプロジェクトはVCSのパフォーマンス制限にぶつかることはないんだよね。Fossilの内部ツール（ウィキ、フォーラム、チケットなど）は、コードと一緒にバージョン管理できるのが本当に便利なんだ。私はフリーランスの仕事でFossilを使っていて、プロジェクトの文脈やクライアントとの合意事項にすぐに戻れるのがいい。コードベースを汚したり、メールやノートソフトを集めたりしなくても、すぐにスピードを取り戻せるからね。まだ変わる可能性はあるけど、Gitが文化的に根付いているから切り替えられないなんて考えは嫌だ。Fossilは切り替えが超簡単で、Gitからの移行も実際には楽だよ。

└

大きなリポジトリでGitが速くなる理由は何だろう。長い間、大きなバイナリは除外されていたけど。

└

今こそ誰かがfossilhub.comを買って新しいコミュニティを作る絶好のタイミングだね。

GitHubが私たちに与えたもの 私にとって、GitHubが私たちに与えた明確なものの一つは、プロジェクトではなく人に基づいた構造だった。プロジェクト名を考えてsourceforgeで予約するという（私にはとても真剣に感じた）プロセスを経るよりも、自分の名前に付けたリポジトリをすぐに作れるのは解放感があった。GitHubのおかげで「これはちょっとしたことだ」というメンタル負担がずっと軽く感じられた。 > プロジェクトにはイシュー追跡、プルリクエスト、リリースページ、ウィキ、組織ページ、APIアクセス、ウェブフック、そして後にCIが与えられた。これらは一度に全部は来なかったけどね。新しいユーザーアカウントを作って組織をシミュレートしたときのことを今でも覚えてる。友達と「GitHubは多分数ヶ月後にバグトラッカーをリリースするだろう」という前提で、プロジェクトのためにバグトラッカーソフトを設定するかどうか話し合ったのをはっきり覚えてる。結局、リポジトリにテキストファイルをコミットしておくことにしたんだ。イシューは数ヶ月後に発表されたよ。

みんながcodebergに移行することが心配だな。サイトはもうめっちゃ遅いけど、自己ホスティングすると結構いいらしいね。自分のマシンにforgejoのインスタンスを立てられる人は、可能ならやってみてほしい！

小さくて分散型のフォージは、デジタル主権の観点から見るとすごく理にかなってる。GitHubのような単一のインスタンスに過度に依存するのは、長期的には健康的じゃないよね。彼らが解決しなきゃいけない問題は、フェデレーションだね。

[遅延]