Beim Thema Bus und Bahn sieht es in Deutschland aktuell nicht gut aus. In vielen Städten brechen die Systeme zusammen. Mal gibt es mehr, mal weniger Ausfälle. Die Tendenz ist aber klar: Es wird nicht besser und ein Ende ist noch nicht in Sicht. Und es ist nicht nur der Nahverkehr (ÖPNV), sondern auch der Fernverkehr, den viele Menschen mittlerweile auch zum Pendeln nutzen.

Wir fahren nach Berlin

Die Ausfälle und Unzuverlässigkeiten sind dabei vielfältig. In Berlin kämpfen etwa die U-Bahn der BVG und die S-Bahn der Deutschen Bahn mit zahlreichen Pannen. Bei der U-Bahn zeigen sich die enormen Auswirkungen der Sparmaßnahmen der letzten Jahrzehnte. Neue Fahrzeuge wurden kaum bestellt. Erst in diesem Jahr werden neue U-Bahnen der Baureihe JK in den Fahrgastbetrieb gebracht.

Die alten U-Bahnen werden zudem wohl auch nicht mehr lange durchhalten. Sie sind in einem dermaßen schlechten Zustand, dass es immer wieder Ausfälle gibt. Als Fahrgast bemerkt man das vor allem an den Türstörungen. Ein rotes Licht oder ein Aufkleber verweisen darauf, dass die Tür nicht funktioniert. Das ist ein Problem, welches man in anderen Ländern so gut wie nie sieht.

Türstörungen? Gibt es anderswo fast nicht.

Zum Beispiel in Südostasien. Hier sind oft sogenannte „Platform Screen Doors“ am Bahnsteig im Einsatz. Es müssen also immer zwei Türpaare sehr zuverlässig arbeiten. Doch ausfallende Türen sind auch in Europa oder den USA kaum zu entdecken – inklusive Länder, die verstärkt mit einem Bahnsteigschutz arbeiten. Türen in Eisenbahnfahrzeugen sind hochgradig zuverlässige Hardware.

Auch Länder, die grundsätzlich mit altem Wagenmaterial herumfahren, haben anscheinend kein Problem mit den Garnituren. In Japan fahren viele alte Züge in einem gepflegten Zustand herum. Polens und Tschechiens Straßenbahnen sind ein wahrer Zoo aus Baureihen unterschiedlichster Generationen. In Nordkorea sind bis heute die sogenannten Stahldoras (BVG-Baureihe D) aus Berlin auf der Schiene.

So altes Material ist wartungsintensiv. Und da wird in Deutschland hingegen sehr viel und sehr gerne Geld gespart. Ein Einsatz in Berlin wäre daher kaum denkbar, da auch die Werkstätten mittlerweile unter hausgemachtem Personalmangel leiden. Wenn die Werkstätten an ihren Kapazitäten sind, wird schlimmstenfalls mit verkürzten Zügen im Berufsverkehr gefahren. Kommt dann noch ein Mangel an Fahrpersonal dazu, dann kommt halt nur jeder dritte oder vierte Zug.

Die Personaldecke ist so dünn, dass die U-Bahn-Linie U4 im Berufsverkehr nur noch 25 Prozent ihrer Fahrten bieten kann. Immerhin sind die Züge dann doppelt so lang. Die U-Bahn-Linie U1 wird bisweilen sogar auf drei Stationen verkürzt, statt nach Kreuzberg zu fahren. All das sorgt für vollere Züge und mehr Empfindlichkeit auf Verspätungen, die Folgeverspätungen auslösen.

Digitale Infosysteme versagen

Wenn die Situation so schlecht ist, dann ist eigentlich eine einwandfreie Kommunikation essentiell für die Fahrgäste. Doch hier hapert es in Deutschland erheblich und auch hier muss Berlin als Paradebeispiel herhalten, wie man es nicht macht. Denn die Systeme sind eigentlich für einen zuverlässigen Nahverkehr konzipiert. Nur im Ausnahmefall sollen sie Störungen melden und Hinweise liefern.

In Berlin ist das ein manueller Prozess. Fällt ein Zug aus, dann muss ihn jemand von Hand aus dem digitalen Informationssystemen entfernen. Man kennt es oft: Zwei Züge sollen angeblich gleichzeitig vom Bahnsteig in die gleiche Richtung abfahren. Es kommen aber nicht etwa zwei Züge gekoppelt an. Stattdessen stauen sich die Züge virtuell.

Das wurde zeitweise so schlimm, dass im September 2024 die BVG nach langer Kritik einen provisorischen Arbeitsplatz eingerichtet hat, der die Fahrgastinformationen bereinigt, die im Echtzeitsystem nur noch virtuell durch das Netz fuhren. Sie werden dann gelöscht. Apps oder Kartendienste mit Echtzeitangaben profitieren davon auch, da dort ebenfalls die virtuellen Züge verschwinden.

Nahverkehr am Limit

Die Problematik digitaler Anzeigen sieht man auch bei der Deutschen Bahn bundesweit. Wer sich mit Gleisplänen, Umlaufzeiten und Zugabständen auskennt, wundert sich manchmal, welcher Mumpitz auf den Anzeigen steht. Bei Störungen sieht die Lage dann sehr schlimm aus. Hier kommt bei einigen Bahnhöfen noch die Verquickung von Nah- und Fernverkehr dazu.

Bei Großstörungen werden die Anzeigen schnell nutzlos. Mitte Juli gab es etwa eine Oberleitungsstörung in Frankfurt (Main) Süd. Frankfurt Süd ist – bedingt durch Bauarbeiten im S-Bahn-Tunnel Offenbach – ohnehin an seiner Kapazitätsgrenze. Als dann aber am 15. Juli gegen Abend noch eine Oberleitungsstörung dazu kam, brach fast das gesamte Anzeigesystem zusammen und der DB Navigator war weitestgehend nutzlos. Durchsagen, welche die Situation hätten erklären können, gab es ebenfalls keine.

Man konnte in Echtzeit beobachten, dass dort das Personal einer extremen Arbeitsbelastung ausgesetzt war. Es durfte die Versäumnisse von Politik und Deutsche Bahn ausbaden und war gleichzeitig dem Zorn der Fahrgäste schutzlos ausgesetzt. Das Einzige, was in Frankfurt an diesem Tag noch halbwegs funktionierte, war der S-Bahn-Verkehr vom Kopfbahnhof sowie die separate S-Bahn-Infrastruktur im Tiefbahnhof.

Hier gibt es sogar regulär keine Ansagen zu den vielen Fahrplanänderungen. Die Deutsche Bahn verweist auf die Apps und die Aushänge, wie uns das Unternehmen mitteilte. Das ist insbesondere beim Verkehr zum Flughafen problematisch. Für Touristen und Geschäftsleute sind die Apps und Änderungsfahrpläne nämlich eine große Herausforderung. Der Änderungsfahrplan vom 3. August 2025 für Bonn Hbf hat beispielsweise 30 Seiten, der reguläre 25.

Die Besucher, die etwa in Verbindungen mit den vielen südkoreanischen Unternehmen in Frankfurt am Main ankommen oder abfliegen, sind unzuverlässige Flughafenverbindungen nämlich nicht gewohnt. Ihnen fehlt das Training für die Deutsche Bahn. Sie wissen auch nicht, dass Flughafen-S-Bahnen baubedingt teilweise in einem Abstand von drei Minuten aus Gleis 103 (S9, Unten) und 21 (S8, Oben) abfahren können.

Als das KI-Modell Grok Anfang Juli antisemitische Einträge verbreitet, Adolf Hitler verteidigt, den Holocaust gelobt und sich als „MechaHitler“ bezeichnet hat, hat das dem KI-Unternehmen xAI von Elon Musk offenbar einen wichtigen Vertrag mit der US-Regierung gekostet. Das jedenfalls legen interne Dokumente nahe, berichtet das US-Magazin Wired. Demnach sollte xAI zusammen mit anderen führenden KI-Firmen aus den USA eine Partnerschaft mit der Regierung eingehen, in deren Rahmen Staatsbedienstete Zugänge erhalten sollten. Das habe sich abrupt geändert und letztlich gehörte xAI nicht zu den Firmen, die jetzt mit der General Services Administration (GSA) kooperieren. Dabei war Elon Musk bis vor Monaten außergewöhnlich eng in die Regierungsarbeit involviert.

Partnerschaften mit KI-Firmen – außer xAI

Wie Wired erläutert, geht es um einen Vertrag zwischen der GSA und KI-Firmen. Die GSA ist für die Versorgung der US-Regierung mit Büros und Büromaterial, Telekommunikationsausstattung und Transportkapazitäten zuständig. Vorige Woche hat die Behörde angekündigt, dass sie mit OpenAI vereinbart hat, dass US-Bundesbehörden für ihre Angestellten Zugriff auf ChatGPT Enterprise bekommen, und zwar zum Sonderpreis von einem US-Dollar. Auch mit Anthropic und Google wurden demnach Vereinbarungen über die Nutzung von KI-Technik getroffen. Mit xAI sei auch eine Vereinbarung vorbereitet worden, Ende Juni sei Grok aber aus allen ausgearbeiteten Verträgen entfernt worden. Zwei Beteiligte vermuten demnach, dass das an den antisemitischen Tiraden lag.

Elon Musk hatte Anfang Juli ein Update des KI-Accounts auf X und bessere Antworten angekündigt. Kurz darauf begann er damit, antisemitische Inhalte zu verbreiten. Danach wurde der Account abgeschaltet. In der Folge hat unter anderem Polens Regierung die EU-Kommission aufgefordert, mögliche Verstöße gegen den Digital Services Act (DSA) durch Grok zu untersuchen. Der Bericht von Wired legt nun nahe, dass xAI wegen der Ausfälle die Möglichkeit verloren hat, umfangreich in US-Bundesbehörden einzuziehen. Wegen der Sonderpreise ist der Firma aber wohl kein großes Geschäft entgangen. Anfang des Jahres war Elon Musk für Monate „besonderer Regierungsangestellter“ mit besonders engem Kontakt zu US-Präsident Donald Trump.

(mho)

Ende August werden große Teile des Bitnami-Katalogs kostenpflichtig und über Arrow teuer vermarktet. Kunden befürchten Kosten von 50.000 US-Dollar im Jahr und mehr. Die jetzige Sammlung wandert in einen Legacy-Katalog, den Broadcom aber nicht mehr pflegen wird. Anwenderinnen und Anwender müssen nach Alternativen suchen.

heise developer spricht mit dem Cloud-native-Experten Johannes Kleinlercher darüber, wie Anwender sich behelfen können, welche Alternativen es gibt und welche Perspektiven sich für die Open-Source-Community ergeben.

Manche Images und Charts bleiben bei Bitnami ja offen. Aber welche für Developer wichtigen hat Broadcom konkret hinter die Paywall geschoben?

Welche Bitnami-Images weiterhin offen bleiben, sieht man jetzt schon vorab unter https://hub.docker.com/u/bitnamisecure. Für Helm-Charts ist das hingegen gar nicht so leicht offiziell herauszufinden. Bitnami erwähnt nur das populäre Chart sealed-secrets. Das heißt, man muss davon ausgehen, dass mehr oder weniger alle anderen nicht mehr frei zur Verfügung stehen.

Der Sourcecode der Helm-Charts bleibt allerdings unter der Apache-2.0-Lizenz frei zur Verfügung, nur die gebauten und versionierten OCI-Artefakte verschwinden hinter der Paywall. Um herauszufinden, welche Images ein Helm-Chart heranziehen, empfehle ich das Plug-in helm-images. Und um alle transitiven Abhängigkeiten von Helm-Charts ausgeben zu lassen, das Plugin helm cascade.

In meiner Firma suXess-it verwendeten wir bis vor Kurzem für die Internal Developer Platform kubriX die Charts von Keycloak und PostgreSQL. Gerade das Keycloak-Chart von Bitnami ist bei sehr vielen Entwicklerinnen und Entwicklern beliebt, weil das offizielle Keycloak-Projekt zwar einen Operator für Kubernetes zur Verfügung stellt, aber kein Helm-Chart für diesen oder für eine klassische Keycloak-Installation.

Aber auch bei anderen Applikationen wie Kafka findet man bei einer Suche an erster Stelle immer das Bitnami-Chart. Bitnami hat in seinem Repository 118 Helm-Charts, wie ArgoCD, verschiedene Grafana-Projekte, Nginx, RabbitMQ, Kafka, Gitea, WildFly, Tomcat, WordPress und so weiter. Alle 118 sind je nach Branche mehr oder weniger populär. Viele Firmen verlassen sich auf Bitnami-Charts und -Images, weil sie sehr gut gehärtet und laufend aktualisiert werden.

Welche Folgen ergeben sich für die Projekte, die auf Bitnami bauen?

Die müssen nun aufpassen, ob nicht Helm-Charts als Abhängigkeit – auch indirekte – irgendwo auf ein Bitnami-Chart verweisen, ohne es wirklich zu wissen. Sehr spannend ist auch, dass populäre Helm-Charts wie Kyverno und Velero immer noch in ihrer aktuellsten Version das kubectl-Image von Bitnami integrieren und erst neue Releases herausbringen müssen, wo sie auf Alternativen umstellen, wie die beiden Issues von Kyverno und Velero zeigen. Vermutlich gibt es noch einige andere Charts, die ähnliche Themen haben.

Durch die Umstellung von Broadcom können also tatsächlich viele Probleme entstehen. Ich sehe den Vorfall auch als Weckruf, sich mehr um die Cloud-native Supply Chain zu kümmern und nicht unbedacht Charts oder Images in Projekte zu integrieren. Wichtig ist, die Abhängigkeiten zu verstehen und ordentlich zu managen.

Wie stark ist die Abhängigkeit der Entwicklungs-Branche von Bitnami? Können die Nutzer als Konsequenz einfach auf andere Anbieter umsteigen oder selbst etwas aufsetzen?

Wie bereits erwähnt, nutzten viele Personen oder Firmen in der Vergangenheit Bitnami-Images oder -Charts, weil sie sehr sicher und aktuell gehalten wurden. Dafür muss man sich bei Bitnami bedanken, aber auch bei allen freiwilligen, externen Contributoren, die dazu beigetragen haben.

Bei einigen Charts wie Keycloak gab es auch gar keine Alternative. Ich schätze die generelle Abhängigkeit in der Industrie deshalb als sehr hoch ein. In meiner Firma haben wir mit Keycloak die Erfahrung gemacht, dass wir nicht ohne Weiteres auf einen anderen Anbieter umsteigen können oder sollten. Wenn man irgendwo im Internet eine Alternative findet, muss man sich viele Fragen stellen:

• Wie sicher und vertrauenswürdig ist die Quelle?
• Welche Maintainer stecken dahinter?
• Unter welcher Lizenz wird das Chart oder das Image angeboten?
• Wann wurde das Projekt das letzte Mal aktualisiert?
• Entspricht der Code gängigen Security-Best-Practices?

Natürlich kann man auch immer selbst die Images und Helm-Charts pflegen, aber bei Software, die sich laufend weiterentwickelt, darf man den Wartungsaufwand nicht unterschätzen. Auch die Frage „Was muss ich für die neue Keycloak-Version im Dockerfile oder Helm-Chart anpassen?“ stellt sich dann laufend. Aus diesem Grund entstehen oft Open-Source-Projekte. Nicht weil alles gratis ist, sondern weil man gemeinsam einen Mehrwert für viele schafft, der sonst für einzelne fast unmöglich zu erarbeiten wäre.

Es gibt auch gute Gründe, keine Charts aus der Community zu verwenden. Wenn eine Firma zum Beispiel komplett unabhängig sein will oder eine konkret auf die eigene Umgebung abgestimmte Lösung benötigt.

Für Keycloak gibt es ja erste Überlegungen, eine Alternative ins Leben zu rufen. Wie reagiert die Open-Source-Community auf die neue Paywall?

Für uns in der Firma war klar, dass wir eine nachhaltige Lösung für uns, aber auch für die Community suchen wollen. Ich habe deshalb über LinkedIn und Github-Issues in den jeweiligen Projekten versucht, gemeinsam mit der Community mögliche Alternativen zu finden. Es hat sich herausgestellt, dass die beste Alternative wäre, ein Helm-Chart so nahe wie möglich bei den Keycloak-Maintainern zu entwickeln. Das steigert den Wert des Projekts selbst und macht auch eine halbwegs effiziente Wartung möglich.

Einige Keycloak-Maintainer und -Contributoren stehen dem auch sehr offen gegenüber, wenngleich auch deren Kapazitäten knapp sind. Es geht jetzt also darum, das Ganze wirklich als Gemeinschaftsprojekt zu sehen, und nicht einfach jemandem die Aufgabe zu übergeben und dann nur zu konsumieren. Ob sich das bis zur Einführung der Paywall am 28. August noch ausgeht, steht leider noch nicht fest.

Was können Keycloak-Anwender jetzt tun?

Derzeit empfehle ich allen, die jeweiligen Kubernetes-Manifeste des Keycloak-Operators in der passenden Version ins eigene Helm-Chart zu integrieren und eine eigene Keycloak-CustomResource zu definieren. Wenn eine neue Version des Keycloak-Operators erscheint, muss man entsprechend die Kubernetes-Manifeste aus dem oben erwähnten Git-Repository beim neuen Versions-Tag herunterladen und bei sich integrieren.

Sobald dann ein offizielles Helm-Chart für den Keycloak-Operator zur Verfügung steht, wird dieses Vorgehen mit einem Update der Helm-Chart-Version um einiges komfortabler und Entwickler können es mit dem populären Tool renovate einfacher managen.

Unser Open-Source-Projekt kubriX wird auf jeden Fall nach der Umstellung am 28. August keine Bitnami-Images oder Helm-Charts mehr benötigen.

Eins ist mir noch wichtig festzuhalten: Es steht jeder Firma natürlich frei, ihr Geschäftsmodell rund um ihre Open-Source-Projekte so zu wählen, wie es ihr gefällt. Und jedem muss klar sein, dass Firmen auch im Open-Source-Umfeld Geld verdienen müssen. Sonst überlebt das beste Projekt nicht. Allerdings sind die kolportierten Preismodelle von Broadcom wohl nicht darauf ausgelegt, die breite Masse anzusprechen, obwohl sehr viele Contributoren in der Vergangenheit zur Qualität der Bitnami-Charts und -Images beigetragen haben.

Dementsprechend bin ich gespannt, wo sich das Bitnami-Projekt hinbewegt. Wir unterstützen auf jeden Fall weiterhin diverse Open-Source-Projekte und -Organisationen, von Bitnami müssen wir uns allerdings verabschieden.

Johannes, vielen Dank für das Gespräch!

(who)