Im Mai 2009 war ich 22, schloss meinen CIS-Abschluss an der University of Jordan ab und half, einen Open-Source-Club zu gründen. Ich stand vor anderen Studierenden und erklärte, warum sie sich für Software interessieren sollten, für die sie nichts bezahlten, die von Leuten gebaut wurde, die sie nie treffen würden, und die auf Telefonen mit 2,5 MB Heap lief.

Der Stack, den wir lehrten: Java — konkret J2ME — PHP für Web und MySQL, weil was sonst. Das hier ist kein Post über moderne Tooling. Das ist ein Post darüber, wie es sich anfühlte, in Amman im Jahr 2009 Evangelist für Open-Source-Software zu sein — als die meisten Leute im Raum mit raubkopierten Kopien von Windows XP aufgewachsen waren und dachten, Linux sei für Leute, die Leiden mögen.

Warum J2ME und nicht Objective-C

Diese Frage kriege ich heute, von Leuten, die nicht dabei waren. “Warum J2ME? Das iPhone war 2009 doch schon draußen.”

Das iPhone war draußen. Das iPhone Developer Program erforderte einen Mac und 99 Dollar im Jahr. Die Telefone, die unsere Kommilitonen tatsächlich besaßen — und die Telefone, die die User jeder Software, die wir bauen könnten, tatsächlich tragen würden — waren Nokia Series 40s, Sony Ericssons und gelegentlich ein Symbian-Gerät. J2ME war das, was diese Telefone liefen. MIDP 2.0, CLDC 1.1 und, wenn man Glück hatte, ein JTWI-konformes Gerät mit einem halbwegs anständigen Camera-API.

Wenn du in Jordanien 2009 Software für echte User bauen wolltest, zieltest du auf J2ME. Das war keine philosophische Entscheidung. Es war Arithmetik.

Mein eigenes Abschlussprojekt damals war eine GIS-basierte Marketing-Plattform mit Mobile-Clients für Windows Mobile und Symbian. Ich schrieb das Mobile-Frontend in Java. Das Web-Backend in PHP. Die Datenbank in MySQL. Das Curriculum, das wir für den Club entwarfen, war also nicht hypothetisch — es war buchstäblich das, was ich im selben Semester baute, in dem ich es lehrte.

Was Open Source in diesem Raum wirklich bedeutete

Hier ist, was es edgy machte: Die meisten Leute in der Softwarewelt Jordaniens zu der Zeit — Studierende, Profis, alle — operierten in einer Welt, in der Software einen Preisschild und eine Seriennummer hatte. Microsoft Office hatte einen Key. Photoshop hatte einen Key. Die Idee, dass etwas Nützliches einfach verfügbar war — legal, kostenlos, mit Quellcode, den man wirklich lesen konnte — das erforderte Erklärung.

Ich hielt keinen Vortrag über die Philosophie von Richard Stallman. Ich erklärte einem Raum voller 20-Jähriger, dass sie heute eine Web-App mit Apache, PHP und MySQL bauen könnten, ohne einen einzigen Dinar für Lizenzen auszugeben, und dass das legal, beabsichtigt und die Art war, wie das meiste Internet schon lief.

Die Aha-Momente waren real. “Der Code ist einfach… da?” Ja. Der Code ist einfach da. Geh, lies ihn. Brich ihn. Fix ihn und schick den Fix zurück.

Die Teile, die gut gealtert sind, und die, die schlecht gealtert sind

Die Philosophie ist gut gealtert. Die konkrete Technologie nicht.

J2ME ist jetzt ein Museumsexponat. Symbian ist ein Museumsexponat. Das Nokia Series 40 ist ein Museumsexponat. Ein volles Jahrzehnt bevor Smartphones ihre Übernahme abschlossen, lehrten wir Mobile-Entwicklung auf Hardware, die heute tatsächlich schwer zu finden ist außer in einer Sammler-Schublade.

Aber das Prinzip — dass man den vollständigen Stack verstehen sollte, dass man den Source-Code der Tools lesen können sollte, die man benutzt, dass echte Dinge zu shippen die beste Ausbildung ist — das hat gehalten. Die Engineers, mit denen ich gearbeitet habe und die die besten Instinkte haben, sind fast immer Leute, die Zeit damit verbracht haben, Source-Code zu lesen, den sie nicht selbst geschrieben haben. Das ist kein Zufall.

Die spezifische Version von “Open Source als ungewöhnliches Pitch” ist auch verschwunden, aus offensichtlichen Gründen. 2009 erforderte es Aufwand, jemanden davon zu überzeugen, dass Open Source legitim ist. 2024 würde es mehr Erklärung erfordern, ein ernsthaftes Projekt ohne Open Source zu bauen. Die Evangelisierung hat funktioniert, kollektiv. Wir haben gewonnen.

Was direkt danach passiert

Dreizehn Monate nach dem Start des Clubs war ich bei EHS/HAKEEM und schrieb MUMPS-Routinen für Jordaniens nationales Healthcare-System. Falls du MUMPS nicht kennst: es ist eine Sprache aus dem Jahr 1966, läuft auf VistA, hält Krankenhäuser auf der ganzen Welt am Laufen, und ist ungefähr so weit von PHP entfernt, wie man reisen kann und trotzdem auf demselben Planeten bleiben.

Der Sprung klingt abrupt. Er fühlte sich nicht abrupt an. Ich hatte Vorlesungen über “lies den Source-Code, versteh das System unter dir” gehalten — und dann war ich in einem System, in dem der Source-Code 40 Jahre alt war, von Leuten am MIT und in der VA geschrieben, und ich musste ihn verstehen, um irgendetwas Nützliches zu tun. Die Praxis transferierte, auch als die Syntax aus einem anderen Zeitalter war.

Ich habe in irgendeiner Form gelehrt, seit bevor ich einen Jobtitel hatte. Bei AFAQ leitete ich Architecture Reviews, die größtenteils strukturiertes Lehren waren. Bei Bytro, Modernisierungs-Workshops. Bei Talentera, mit dem Team über System Design. Das Format änderte sich. Der Instinkt — erkläre das System, zeig den Source-Code, baue die Sache — blieb konstant.

2009 bis heute

Ich war 22, stand vor einem Whiteboard und erklärte, warum eine Java-Runtime, die auf ein Nokia-Telefon passte, etwas Gutes war, das deine Zeit wert ist. Ich bin jetzt 37, shippe verteilte Systeme in Kotlin und Go, betreibe eine local-first Agent-Control-Plane (Fulcrum) in meinem Homelab.

Die J2ME-Heap-Constraints sind weg. Die MIDP-2.0-APIs sind weg. Der Symbian-Client meines Abschlussprojekts ist weg. Aber ich erkläre immer noch, warum du den Source-Code lesen solltest, glaube immer noch, dass der beste Weg, ein System zu lernen, darin besteht, etwas Echtes damit zu bauen, und bin immer noch ein bisschen der Typ, der mit 22 aufstand und sagte: “Das ist deine Zeit wert” über Software, für die man nichts bezahlte.

Manche Instinkte compoundieren.