3 ポイント 投稿者 GN⁺ 2025-08-29 | 1件のコメント | WhatsAppで共有
  • 最近の報道で、ロシア人開発者が作ったオープンソースソフトウェアの利用に対する批判が提起された
  • 実際には、ほぼすべてのオープンソースプロジェクトの大半が、たった一人の個人メンテナーによって運営されている
  • NPMだけでなくさまざまなエコシステムでも、単独のメンテナーが人気パッケージを管理している事例が非常に多い
  • この構造の問題は、メンテナー一人への過度な負担とサプライチェーンリスクにある
  • 問題の本質は国籍ではなく、現実的に不足しているリソースと支援である

序論: オープンソースと最近の論争

  • The Registerで、ロシア人開発者が作ったオープンソースユーティリティの使用について、米国防総省の依存性を問題視する記事が報じられた
  • 当のオープンソース開発者は、不当な非難を受けている状況にある
  • 記事の内容はオープンソースの現実を誤解しており、そのようなアプローチの限界を指摘している

オープンソースの現実: 「一人」という構造

  • データによれば、ほとんどのオープンソースプロジェクトは一人で管理される形になっている
  • ecosyste.ms プロジェクトでは、約1,180万件のオープンソースプロジェクトがデータとして集計されている
    • このうち約700万件が単独メンテナーである
    • 残りの約400万件のプロジェクトはメンテナー数が不明だが、そのかなりの数もやはり一人だと推定される
    • ごく少数のプロジェクトだけが、数百人のメンテナーを抱えている

人気プロジェクトも例外ではない

  • 多くの人は「重要なオープンソースや人気プロジェクトは複数人で管理されているはず」と考えるが、実際にはNPMなど主要なエコシステムでも事情は変わらない
  • NPMエコシステム内には、400万件を超える単独メンテナープロジェクトが存在する
  • 月間100万回以上ダウンロードされるNPMパッケージの中でも、約半分が単独メンテナーによって運営されている
    • ダウンロード数を10億回まで引き上げると多少の差はあるものの、それでも単独メンテナーのパッケージは存在する
  • NPM内の400万件の単独メンテナープロジェクトを運営している実際の人数は、約90万人である(つまり、一人が複数のプロジェクトを担う構造)

問題の本質: 国家ではなくリソース不足

  • オープンソースの経済規模は、数兆ドルに達する基盤である(Harvardの研究では8.8兆ドル)
  • 単独メンテナープロジェクトの大半は、リソース不足にあり、サプライチェーンリスクが存在する
  • 最大のリスクは国家ではなく、働きすぎで適切な補償を受けていない「一人のメンテナー」だ
  • メディアなどが個人メンテナーを標的にすることは、解決策ではない

結論とアクションポイント

  • 現在の問題の原因は単独メンテナーという構造にあり、国家に焦点を当てることには意味がない
  • 個人メンテナーを悪魔化したり特定したりすることは解決策ではない
  • この問題は複雑であり、即効性のある解決策は存在しない
  • 単独メンテナーを名指しで非難するのではなく、構造的な問題と支援策を考える必要がある

1件のコメント

 
GN⁺ 2025-08-29
Hacker Newsのコメント
  • ソフトウェアコミュニティでは、この問題について誤解が多いように感じる。実際には、サプライチェーンリスクはソフトウェアやエンジニアリングの問題というより、ガバナンスの問題だと思う。
    誰にも悪意がなくても、プロジェクトにサプライチェーンリスクは生じうるし、サプライチェーンリスクを評価する人ごとに、セキュリティの観点や基準は異なる。
    DoD(米国防総省)は一般の開発者とはまったく違う観点でリスクを見ており、多くの1人プロジェクトは、単に担当者が1人しかいないというだけでリスクになる。
    「バス係数」が1であること自体が、サプライチェーンリスクだ。
    ほとんどの人はパッケージを選ぶ際に戦争状態までは考えないが、軍は戦争を前提に考えることがありうる。
    戦争が起きれば、普段は自律的に運営されているオープンソースプロジェクトでも、状況が急激に変わる可能性がある。
    実際、多くの国では戦時に法律で民間企業や個人プロジェクトに協力を求められるため、こうした事態までセキュリティリスクとして計算する組織(DoDなど)がある。

    • みんなで声をそろえて言ってほしい。パッケージは必ずベンダリングしよう! ベンダリングしよう!
    • それなのに、「1人の開発者でもすぐに億万長者のソフトウェア企業を作れる」といった誇大宣伝が続いているのを見ると複雑な気持ちになる。
    • DoDであれば、そのパッケージのすべてのコードを一つ一つ読み、アップデートを固定し、必要なら自分たちでパッチを当てる準備ができていなければ、そもそも使わなかったと思う。
      戦時下で「まったく信頼していない別の1人でもいればよかったのに」などという運用はしないはずだ。
  • NPMには400万件の1人プロジェクトがあり、約90万人がそれらを管理している、というデータがあったが、これが本当に重要なポイントだったのか気になった。

    • 明示はされていなかったが、おそらくこういう意味だと思う。
      つまり、オープンソースの経済的価値(ハーバードは8.8兆ドルと推定)を生み出しているものの大半が「1人プロジェクト」であり、その誰も十分なリソース支援を受けていない。
      サプライチェーンリスクの話で本当に危険なのは、低賃金で過重労働の1人メンテナーだ。
      その人がどこの国にいるかは、実はそれほど重要ではないと思う。
  • 1人メンテナーが突然事故に遭ったり、プロジェクトをやめたりしたらどうなるのか、そうした統計があるのか気になる。
    これだけデータがあるなら研究する価値がありそうだ。
    新しい開発者がプロジェクトを引き継ぐのか、似た別プロジェクトに置き換えられるのか、それとも完全に消えてしまうのか知りたい。

    • ケースバイケースだ。
      実際には、バス事故よりも「管理者が興味を失う、または時間が足りなくなって手を引く」ケースのほうがずっと多い。
      こういう時によくあるシナリオは、
      1. 誰かがフォークし、最終的にそのフォークが元を置き換える場合
      2. 同じ役割を果たす新しいプロジェクトが人気を集め、既存プロジェクトを置き換える場合
      3. 元のメンテナーが別の人にプロジェクト管理を引き継ぐ場合
      4. 誰も管理しなくてもそのまま使われ続け、問題が起きたら各自がフォークして対処するが、それらのフォークが主要トレンドにはならない場合
        オープンソースの強みは、作者がいなくなったり、おかしくなったり、ライセンスを変えたりしても、誰かがフォークして守り続けられることだ。
        一方、商用ソフトウェアは、作者が企業であれ個人であれ、いなくなったり内容を変えたりしたらそれで終わりだ。
        せいぜい代替製品を探すしかない。
    • こうした人気のあるオープンソースのライブラリ/ツール/アプリ/サイトが、ある管理者から別の管理者へ移っていく過程を扱うエピソードシリーズがあれば、ぜひ見たい。
      だから自分はNetflixを運営していないのだろう。
    • 私の経験では、3つのケースすべてを実際に見たことがある。
      結局のところ、ユーザー数、コードベースの複雑さ、代替の有無によって変わる問題だ。
    • いちばん近い例としては Hans Reiser / Reiserfs を思い出す。
      単に「バスにはねられた」よりずっと奇妙な話で、結局そのプロジェクトは消滅した。
    • 人々が見落としがちなのは、コードがオープンソースである限り、時間はかかっても最悪の場合いつでもフォークできる、という点だ。
  • 2人以上で管理しているプロジェクトですら、実際のコミットの大半は結局1人が担っていることがほとんどだ。

  • 活動状況だけ確認していても、全プロジェクトの半分はメンテナーが0人だとすぐ分かったはずなのに、そこが惜しい。

    • ソフトウェアは一度「完成した」と感じられる段階に達すると、それ以上メンテナンスが不要な場合もある。
      掃除やチューニング、調整も必要なく、そのまま放っておいてよいという意味だ。
      むしろアップデートのほうが問題で、プロジェクト自体の問題ではないことも多い。
  • DoD が node を使っている事実のほうが心配だ。
    npm のようなプラットフォームは攻撃対象領域が大きすぎるという不安がある。

    • なぜそうなのかという疑問が湧く。
      DoD は世界最大級の組織のひとつなので、ニュースレター配信やボーイスカウト基地ツアー予約用の Web ページのような業務も多い。
      そういうところなら node を使っても問題ないと思う。
      こうしたシステムはミサイル発射のような主要システムとは別で運用されており、単にイベント申込ページが改ざんされても大きな問題にはならない。
    • DoD は規模があまりに大きいので、主要なプラットフォームはほぼ全部使っているはずだ。
  • 多くの1人 GitHub プロジェクトは、実際には "hello world" のような個人的実験や遊びにすぎないと思う。
    npm がどうかは分からないが、PyPI にも似たような例があふれている。
    実際に「browse projects」を押してみたら、こんなものが出てきた: https://pypi.org/project/helloworld-eduardo/
    どれだけ酔っていても、こんなものを製品に使おうと考える人はいないだろう。

  • DoD は、何かを無料で手に入れられるとなると、「これはみんなに利益がある」と全員を説得して、結局は有償で外注先に任せるのが非常にうまい。

    • トロイの木馬の話を思い出せば、無料であることが常に良いとは限らない、ということだ。
  • 「1人の管理者が10億回以上ダウンロードされたパッケージ」があると言っていたが、それが何を意味するのか気になった。

  • Linus という人が作った仕事について良い話をたくさん聞いてきたし、実際かなり使ってきた気がする。
    彼がロシアと国境を接する国の出身だという点まで気にすべきなのか、という疑問も湧く。
    オープンソース開発を数十年やってきたが、ほぼ1人でやるか、時々ボランティアのチームを組むかのどちらかだった。
    ボランティアチームで働いたことがある人なら分かると思うが、本当に簡単ではない。
    もちろん絶対に不可能ではないが、私たちが思うほど一般的にうまくいくわけでもない。
    うまくいく時は、たいてい「BDFL(慈悲深い独裁者)」がいるか、全員がひとつの目標に沿って動いている場合だった。
    私の場合は、ほぼ後者だった。

    • (オフトピック)Linus の両親も政治的に活動していて、Linus 自身も子どもの頃に共産主義少年団(スカウトに似た組織)で活動していたという。
      彼の父親はモスクワで数年間過ごしたこともある。
    • Linux は大規模なメンテナーと支援体制のあるプロジェクトで、Linus が1人で開発する単独プロジェクトとはまったく異なる。