Migrating an Ecosystem: An Empirical Study of How React Native Libraries Adopted the New Architecture
Diese empirische Studie analysiert die Migration des React-Native-Ökosystems auf seine neue Architektur und zeigt auf, dass zwar bedeutende Meilensteine die Einführung bei populären Bibliotheken beschleunigt haben, ein erheblicher Teil inaktiver, nicht migrierter Pakete jedoch weiterhin in Gebrauch ist, was zu einer fragmentierten Landschaft führt, in der Kompatibilitätsschichten zu einer langfristigen Infrastruktur geworden sind.
Originalarbeit lizenziert unter CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht vom Autor verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
In der Welt der Software sind Plattformen die Fundamente, auf denen unzählige Anwendungen aufgebaut werden. Ähnlich wie die Infrastruktur einer Stadt vorgibt, wie Gebäude errichtet werden, bieten diese digitalen Fundamente die wesentlichen Werkzeuge und Regeln, die es Entwicklern ermöglichen, mobile Apps zu erstellen. Gelegentlich müssen die Eigentümer dieser Plattformen ihre Kernsysteme ersetzen, um die Leistung zu verbessern oder neue Funktionen hinzuzufügen. Dies ist ein gewaltiges Unterfangen, nicht nur für die Plattform selbst, sondern auch für die tausenden unabhängigen Tools und Bibliotheken, die auf ihr beruhen. Wenn sich ein Fundament ändert, muss sich jede darauf errichtete Struktur schließlich anpassen, oder sie wird nicht mehr passen. Dies schafft eine komplexe Herausforderung: Wie reagiert ein riesiges, dezentrales Ökosystem aus unabhängigen Schöpfern, wenn der Boden unter ihnen nachgibt? Die Frage ist nicht nur technischer Natur; sie ist eine Studie über menschliche Koordination, Wartung und den Lebenszyklus digitaler Werkzeuge.
Eine aktuelle Studie des unabhängigen Forschers Revanth Krishna Maddula untersucht genau dieses Szenario innerhalb des React-Native-Ökosystems, eines populären Frameworks zum Bauen mobiler Anwendungen. React Native hat vor kurzem sein altes Kommunikationssystem, bekannt als „Bridge“, durch eine neue, schnellere Architektur ersetzt. Der Übergang geschah nicht unmittelbar; er vollzog sich in drei deutlichen Phasen über mehrere Jahre hinweg. Zuerst wurde das neue System als optionale Wahl angeboten. Dann wurde es zur Standardeinstellung, obwohl Entwickler immer noch zum alten System zurückwechseln konnten, wenn sie es wünschten. Schließlich wurde das alte System vollständig abgeschaltet, was die neue Architektur zur einzigen Option machte. Maddula setzte sich zum Ziel, zu messen, wie das Ökosystem auf diese Änderungen reagierte. Er betrachtete nicht nur die offiziellen Ankündigungen oder die populärsten Apps; er analysierte den gesamten Katalog von fast 2.800 Bibliotheken im Community-Verzeichnis und konzentrierte sich dabei speziell auf die 1.444 Bibliotheken, die nativen Code enthielten und daher umgeschrieben werden mussten, um mit dem neuen System zu funktionieren.
Die Ergebnisse zeichnen das Bild zweier sehr unterschiedlicher Gruppen, die sich in unterschiedlichem Tempo bewegen. Von den Bibliotheken, die nativen Code enthielten, haben etwa 62 Prozent erfolgreich auf die neue Architektur migriert. Diese erfolgreichen Bibliotheken sind die Schwerarbeiter des Ökosystems und machen 9、5 Prozent aller wöchentlichen Downloads aus. Das bedeutet, dass der Übergang für die große Mehrheit der Nutzer effektiv abgeschlossen ist. Es gibt jedoch einen signifikanten Ausläufer von 519 Bibliotheken, die nicht migriert sind. Dabei handelt es sich hauptsächlich um alte, inaktive Projekte, die seit Jahren nicht mehr aktualisiert wurden. Während sie einen kleineren Anteil am Gesamtnutzungsvolumen ausmachen, verzeichnen sie dennoch Millionen von Downloads pro Woche. Die Studie ergab, dass 115 dieser unmigrierten Bibliotheken mindestens 10.000 Downloads pro Woche erhalten und 41 von ihnen über 100.000. Dies sind keine obskuren Werkzeuge; sie umfassen weit verbreitete Komponenten für die Handhabung von Dateisystemen, Video, Zahlungen und Benachrichtigungen. Da so viele Anwendungen noch von ihnen abhängen, können die Plattformbesitzer das alte System nicht einfach entfernen, ohne einen großen Teil des Ökosystems zu beschädigen.
Das Timing dieser Migrationen erzählt eine spezifische Geschichte über Druck und Reaktion. Als die Plattform von einer optionalen Wahl zur Standardeinstellung und schließlich zu einer verbindlichen Anforderung wurde, stieg die Rate, mit der Bibliotheken aktualisiert wurden. Die Anzahl der Bibliotheken, die sich pro Monat konvertierten, stieg von einem langsamen Tröpfeln zu einem stetigen Strom an. Die Daten legen jedoch nahe, dass diese offiziellen Fristen die unmigrierten Bibliotheken nicht zur Änderung zwangen. Die Bibliotheken, die feststeckten, wurden nicht durch Zeitmangel oder mangelnde Warnungen zurückgehalten; sie wurden dadurch zurückgehalten, dass ihre Maintainer nicht mehr da waren. Die Studie fand heraus, dass der stärkste Prädiktor dafür, ob eine Bibliothek migrieren würde, schlicht die Frage war, ob sie noch aktiv aktualisiert wurde. Bibliotheken, die seit Jahren keine neue Version veröffentlicht hatten, würden wahrscheinlich nie migrieren, ungeachtet der Regeln der Plattform. Selbst unter den Bibliotheken, die noch aktiv gepflegt wurden, hatten weniger als die Hälfte innerhalb von zwei Jahren nach der Einführung des neuen Systems als Standard migriert.
Eine überraschende Entdeckung bezüglich der Art und Weise, wie diese Bibliotheken aktualisiert wurden, kam ans Licht. Die Plattformbesitzer hatten einen spezifischen, offiziellen Migrationspfad entworfen – eine Methode namens „Codegen“, die den notwendigen Code automatisch generiert. Dennoch folgte das Ökosystem nicht diesem einzelnen Pfad. Stattdessen fragmentierte das Migrationsziel. Fast die Hälfte der erfolgreich migrierten Bibliotheken entschied sich dafür, Drittanbieter-Frameworks zu nutzen, konkret Tools namens „Expo Modules“ und „Nitro Modules“, anstatt den offiziellen Weg zu gehen. Diese Drittanbieter-Tools boten einen einfacheren oder schnelleren Weg, das neue System zu bauen, und absorbierten so einen Großteil der Migrationsarbeit. Dies bedeutet, dass das Ökosystem nun ebenso sehr oder sogar mehr auf diese externen Frameworks angewiesen ist wie auf die eigenen offiziellen Tools der Plattform. Die Studie stellt fest, dass dies eine neue Ebene der Abhängigkeit schafft, bei der die Stabilität des gesamten Ökosystems nun teilweise auf diesen Intermediären ruht.
Die Forscher untersuchten auch, was die Schöpfer dieser unmigrierten Bibliotheken sagten. Sie fanden heraus, dass sehr wenige von ihnen, weniger als einer von zehn, eine Stellungnahme in ihrer Dokumentation über die neue Architektur oder ihren eigenen Wartungsstatus abgegeben hatten. Die meisten sagten gar nichts. Unter denen, die sprachen, war die Botschaft oft eine der Aufgabe. Einige Bibliotheken wurden explizit als „deprecated“ (veraltet) markiert, während andere archiviert wurden oder als suchend nach neuen Maintainern gelistet waren. Eine kleine Anzahl von Bibliotheken behauptete, das neue System zu unterstützen, doch ein genauerer Blick auf ihren Code zeigte, dass sie immer noch auf dem alten System liefen und eine Kompatibilitätsschicht nutzten, um zu funktionieren. Diese Schicht fungiert als Übersetzer, der es altem Code ermöglicht, auf dem neuen System zu laufen, ist aber keine dauerhafte Lösung. Die Studie legt nahe, dass diese Kompatibilitätsschicht für einen großen Teil des Ökosystems von einer temporären Brücke zu einem permanenten Ziel geworden ist.
Die Implikationen dieser Erkenntnisse sind klar für jeden, der auf dieser Plattform baut. Das offizielle Label „unterstützt“ (supported) auf einer Bibliothek garantiert nicht, dass sie vollständig aktualisiert wurde; es kann lediglich bedeuten, dass die Bibliothek über eine Kompatibilitätsschicht funktioniert. Für Entwickler bedeutet dies, dass die Überprüfung des Status einer Bibliothek tieferen Blick erfordert, als nur die oberflächlichen Deklarationen. Die Studie hebt hervor, dass die gefährlichsten Abhängigkeiten oft die inaktiven mit hohen Downloadzahlen sind, da sie am wahrscheinlichsten Probleme verursachen werden, falls die Kompatibilitätsschichten irgendwann entfernt werden. Für die Plattformbesitzer ist die Lektion, dass das Setzen einer Frist gut funktioniert, wenn es aktive Maintainer gibt, aber für den inaktiven Ausläufer des Ökosystems nichts bewirkt. Die Studie kommt zu dem Schluss, dass Kompatibilitätsschichten als langfristige Infrastruktur geplant werden müssen und dass die Plattform mit den Drittanbieter-Frameworks interagieren muss, die für den Migrationsprozess essenziell geworden sind. Der Übergang ist kein einzelnes Ereignis, das man als abgeschlossen erklären kann; es ist ein fortlaufender Prozess, in dem das Ökosystem seinen eigenen, fragmentierten Weg gefunden hat.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.