Hadmut Danisch
Ansichten eines Informatikers

Wie man Ruby on Rails zum Entgleisen bringen will

Hadmut
25.9.2025 12:25
Uncategorized

Zur politischen Zersetzung der Open Source Szene.

Weil nicht alle wissen, worum es geht:

Ruby ist eine Programmiersprache. Genauer gesagt, eine Interpretersprache, weil sie nicht compiliert, sondern erst zur Laufzeit als Quelltext geladen und ausgeführt wird. Eigentlich mag ich Ruby sehr gerne und verwende es für viele Dinge, weil es eine sehr elegante und moderne Sprache ist, die auf einem weit höheren Niveau als etwa Python arbeitet und viel kürzere und prägnantere Ausdrücke ermöglicht. Eigentlich eine sehr schöne Sprache. Mich stören daran aber zwei Dinge enorm. Eines ist, was man ursprünglich als Stärke beschrieben hat, und was Merkmal praktisch aller Interpretersprachen ist, dass es keine Typen- und Parameterbindung für Variablen und Prozeduren gibt, und das deshalb nicht wie bei Compiler-Sprachen schon zur Zeit der Übersetzung geprüft werden kann, sondern – wenn überhaupt – erst dann, wenn der Code tatsächlich ausgeführt wird. Wenn man aber beispielsweise die Parameter einer Prozedur ändert, ist es enorm schwer, alle Prozeduraufrufe zu finden und anzupassen. Oder wenn man sich bei einem Variablennamen verschreibt, oder etwas in der Art, dann sind das alles Fehler, die erst zur Laufzeit – vielleicht – auffallen, wenn das Programm mit einer Fehlermeldung terminiert. Oder aber einfach Fehler produziert, weil der Parameter den falschen Typ hat, und Ruby jeden Typ akzeptiert, und versucht ihn zu benutzen. Man hat das als Vorteil hingestellt und auf den Namen „Duck Typing“ getauft, es ist aber einfach nur Mist, der Programme sehr fehleranfällig und Ruby für größere Projekte untauglich macht. Der zweite Punkt, der mich stört, ist, dass viele Community-Module (Bibliotheken, unter Ruby Gems genannt) nicht mehr gepflegt werden, weil sich die Mehrheit eher Python angeschlossen hat. Python ist weit primitiver, macht vieles schlechter und leidet – ebenfalls Interpretersprache – unter denselben Fehlern, ist aber eher so etwas wie ein modernes BASIC, und gerade deshalb so beliebt, weil man da nicht viel lernen muss. Auch die Sprache Go schöpft ihre große Beliebtheit vor allem daraus, dass sie so gottserbärmlich simpel ist und deshalb vielen zugänglich ist, die eigentlich nicht programmieren können und die Finger besser weg ließen.

Ruby on Rails („RoR“, Ruby auf Schienen) ist ein „Framework“, eine Programmierumgebung, die es erlaubt, nach einem relativ starren, aber anerkannten Programmierschema (MCV = Model – Controller – View) Webapplikationen mit Datenbank-Backend zu schreiben. Und solche Programme, die nach vorne raus mit dem Webbrowser zu bedienen sind und nach hinten raus die Daten in einer relationalen Datenbank ablegen, sind etwas, was man ganz oft und ganz wichtig braucht, damit kann man enorm viel machen. Webshop, Ticketsystem, Bibliotheksverwaltung, Blogs, und und und und … ist ein ganz häufig vorkommendes Programmierschema. Im Prinzip ist Ruby on Rails damit eine modernere Variante des sogenannten „LAMP-Stacks“ (= Linux, Apache, MySQL, PHP), der ja auch daraus hinauslief, dass man eine Webapplikation anbot, die nach vorne raus mit dem Webbrowser bedient wird und nach hinten raus die Daten in einer Datenbank ablegt.

Ruby on Rails war anfangs überaus beliebt, galt als eine ganz tolle Idee, kam so um 2007 oder 2008 heraus (ich habe 2008 die Version 2 benutzt) und war bis ungefähr Version 3 richtig gut: Man konnte sich die Doku durchlesen, wusste dann, was das Ding macht, nämlich nur überschaubar viel, und loslegen. Es gab damals auch Anleitungsbücher und ein Kurzanleitungsheft von O’Reilly. Da stand alles drin, man konnte das alles benutzen.

Beide, Ruby und Ruby on Rails schaukelten sich gegenseitig hoch und machten sich gegenseitig bekannt, weil Ruby on Rails einfach eine Paradeanwendung für Ruby war.

Aber, ach.

Ein enormes Problem von Ruby on Rails wurde, dass das ab ungefähr Version 4 völlig verfilzt ist und toterweitert wurde. Aus lauter Beliebtheit haben immer mehr Leute mitgemacht und jeder Honk und Spinner da seine persönlichen Wünsche eingebaut hat, man das dann auch aus einer ursprünglich einheitlichen Bibliothek in viele Unterbibliotheken und Module aufgeteilt, und dabei jede Übersicht verloren hat. So sehr, dass man trotz großer Mühe bei der Dokumentation und dem Schreiben schöner Anleitungen (vor allem den Ruby on Rails Guides) nicht nur nicht hinterherkam, sondern schlicht selbst nicht mehr wusste, was das alles macht und wozu man es braucht, weil keiner mehr den zentralen Überblick hatte.

So wurde das mit immer mehr Funktionen und Modulen aufgebläht, die aber alle unter dem Zeitgeistphänomen schlechter Programmierung litten: Wie so viele Projekte in der IT haben sie einen Phantasienamen und als Erklärung „it’s so cool“ und man kann damit so schnell so tolle Dinge machen, das ist so wichtig, ohne aber dazuzuschreiben, was das überhaupt macht, wozu man es braucht, oder wie man es benutzt. Ist Euch mal aufgefallen, wie viele IT-Projekte, Module, Bibliotheken es unter der Fuchtel von Gen X , Gen Z usw. gibt, die sich großartig anpreisen, voll des Eigenlobs sind, voll von Zeitgeistsprache („cool“ und so weiter), aber schon nicht erklären könne, was sie eigentlich machen, was ihre Aufgabe und Funktion ist? Wozu sie überhaupt da sind?

Und wieviele Leute nicht mehr in der Lage sind, ihren Code, ihre Bibliothek zu dokumentieren, die Funktion zu beschreiben? Bestenfalls bekommt man noch Beispiele, die man blind per copy-and-paste übernehmen soll, ohne sie verstehen zu können, weil nichts beschrieben ist, und jede noch so kleine Abweichung oder anderen Anwendungsfall unmöglich macht? Die dann darauf verweisen, dass man „Googlen“ solle, irgendwer wird die Frage irgendwo auf der Welt doch schon mal beantwortet haben? Und inzwischen die KI fragt? Denen es also nicht nur an Zeit dafür fehlt, sondern die gar nicht mehr wissen und verstehen, was eine Dokumentation ist?

Ruby on Rails wurde vollgepackt mit solchen Schrottmodulen. Immer öfter passierte es, dass bei den Versionsupdates das Modul X durch das Modul Y ersetzt wurde – oder auch nicht, so genau erfuhr man das nicht, weil nach der Update-Prozedur plötzlich X und Y hatte, und nicht klar war, ob man nun X und Y brauche, oder X rauswerfen solle oder man auf Y verzichten und X weiterverwenden solle. Die Leute fragten, und beklagten, dass sie nicht mehr verstehen könnten, was all diese Module mit diesen nichtssagenden Phantasienamen und ohne greifbare Dokumentation überhaupt machen. Die Rails-Macher wussten es selbst nicht mehr. Immer wieder bekam man die Antwort, dass man doch einfach mit dem aktuellen Rails ein neues, leeres Rails-Projekt anlegen solle (rails kann mit dem Befehl rails new [NAME] neue Rails-Projekte als Grundstruktur anlegen) und dann da reinschauen, ob X noch drin ist oder nicht. Weil keine Sau mehr einen zentralen Überblick hatte, sondern Hinz und Kunz irgendwelche Erweiterungen nach ihren Vorstellungen einbauten, die dann wiederum eigene Abhängigkeiten einschleppten, und am Ende keine Sau mehr wusste, was das Ding im Ganzen eigentlich macht.

Ich hatte mal nach einem Upgrade und Neuanlegen von Projekten angefragt, was die Konfigurationsdatei sowieso, deren Bedeutung mir nicht ersichtlich war, und für die ich keinerlei Dokumentation finden konnte, eigentlich macht und zu welchem Modul sie gehört. Sie wussten es selbst nicht mehr. Weil jedes eingeschleppte Modul willkürlich und planlos irgendwelche Konfigurationsdateien anlegte, die einfach irgendwohin legte, und am Ende keiner mehr wusste, was das eigentlich macht und wozu man es braucht, oder wie man darin Fehler korrigiert.

Nur zwei Beispiele:

Rails verwendet, wie viele Web-Applikationen, eine sogenannte „Asset-Pipeline“. Web-Applikationen brauchen Dinge wie Style-Sheets, die auch dynamisch erzeugt und im Cache gehalten und verwaltet werden müssen, Fonts, Statische Elemente, JavaScript-Module und einiges mehr. Und weil diese „Assets“ durch verschiedene Konverter gejagt werden müssen (z. B. Sass -> CSS -> komprimiertes CSS), nennt man das alles eine Asset-Pipeline. Diese Generatoren, die diese Assets verarbeiten, hat man mehrmals ausgetauscht, um irgendetwas zu verbessern, und die jedesmal ganz anders funktionierten und andere Konfigurationsdateien brauchten, aber nie verständlich dokumentiert waren, und bei denen nie klar wurde, ob sie die alten ersetzen oder ergänzen, ob sie zusammen verwendet werden können, ob man die neuen einsetzen muss oder die alten weiterverwenden kann.

Ruby verwendet Ajax und verwandte Techniken, um Webseiten mit Datenbankansichten nicht bei jeder Änderung komplett neu laden zu müssen, sondern etwa bei Formulareingaben oder „Anklicken“ nur kleine Stellen zu aktualisieren und nur Teilbereiche neu vom Server zu holen. Auch das hat man mehrmals geändert, und die Dokumentation dazu war oft lausig bis nicht vorhanden.

Der Verdruss stieg, und derweil entstanden Konkurrenzframeworks für etwa Go und Rust, obwohl die nicht wirklich Konkurrenz sind, weil man in Compilersprachen immer Compilieren und neustarten muss, und nicht, wie bei Ruby on Rails, im laufenden Webserver drin herumprogrammieren kann, ohne ihn neu starten zu müssen, was die Entwicklung enorm beschleunigt und vereinfacht.

Das zweite Problem von Ruby heißt David Heinemeier-Hanson (DHH). Das ist der Erfinder und Haupt-Maintainer von Ruby on Rails, der – wenn ich das richtig verstanden habe – auch eine Firma hat, die in der Nutzung von Ruby on Rails berät. DHH steht aber im Ruf, ein arroganter Kotzbrocken zu sein. Überheblich, herablassend, hält sich selbst für Gott.

Diese Erfahrung durfte ich auch einmal kurz machen.

Bei irgendeiner neuen Rails-Version (ich weiß nicht mehr, ob es die 5 oder die 6 war), bemerkte ich, weil ich damals Rails-Anwendungen in Docker-Container packte, bei denen man genau sehen kann, wie groß der ganze Krempel ist, während sich das bei einer normalen System-Installation immer irgendwo in der sonstigen Betriebssysteminstallation verliert und nicht so auffällt), dass die Größe einer Rails-Installation ohne eigene Erweiterung, so wie rails new sie ausspuckt, noch bevor man selbst etwas daran geändert hat, von ein paar MB (ich glaube, es waren so um die 3 MByte) auf weit über 100 MB angestiegen war.

Ursache war, dass man irgendeine sehr bekloppte, riesige JavaScript-Sammlung eingebunden hatte, damit man in Rails auf jeden erdenklichen JavaScript-Scheiß zugreifen kann, der jemals irgendwo geschrieben wurde.

Das hat die Sache aber nicht nur riesengroß gemacht, sondern vor allem zu einem Sicherheitsproblem, denn ich habe darin auch Codestücke gefunden, deren eigene Autoren schon lange darauf hinwiesen, dass die seit Jahren nicht mehr gepflegt würden und dringend davon abrieten, sie noch zu benutzen, weil sie riesige Sicherheitslöcher enthielten, die nicht mehr gestopft wurden. Irgendein Depp hatte wohl gemeint, es sei doch so nützlich und bequem, einfach alles in Rails einzubinden, was es gibt, damit man auf alle JavaScript-Kunststückchen dieser Welt zugreifen kann, und keiner hatte mehr einen zentralen Überblick, was da passiert oder wie groß der Müllhaufen wird – und welche Sicherheitslöcher man sich einschleppt. Nicht wenige Rails-Applikationen stehen offen im Netz. Twitter zum Beispiel lief anfangs auf Ruby on Rails.

Also legte ich einen Bug-Report an, der auf zwei Dinge hinwies:

  • die stark angeschwollene Größe von RoR, und dass da plötzlich weit über 100 MB Programme drin sind, die keiner mehr durchblicken kann,
  • die Sicherheitsprobleme, die damit einhergingen, dass in unkontrollierter Menge veralteter Code eingebaut wurde, dessen Autoren schon selbst schreiben, dass man ihn wegen seiner Sicherheitslöcher nicht mehr verwenden dürfe und die nicht mehr gestopft würden.

Ergebnis: DHH sperrte meinen Account für eine Woche, weil ich es gewagt hatte, ihro Heiligkeit zu kritisieren und Entscheidungen in Frage zu stellen. (Was mir völlig egal war, weil ich da sonst sowieso nie etwas schrieb, aber eben sehr aufschlussreich war, zu welchem Murks Ruby on Rails degeneriert war.)

In der nächsten großen Version hatte man den Misthaufen dann doch wieder rausgeworfen (wehe jedem, der sich daran gewöhnt hatte, das zu verwenden), und inzwischen ist man bei RoR Version 8, wo man doch wieder etwas aufgeräumt und reduziert hat.

Und das ging nicht nur mir so. DHH steht im Ruf, sich wie eine Art Sonnenkönig aufzuführen, eingebildet bis zum geht nicht mehr, weil Ruby on Rails früher eben mal ein ganz großes Ding und sehr bekannt war, die Leute aber durch die abgestürzte Code-Qualität das Grausen bekamen und längst in Scharen davonliefen, was ihn nur zu noch mehr Arroganz gebracht habe, statt Fehler einzusehen.

Rails lebte auch lange davon, dass es keine Alternative gab. PHP ist zu schlecht, krautig und unstrukturiert, und JAVA einfach zu schlecht, umständlich, fehleranfällig. Mit Go und Rust sind aber inzwischen Konkurrenten erwachsen, auch wenn denen als Compilersprache auf niedrigem Komplexitätsniveau die Leichtigkeit und Beweglichkeit der Entwicklung und der komfortable Umgang mit Strings, Datenbanken usw. fehlt.

Der Angriff

Eine Gruppe Linker versucht nun, David Heinemeier-Hanson (DHH) nach dem üblichen Code-of-Conduct-Schema abzusägen und aus seinem eigenen Projekt herauszuhebeln.

Siehe vor allem den Open-Letter, den sie selbst als „Github-Projekt“ angelegt haben, aber keine „Bug-Reports“ zulassen, weil sie natürlich ihrerseits nicht dulden, kritisiert zu werden.

Der Grund: DHH habe sich – außerhalb des Projektes – politisch unkorrekt geäußert.

So halten sie ihm vor, dass er etwa beklage, dass in London nur noch ein Drittel der Bewohner gebürtige Engländer seien. Weil in London aber auch nur noch ein Drittel Weiße sind, halten sie ihm nun vor, dass er behaupte, dass nur Weiße Engländer sein könnten – er also ein Rassist sei. Ich habe noch nicht alles gelesen, aber es scheint, als habe er das gar nicht gesagt. Er hat wohl nur gefragt, was in Copenhagen los wäre, wenn – wie in London – nur noch ein Drittel der Einwohner Dänen wären. Oder dass er sich kritisch zum Genderzirkus und Grundschulen geäußert hatte.

Er sei deshalb ein Rassist und ein Sexist, oder einfach kurz: Ein Nazi eben.

Deshalb fordern sie jetzt in ihrem „offenen Brief“, dass man Heinemeier-Hanson doch aus seinem eigenen Projekt werfen möge.

Die übliche Methode, eingeführt von der linksextremen Kampftranse Coraline Ada Ehmke mit den „Code of Conducts“, deren Ziel und Taktik es ist, Open-Source-Projekte zu enteignen und links zu übernehmen, nachdem das Unterwandern per Frauenquote wie in Unternehmen in Open-Source-Projekten so nicht funktioniert. Reihenweise haben die damit schon Projekte zerstört oder übernommen und deren ursprüngliche Eigentümer und Macher in die Wüste geschickt, indem sie ihnen irgendwelche Aussagen vorhielten, die mit dem Projekt gar nichts zu tun haben. Letztlich sind das stalinistische Enteignungen, Projektraub. Und ich habe den sehr starken Verdacht, dass Ehmke auch hier dahinter steckt, denn Ehmke war früher in der Ruby- und vor allem Ruby-on-Rails-Szene sehr aktiv. Ehmke „kennt“ Rails in- und auswendig. Meines Erachtens gehört Ehmke mit einem derartigen Rufmord-Konto längst ins Gefängnis. Ob Männer- oder Frauenknast ist mir egal.

Eine besondere Geschmacklosigkeit daran ist, dass sie sich in Anspielung den Namen „Ruby on Rails“ (Ruby auf Schienen) „Plan Vert“ nennen:

“Plan Vert” was a railway sabotage campaign by the French resistance during WW2. Reference suggested by @cinebox@masto.hackers.town.

Plan Vert war eine Operation des französischen Widerstandes, am Abend vor der Landung der Alliierten in der Normandie Zugstrecken zu sabotieren, damit die Deutschen daran gehindert wurden, Soldaten und Munition nachzuliefern.

Dieses Idiotenpack hält sich also für die Nachfolger der Résistance im Kampf gegen die Nazis, weil sie auf einen einzelnen Mann losgehen, der ein paar Blogartikel geschrieben hat, die ihnen nicht passen, und dem es nicht gefällt, dass in London nur noch ein Drittel der Bewohner Engländer sind.

Das reicht ihnen, um ihn zum Nazi zu erklären, sich für die Résistance zu halten, und die Landung in der Normandie nachzuspielen, als wären die Alliierten damals am D-Day gelandet, um Europa von Blogartikeln zu befreien.

Diese Leute sind nicht nur Holocaust-Verharmloser übelster Sorte (und die US-Linke wird ja auch gerade selbst sehr antisemitisch, rückt also selbst in die Nähe der Nazis), sondern es wirft auch ein ganz anderes Problem auf:

Wenn diese Leute sich selbst als die Résistance sehen und sich nach Sabotage-Projekten benennen, wie sicher kann dann community-geschriebene Open-Source-Software noch sein? Muss man dann nicht dringend davon ausgehen, dass sie auch Software sabotieren, um politische Ziele zu erreichen, also Fehlfunktionen und Backdoors einbauen, Daten löschen und verändern, und so weiter?

Müssen wir das nicht als Akt des linken Terrors gegen die Softwareinfrastruktur betrachten?

Muss man nicht dringend davon ausgehen, dass sie per Softwaresabotage auch Webseiten aller Leute sabotieren, die sie für „Nazis“ halten?