Übernommen heißt nicht erledigt— woran du erkennst, ob ein Software-Fundament trägt

Wer eine Website, ein Portal oder ein KI-System betreibt, baut auf Software, die andere pflegen. Das ist kein Makel, sondern der Grund, warum moderne Projekte in Wochen statt Jahren fertig werden. Der Preis dafür ist eine Abhängigkeit, die man selten prüft: Wenn der Unterbau stehen bleibt, steht irgendwann auch das eigene System. Und die Frage, woran man das früh erkennt, wird üblicherweise mit Bauchgefühl beantwortet — „die Firma wurde gekauft, das wird nichts mehr".

Die beiden Fälle, an denen sich das gerade durchrechnen lässt, sind Astro und Gatsby. Beide sind Web-Frameworks, beide waren beliebt, beide gehören heute einem Konzern. Nur läuft das eine Projekt schneller als je zuvor und das andere praktisch nicht mehr.

Was messbar ist

Alle Zahlen unten haben wir am 11. September 2026 selbst erhoben — über die GitHub-API und mit einem frischen Paket-Install in einem leeren Verzeichnis. Sie sind damit nachprüfbar und veralten planbar.

Die wichtigste Zeile ist nicht die mit den Schwachstellen, sondern die mit dem Zeitraum. Astro braucht 19 Tage für 100 Commits, Gatsby siebeneinhalb Monate — bei zwölffach höherem Bot-Anteil. Ein Projekt, das nur noch automatische Dependency-Updates bekommt, ist nicht tot. Es ist im Wartungsmodus, und zwar in einem, den niemand angekündigt hat.

Der Unterschied ist nicht die Übernahme

Der naheliegende Schluss wäre: Konzern kauft Open Source, Open Source stirbt. Er ist falsch, und die Gegenprobe ist einfach. Svelte und Nuxt gehören zu Vercel. Meteor gehört seit Jahren zu Tiny. Ember wurde nie übernommen. Alle vier haben in den letzten sechs Wochen ein Release veröffentlicht: Svelte am 28. August 2026, Nuxt am 5. August, Meteor am 8. September, Ember am 10. August. Kein Muster.

Was Gatsby von diesen Fällen unterscheidet, ist die Rolle des Projekts im Deal. Netlify kaufte ein Unternehmen, dessen kommerzielles Produkt eine Hosting-Plattform war — das Framework war der Trichter dorthin. Nach der Übernahme brauchte der Käufer den Trichter nicht mehr, weil er die Plattform selbst betrieb. Bei Cloudflare und Astro ist die Lage umgekehrt: Cloudflare verkauft Infrastruktur und braucht ein Framework, das auf dieser Infrastruktur hervorragend läuft. Das Projekt ist hier der Zweck, nicht das Nebenprodukt.

Diesen Unterschied kann man nicht nur vermuten, sondern nachlesen. Cloudflare hat im Beitrag vom 16. Januar 2026 vier Dinge schriftlich zugesagt: „Astro stays open-source and MIT-licensed", „Astro's open governance and current roadmap remain in place", „Astro continues to support a wide set of deployment targets, not just Cloudflare" und „All full-time employees of The Astro Technology Company are now employees of Cloudflare, and will continue to work on Astro full-time". Das sind prüfbare Zusagen, keine Absichtserklärungen — und die Zahlen aus der Tabelle deuten darauf hin, dass sie bisher eingehalten werden.

So weit die naheliegende Erklärung — und hier ist der Punkt, an dem man sie ehrlich begrenzen muss. Sie ist eine Heuristik, kein Gesetz. Svelte hat gar keine formale Governance-Struktur, nur einen Blogsatz des Eigentümers, und ist trotzdem der gesündeste Fall im Feld. Meteor war das Kaufobjekt und hat bezahlte Vollzeitkräfte, ist aber schmaler aufgestellt als Ember — das keinen Käufer, kein kommerzielles Produkt und ein Spendenbudget im dreistelligen Bereich pro Monat hat und trotzdem im Sechs-Wochen-Takt veröffentlicht. Wer die Frage nach dem Kaufobjekt für die ganze Antwort hält, liegt in drei von fünf Fällen daneben.

Der Test, den du selbst machen kannst

Es gibt eine Kennzahl, die über alle sechs Projekte hinweg mit dem Zustand läuft — und sie hat nichts mit Eigentümern zu tun: wie viele verschiedene Menschen in welchem Zeitraum am Projekt arbeiten. Dieselbe Messung wie oben, auf die Vergleichsprojekte angewendet:

Fünf der sechs Projekte liefern ihre letzten 100 Commits in 11 bis 42 Tagen, bei 8 bis 43 beteiligten Personen. Gatsby braucht dafür siebeneinhalb Monate. Das ist der Ausreißer — und er ist unabhängig davon sichtbar, wem das Projekt gehört, wer es finanziert und was in der Ankündigung stand. Zwei Abfragen auf GitHub, zehn Minuten, kein Berater nötig.

Die Fragen, die du stellen solltest

Für jedes Fundament, auf dem ein wichtiger Prozess läuft — Framework, CMS, ERP-Modul, KI-Anbieter. Die erste ist die belastbarste, weil sie sich messen lässt statt interpretieren:

• Wie breit ist die Basis? Wie viele verschiedene Menschen haben in den letzten Wochen am Projekt gearbeitet, und wie lang ist der Zeitraum der letzten hundert Änderungen? Diese Frage beantwortet sich mit zwei GitHub-Abfragen — und sie hat in unserem Vergleich als einzige zuverlässig zwischen gesund und stehengeblieben unterschieden.
• Ist das Projekt das Produkt? Wenn der Eigentümer sein Geld mit etwas anderem verdient und das Projekt nur der Vertriebsweg dorthin war, ist es beim nächsten Strategiewechsel als erstes dran.
• Wer bezahlt die Vollzeitstellen? Ein Projekt, das von Freiwilligen in der Freizeit getragen wird, kann jahrelang gut laufen — aber es hat keinen Puffer, wenn zwei Leute aufhören.
• Steht die Governance schriftlich? „Wir bleiben offen" in einem Blogpost ist schwächer als eine Lizenz und ein dokumentierter Entscheidungsprozess, aber stärker als gar nichts. Prüfe, was zugesagt ist und was nur gesagt wurde.
• Wie lang ist das Supportfenster? Nicht „gibt es Updates", sondern: für wie viele Versionen zurück, und wie lange. Bei Astro sind es Sicherheitsupdates für genau eine vorherige Major — bei einem Major-Takt von zuletzt 104 Tagen heißt das wenig Zeit.
• Wie sieht der Ausstieg aus? Nicht ob du wechseln willst, sondern was es kostet. Wenn die Antwort „Neubau" lautet, ist das keine Abhängigkeit mehr, sondern eine Bindung.

Was der Wechsel real kostet — unser eigener Fall

Wir reden hier nicht theoretisch. Diese Website läuft selbst auf Astro, und wir sind vergangene Woche von Version 5 auf Version 7 gesprungen — zwei Majors auf einmal, 165 Seiten in drei Sprachen. Aufwand: rund ein halber Arbeitstag, davon der größere Teil Qualitätssicherung. Der Grund für den Sprung war nicht ein Feature, sondern dass Astro 5 und 6 keine Pflege mehr bekommen: Der 6er-Zweig hat seit dem 17. Juni 2026 keinen Release mehr gesehen.

Dabei ist uns etwas aufgefallen, das kein Changelog erwähnt. Astro 7 bringt eine neue Bundler-Generation mit, die CSS anders minifiziert und dabei das angenommene Mindest-Browser-Ziel anhebt. Ergebnis im Build: 1.713 Media Queries in einer Schreibweise, die Safari und iOS unter Version 16.4 komplett ignorieren — das Responsive-Layout wäre auf älteren iPhones ausgefallen, ohne Fehlermeldung. Eine Konfigurationszeile stellt das zurück. Gefunden haben wir es nur, weil wir den alten und den neuen Build Zeile für Zeile verglichen haben, statt auf „Build erfolgreich" zu vertrauen.

Das ist die eigentliche Lehre für Entscheider: Ein Major-Upgrade ist selten teuer, wenn man es rechtzeitig macht. Teuer wird es, wenn man drei Majors überspringt und dann unter Zeitdruck springen muss — oder wenn niemand den Build kontrolliert und der Schaden erst über Support-Tickets zurückkommt.

Dasselbe Muster bei KI-Anbietern

Die fünf Fragen sind nicht auf Frameworks beschränkt. Bei KI-Anbietern sind sie dringlicher, weil der Ausstieg schwerer ist: Ein Framework kannst du einfrieren und jahrelang weiterbetreiben, ein abgeschaltetes Modell nicht. Wie schnell aus einem Partner ein Wettbewerber wird, haben wir am Fall Figma/Anthropic beschrieben — nachzulesen unter Plattformrisiko und die Figma-Lektion. Und wann sich Eigenbetrieb gegenüber Einkauf rechnet, steht im Build-vs-Buy-Leitfaden.

Der gemeinsame Nenner: Abhängigkeit ist unvermeidbar, Bindung nicht. Wer beim Bauen darauf achtet, dass der Code ihm gehört und die austauschbaren Teile austauschbar bleiben, kann einen Anbieterwechsel als Projekt behandeln statt als Krise. Mehr dazu unter Souveräne KI für den Mittelstand.

Häufige Fragen: Software-Fundamente prüfen