Anfang 2009 wollte es der Zufall, dass ich hauptberuflich zum Contao-Entwickler wurde. Nicht lange hat es gedauert, bis eine E-Mail ankam, in der es hiess: Kannst du uns einen Shop für Contao programmieren?

Klar hätte ich das gekonnt. Aber warum das Rad neu erfinden? Ich wusste, in Deutschland wird an etwas gearbeitet. Und ich hatte von einem Team erfahren, das in den USA eine Lösung baut. Also habe ich beide angeschrieben. Mein Kunde braucht einen Shop, kann ich euer Modul dafür nutzen?

Die Antwort aus Deutschland:
Es kommt in X Monaten, du musst warten.
Aber der Zeitplan passte nicht zu meinem Kunden.

Die Antwort aus den USA:
Klar, hier hast du den Code, schau mal, ob es dir gefällt.
Und wie es mir gefiel!

Damit wurde ich Mitentwickler einer Shop-Lösung für Contao, erfunden von Fred Bliss und Blair Winans. Deren Auslöser war der Frust über externe eCommerce-Lösungen. Der Name Isotope eCommerce war da bereits vorhanden.

Was ursprünglich in einem SVN-Repository begann, wurde der Allgemeinheit im Mai 2010 zur Verfügung gestellt. Man kann sich die Version 0.1.0 bei GitHub ansehen; Isotope «begann» mit 239 Dateien und ca. 40'000 Zeilen Code. https://github.com/isotope/core/commit/cbcc72d57b9a5c4191dd2dcb3d1fad534660ab5d

Wer Contao-Code versteht und Isotope schonmal verwendet hat, erkennt bekannte Muster. Es gibt bereits Produkttypen, Attribute, Adressen für Mitglieder, Zahlungs- und Versandmethoden, Steuersätze und Steuerklassen, sogar Verwandte Produkte sind in ihrer Urform bereits vorhanden. Die Klassen für DC_ProductData (Produktverwaltung im Backend) und DC_TablePageId (Verknüpfung der Produkte mit Seiten als Kategorien) gibt es mit genau diesem Namen noch heute. Auch Konzepte wie beispiels­weise der Bildupload im Backend (in den eigenen /isotope Ordner) sind bis heute gleichgeblieben.

Schon kurze Zeit nach der ersten Version wanderte ein Grossteil der Weiterentwicklung nach Europa, insbesondere auch dank der deutschen Contao-Community. Die gerade aufblühende Contao Konferenz und das Camp trugen ihren Teil zur Verbreitung bei, nach einer Isotope-Session wurde fast immer gefragt.

Pünktlich zu Weihnachten 2013 erschien die Version 2.0. Die Anpassungen an Contao 3 waren umfangreich, diverse Probleme der 0er- und 1er-Version wurden beseitigt. Für bestehende Shops musste ein Migrations-Tool geschaffen werden, da Contao noch nicht über entsprechende Mittel verfügte. Ein wichtiger Meilenstein war auch das Notification Center, welches Yanick für Isotope 2 erfand. Ausserdem wurde die Dokumentation von Bjarke komplett überarbeitet.

Zehn Jahre ist es her, dass eine Major-Version von Isotope erschienen ist. Zehn Jahre, in denen dutzende neue Funktionen, Zahlungsmethoden, Erweiterungen und ein umfangreiches Ökosystem entstanden. Aber auch 10 Jahre, in denen sich Contao weiterentwickelt hat. Kaum zu glauben, dass bei Isotope noch praktisch nichts von Symfony profitiert – das gab es damals bei Contao schlicht noch nicht.

Software altert, weil sich deren Umgebung ändert, dadurch hat sie eine begrenzte Lebensdauer. Spätestens mit Contao 5 wissen wir, dass grössere Anpassungen nötig sind, damit Isotope nutzbar bleibt. Die gute Nachricht ist: die Struktur von Isotope wird sich nicht signifikant ändern. Wir erfinden nicht alles neu, es wird kein Migrationstool oder ähnliches benötigt. Aber es liegt eine Menge Arbeit vor uns, die wir nicht in unserer Freizeit stemmen können.

In Gesprächen, per E-Mail, an Contao-Events und im Forum hat die Contao-Community immer wieder geäussert, dass es ein zukunftsfähiges Shopsystem für Contao braucht. Jetzt brauchen wir deine Mithilfe, um dafür zu sorgen.

Bereits jetzt gilt unser Dank den Mitgliedern des Isotope Circle, welche die Pflege von Isotope jedes Jahr mit ihrem Beitrag unterstützen.

Als Entwickler habe ich mich lange schwergetan, einen sinnvollen Release-Zyklus für Erweiterungen zu finden. Wir bewundern grosse Firmen, welche mit viel (Wo)man-Power, Geld und Marketing neue Produktversionen auf den Markt werfen. Wir wünschen uns, dieselbe Maschinerie auffahren zu können. Tatsächlich ist dies für Open Source Projekte kaum machbar und meist auch nicht sinnvoll.

Ich möchte den Versionsnummern weniger Priorität geben. Nicht grundlos hat Office für Mac 2021 die Versionsnummer 16. Der Info-Dialog in Photoshop 2024 zeigt Version 25.11. Versionsnummern beziehen sich auf API-Kompatibilität für Erweiterungen. Semantic Versioning soll sicherstellen, dass nur installiert wird, was auf meinem System auch funktioniert. Für Anwender:innen gilt: je grösser die Nummer, desto neuer das Produkt. Im Idealfall hat man immer das Neuste – oder eben das, was Composer aufgrund der Abhängigkeiten installiert.

Die Hürden, neue Versionen zu veröffentlichen, sind dank Composer viel kleiner geworden. Tools wie der Contao Manager oder trakked tragen mit dazu bei. Was ich seit geraumer Zeit bei anderen Erweiterungen bereits umsetze, soll in Zukunft auch bei Isotope passieren. Bugfixes werden veröffentlicht, sobald sie verfügbar sind. Eine Minor-Version gibt es, sobald eine neue Funktion eingebaut ist. Über Funktionen lohnt es sich dann auch zu schreiben. Und falls ein Feature die API-Kompatibilität für Erweiterungen ändert, gibt das gemäss SemVer eine Major- statt Minor-Version.