Migrating an Ecosystem: An Empirical Study of How React Native Libraries Adopted the New Architecture
この実証研究は、React Nativeのエコシステムにおける新アーキテクチャへの移行を分析しており、主要なマイルストーンが人気のあるライブラリの間での採用を加速させた一方で、休眠状態にある未移行のパッケージがかなりの割合で依然として使用されており、互換性レイヤーが長期的なインフラストラクチャとなっている断片化された状況を招いていることを明らかにしている。
原論文は CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
ソフトウェアの世界において、プラットフォームは数え切れないほどのアプリケーションが構築される基礎となります。都市のインフラが建物の構造を規定するのと同様に、これらのデジタルな基礎は、開発者がモバイルアプリを作成するための不可欠なツールとルールを提供します。時として、これらのプラットフォームの所有者は、パフォーマンスの向上や新機能の追加のために、その中核となるシステムを置き換えなければならないことがあります。これは、プラットフォーム自体にとっても、そこに依存している何千もの独立したツールやライブラリにと로しても、極めて大規模な事業です。基礎が変われば、その上に築かれたすべての構造物は、最終的に適応するか、あるいは適合しなくなるかのどちらかを選択しなければなりません。これは、広大で分散化された独立したクリエイターのエコシステムが、足元の地面が動いたときにどのように反応するかという、複雑な課題を生み出します。この問いは単なる技術的な問題ではなく、人間の調整、メンテナンス、そしてデジタルツールのライフサイクルに関する研究なのです。
独立系研究者のRevanth Krishna Maddulaによる最近の研究は、まさにこのシナリオを、モバイルアプリケーション構築のための人気フレームワークであるReact Nativeのエコシステム内で検証しています。React Nativeは最近、「ブリッジ」として知られる旧来の通信システムを、より高速な新しいアーキテクチャへと置き換えました。この移行は即座に行われたわけではなく、数年にわたって3つの明確な段階を経て行われました。まず、新しいシステムがオプションの選択肢として提供されました。次に、それが標準設定となりましたが、開発者は依然として旧システムに切り替えることが可能でした。最後に、旧システムが完全にオフになり、新しいアーキテクチャが唯一の選択肢となりました。Maddulaは、この変化に対してエコシステムがどのように反応したかを測定することを目的としました。彼は公式のアナウンスや最も人気のあるアプリだけを見たのではありません。コミュニティディレクトリにリストされている約2,800のライブラリの全カタログを分析し、特に新しいシステムに合わせて書き換える必要があったネイティブコードを含む1,444のライブラリに焦点を当てました。
結果は、非常に異なる2つのグループが異なる速度で動いているという物語を明らかにしています。ネイティブコードを含むライブラリのうち、約62パーセントが新しいアーキテクチャへの移行に成功しています。これらの成功したライブラリは、エコシステムの「重労働を担う者」であり、全週間ダウンロード数の95パーセントを占めています。これは、大多数のユーザーにとって、移行が事実上完了していることを意味します。しかし、移行していない519のライブラリという、かなりの「長い尾（テール）」が存在します。これらは主に、数年間更新されていない古い、あるいは休止状態のプロジェクトです。これらは総使用量に占める割合は小さいものの、毎週数百万回のダウンロードを受けています。研究によると、これら未移行のライブラリのうち115個は週に少なくとも1万回のダウンロードがあり、41個は10万回以上のダウンロードがあります。これらは無名のツールではありません。ファイルシステム、ビデオ、決済、通知などを扱うために広く使用されているコンポーネントが含まれています。これほど多くのアプリケーションが依然としてこれらに依存しているため、プラットフォームの所有者は、エコシステムの大部分を壊すことなく、旧システムを単純に削除することができないのです。
これらの移行のタイミングは、圧力と反応に関する特定の物語を伝えています。プラットフォームがオプションの選択肢からデフォルト設定へ、そして最終的に必須要件へと移行するにつれて、ライブラリが更新される割合は増加しました。毎月の変換ライブラリ数は、緩やかな滴りから安定した流れへと増えていきました。しかし、データは、これらの公式の期限が未移行のライブラリの変化を強制できなかったことを示唆しています。取り残されたライブラリは、時間の不足や警告の不足によって停滞したのではなく、そのメンテナーがいなくなったために停滞していました。研究によれば、ライブラリが移行するかどうかを予測する最も強力な要因は、単にそれがまだ更新されているかどうかでした。数年間新しいバージョンをリリースしていないライブラリは、プラットフォームのルールに関わらず、移行する可能性が低いのです。現在も活発にメンテナンスされているライブラリの間でさえ、新しいシステムがデフォルトになってから2年以内に移行したのは半分以下でした。
これらのライブラリがどのように更新されたかに関して、驚くべき発見がありました。プラットフォームの所有者は、必要なコードを自動生成する「Codegen」と呼ばれる、特定の公式な移行パスを設計しました。しかし、エコシステムはこの単一のパスには従いませんでした。代わりに、移行先が断片化しました。移行に成功したライブラリのほぼ半分は、公式のルートではなく、「Expo Modules」や「Nitro Modules」と呼ばれるサードパーティのフレームワークを使用することを選択しました。これらのサードパーティ製ツールは、新しいシステムを構築するためのより簡単または高速な方法を提供し、移行作業の多くを実質的に吸収しました。これは、エコシステムが、プラットフォーム自身の公式ツールと同等、あるいはそれ以上に、これらの外部フレームワークに依存していることを意味します。研究は、このことが新たな依存レイヤーを生み出し、エコシステム全体の安定性が、今やこれらの仲介者に部分的に依存していることを指摘しています。
研究者たちは、未移行のライブラリの作成者たちが何を言っているのかについても調査しました。彼らは、新しいアーキテクチャや自身のメンテナンス状況について、ドキュメントに記述を残していたのは、10件に1件未満という極めて少ない数であることを発見しました。ほとんどは何も述べていませんでした。記述を行っていた者の間でも、メッセージはしばしば「放棄」を示すものでした。一部のライブラリは明示的に非推奨（deprecated）とマークされており、他のものはアーカイブされたり、新しいメンテナーを探していると記載されたりしていました。少数のライブラリは新しいシステムをサポートしていると主張していましたが、コードを詳しく調べると、依然として旧システム上で動作しており、互換レイヤーに依存していることが分かりました。このレイヤーは翻訳機のように機能し、古いコードを新しいシステム上で動作させますが、それは永続的な解決策ではありません。研究は、エコシステムの大部分にとって、この互換レイヤーが一時的な架け橋ではなく、永続的な目的地になってしまっていることを示唆しています。
これらの発見が持つ意味は、このプラットフォーム上で構築を行うすべての人にとって明白です。ライブラリに付与された公式の「サポート済み」というラベルは、それが完全に更新されていることを保証するものではありません。それは単に、ライブラリが互換レイヤーを通じて動作していることを意味している可能性があります。開発者にとって、これはライブラリの状態を確認するには、表面的な宣言よりも深く掘り下げる必要があることを意味します。研究は、最も危険な依存関係は、ダウンロード数が多い休止状態の依存関係であると強調しています。なぜなら、それらは互換レイヤーが最終的に削除された場合に問題を引き起こす可能性が最も高いからです。プラットフォームの所有者にとっての教訓は、期限を設定することはアクティブなメンテナーには効果的ですが、エコシステムの「長い尾」の部分には何の効果もないということです。研究は、互換レイヤーは長期的なインフラとして計画されるべきであり、プラットフォームは移行プロセスに不可欠となったサードパーティのフレームワークと関わりを持つ必要があると結論付けています。移行は、完了したと宣言できる単一のイベントではなく、エコシステムが独自の断片化された方法を見出した継続的なプロセスなのです。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。