【ITニュース解説】I Wanted to Pay My Dependencies. Only One of Three Registries Would Let Me Find Out Who to Pay.

オープンソースソフトウェア（OSS）は、現代のソフトウェア開発において非常に重要な役割を果たしている。多くのシステムエンジニアが日々開発しているシステムも、無数のOSSパッケージという部品を組み合わせて作られている。これらのパッケージは、多くの場合、個人や小規模なチームがボランティアとして開発や保守を行っている。しかし、彼らが持続的に活動していくためには、資金的な支援が不可欠である。このニュース記事は、そうしたOSSのメンテナー（保守管理者）に対し、金銭的な支援を行う方法を、ソフトウェアの部品が登録されている「パッケージレジストリ」という場所から、プログラムを使って自動的に探し出せるかを検証した調査について解説している。

著者は、npm（Node.jsのパッケージ）、PyPI（Pythonのパッケージ）、crates.io（Rustのパッケージ）という、それぞれのプログラミング言語で広く利用されている主要な3つのパッケージレジストリを調査対象とした。GitHub SponsorsやOpen Collectiveなど、OSSプロジェクトのスポンサーシップ（資金援助）の仕組みが普及し、「プロジェクトを支援してください」というメッセージもよく見かけるようになったことから、レジストリが提供する公開API（プログラムが外部のサービスとやり取りするための窓口のようなもの）を使えば、寄付に関する情報を簡単に取得できるだろうと、当初は考えていた。しかし、この調査の結果、彼の予想は裏切られることになる。3つのレジストリは、寄付に関する情報、つまり「資金調達データ」の扱い方について、それぞれ全く異なるアプローチを取っており、統一された形で情報を提供している場所はほとんど見つからなかったのである。

まず、npmについて見てみよう。npmのパッケージの設定ファイルであるpackage.jsonには、fundingという専用のキーが存在する。これは単なる慣習的な記述ではなく、正式な仕様（RFC）として定義され、実装されたフィールドである。また、npm fundというコマンドを使えば、あなたのプロジェクトが利用しているすべての依存パッケージ（そのプロジェクトが機能するために必要な他のパッケージ）について、このfundingフィールドの内容を自動的に読み取ることができる。著者が有名な25のパッケージを調査したところ、9つ（36%）がこのfundingフィールドに情報を記載していた。しかし、問題は、このフィールドのデータ形式が一貫していない点にあった。「express」というパッケージは、寄付先のURLとその種類（例：Open Collective）をまとめたオブジェクト形式で情報を提供していたが、「eslint」はURLが単なる文字列として記述されており、「uuid」というパッケージは、複数のメンテナーのためにGitHub SponsorsのURLを2つ、配列形式で提供していた。このため、もしプログラムでこの情報を利用しようとすると、データがどのような型（文字列なのか、オブジェクトなのか、配列なのか）で提供されているかを事前に確認し、それぞれの形式に対応する処理を書く必要が生じる。さらに、「react」や「vue」、「typescript」といった、大企業や財団に支援されている主要なパッケージの多くは、そもそもこのfundingフィールドを全く利用していなかった。これは、これらの大規模なプロジェクトが、package.jsonの枠組みに限定されない、より大規模な資金調達の仕組みを持っているためと考えられる。

次に、PyPIについてである。PyPIには、npmのように「寄付」専用の明確なfundingフィールドは存在しない。その代わりに、メンテナーが手動で自由に記述できるproject_urlsという項目がある。このproject_urlsは、プロジェクトのドキュメント、ホームページ、ソースコードリポジトリなどのURLを記載するために使われる汎用的な場所である。PyPI自体やパッケージマネージャーであるpipは、このproject_urlsの中から特定の「寄付」に関連する情報を自動的に見つけ出すような仕組みは持っていない。著者が調査した結果、「django」というパッケージはFundingというキーを使って寄付先のURLを記載していたが、「flask」や「click」はDonateという異なるキーを使っていた。著者は、Funding、Donateに加えてsponsor、supportといった寄付に関連しそうなキーワードを使って検索を行った結果、調査した20のパッケージ中8つで何らかの寄付情報を発見できた。しかし、これは人間が特定のキーワードを使って探す「ヒューリスティック」（経験則に基づく探索）な方法であり、厳密なスキーマ（データの構造定義）に基づくクエリではない。そのため、もしメンテナーが「Support Us」や「Ko-fi」といった、著者が想定しなかった異なる表現を使っていた場合、それらの情報は検出から漏れてしまう。つまり、「寄付情報が記載されているのに見つけられなかったケース」と、「そもそも寄付情報が記載されていないケース」とを区別することが困難であった。

最後に、crates.ioについてである。Rust言語のパッケージレジストリであるcrates.ioは、寄付情報の取得において最も困難な状況を示した。Rustのパッケージマネージャーであるcargoが、依存関係を解決する際に参照する「sparse index」という軽量なインデックス形式には、パッケージのホームページやソースコードリポジトリのURLといった、比較的基本的な情報ですら含まれていない。当然のことながら、寄付に関する情報は一切提供されていない。このインデックスには、パッケージの名前、バージョン、依存関係、チェックサムなど、ごく限られた最低限の情報しか格納されていないのだ。寄付に関するメタデータ自体は、crates.ioが提供する別のREST API（Webサービスとやり取りするための別の窓口）には存在する。しかし、これはcargoが通常利用するエンドポイントとは異なるため、多くのツールはそこから情報を取得しない。結果として、現状ではcrates.ioから直接、プログラム的に寄付に関する情報を取得することは非常に難しいことが判明した。

さらに、GitHubが提供している「Sponsor」ボタンと、npmのfundingフィールドの間にも、情報の不一致が見られた。GitHubのリポジトリページに表示される「Sponsor」ボタンは、.github/FUNDING.ymlという特定の設定ファイルの内容に基づいて表示される。しかし、npmのpackage.jsonでGitHub SponsorsのURLが宣言されているにもかかわらず、対応する.github/FUNDING.ymlファイルがリポジトリ内に存在しないケースがあった。「chalk」というパッケージがその一例である。これは、同じプロジェクトであっても、異なる情報提供チャネルが存在し、それらの情報が必ずしも同期しているわけではないという、別の種類の問題を示している。

著者は、今回の調査にはいくつかの限界があることも自ら指摘している。例えば、調査対象としたのは主に知名度の高い「有名パッケージ」であり、これらは財団や企業からの支援を受けていることが多いため、真に資金援助が必要な、小規模で個人がメンテナンスしているような「長期間維持されているが目立たない依存パッケージ」の実態を正確に反映しているとは限らない。PyPIでのキーワードマッチングによる調査は、メンテナーが選んだ言葉によっては、情報を見落とす（過小評価）可能性もあれば、無関係な情報を拾ってしまう（過大評価）可能性もある。また、今回の調査では、寄付へのリンクが存在するかどうかは確認したが、そのリンクが現在も有効か、実際にプロジェクトが利益を得ているか、あるいは利用者がそのリンクを実際にクリックして支援を行っているかといった、より実用的な側面については検証されていない。彼が本当に重要だと考えているのは、現代のソフトウェアの「サプライチェーン」の奥深くに埋もれている、普段は誰も意識しないような小規模な依存パッケージの持続可能性である。しかし、そうしたパッケージこそ、寄付情報を探し出すことが最も困難な対象となっているのが現状なのだ。

この調査結果は、もしあなたがオープンソースソフトウェアのメンテナーであれば、package.jsonのfundingフィールド、PyPIのproject_urls、あるいはGitHubの.github/FUNDING.ymlといった場所に、寄付に関する情報を明確に、かつ一貫性のある形式で記載することの重要性を示唆している。そして、もしあなたがシステムエンジニアを目指す初心者であり、日々の開発でオープンソースソフトウェアを利用しているのであれば、これらの情報を実際に活用し、依存するプロジェクトを支援しているか、あるいは単に情報として存在しているだけで、見過ごしてしまっているかを問いかけるものとなっている。オープンソースソフトウェアが持続的に発展していくためには、こうした情報の提供と利用の双方が、より効果的に機能していく必要があるだろう。