Die Zukunft begann wie so oft mit einem Problem. Vor etwa sechs Jahren hatte sich bereits eine schnell wachsende Schar von Entwicklern um den Projektgründer Kasper Skårhøj versammelt, die ihre eigenen Ideen für die Weiterentwicklung von TYPO3 beisteuern wollten. Kasper hatte alle Hände voll zu tun, die neuen Beiträge in die TYPO3-Codebasis einzupflegen, denn zu der Zeit hatte er die alleinige Hoheit über das CVS-Repository.

Kasper Skårhøjs größte Sorge aber war, dass einer der vielen Entwickler durch unbedachte Änderungen Fehler an anderer Stelle einschleusen könnte. Denn lange Jahre hatte nur der Meister selbst einen umfassenden Überblick über die Zusammenhänge im TYPO3-System.

Zu dieser Zeit überlegte eine kleine Gruppe, wie man den TYPO3-Kern modernisieren und weiter modularisieren könnte, um die Zusammenarbeit zu erleichtern und den Einbau neuer Funktionen, wie etwa des Digital Asset Managements (DAM), zu ermöglichen. Nach mehreren Treffen war die Entscheidung für eine grundlegende Überarbeitung der Codebasis gefallen. Der neue TYPO3-Kern sollte es auch längerfristig ermöglichen, komplexe Funktionen und Erweiterungen mit einer Vielzahl von Entwicklern sicher zu implementieren. Features wie Versionierung, Workspaces und Lokalisierung sollten von Anfang an in das neue Design einfließen, um Programmierschnittstellen aus einem Guss zu gewährleisten.

Der ursprüngliche Plan der Kernentwickler, den bestehenden TYPO3-Code umfassend umzubauen, wurde nach den ersten Versuchen aufgegeben. Durch das Fehlen von geschützten Methoden in PHP4 war die TYPO3-API löchrig geworden und im Laufe der Zeit sprachen hunderte Erweiterungen die Interna von TYPO3 direkt an, führten selbst Systemabfragen in der Datenbank durch und umgingen so die dafür vorgesehenen Schnittstellen. Da große Sprünge in einer solchen Ausgangslage nicht möglich waren, entschieden sich die TYPO3-Kernentwickler für ein komplette Neuentwicklung des CMS.

Die ersten Schritte waren mühselig, galt es doch, von Anfang an etwas besseres zu schaffen als die bestehende Lösung. Die höchste Priorität lag daher auf einer neu durchdachten Architektur und vor allem auch einer neuen Art zu entwickeln, um die aktuellen Probleme in einer zukünftigen Version nicht zu wiederholen. Die vielleicht wichtigste Entscheidung auf diesem Weg war, sich nicht entscheiden zu müssen – jedenfalls nicht endgültig. Durch agile Entwicklungsmethoden wie testgetriebene Entwicklung, Refaktorierung und kontinuierliche Integration waren selbst größere nachträgliche Änderungen an Basiskonzepten leicht und vor allem sicher möglich.

Eine wichtige Einsicht, die die Entwickler bei ihrer Arbeit im TYPO3-Projekt erlangten: Manuelle Arbeit skaliert schlecht. Eine Binsenweisheit vielleicht – aber eine, die nicht jedem jederzeit auf den ersten Blick ersichtlich ist.

Manuelle Code-Reviews, wie sie die TYPO3-Kernentwickler 2006 für Extensions einführten, zeigen sehr schnell ihre Grenzen auf: Ein Team aus fünf Entwicklern hätte schon damals ein knappes Jahr benötigt, um alle veröffentlichten Versionen zu begutachten. Diese Erkenntnis lässt sich auf viele weitere Bereiche übertragen und so stand für das Entwicklerteam der Entschluss fest, durch ausgiebige Recherche und durchdachtes Anwendungsdesign möglichst grundlegende, sich wiederholende Probleme beim Anwender zu vermeiden. Neben Flexibilität und Interoperabilität geht es dabei auch um die Vermeidung unnötiger Arbeit.

Ein spezielles Framework verlagert beispielsweise Sicherheitsbelange an einen zentralen Ort, der durch TYPO3 gesteuert wird. Ein Extension-Entwickler muss nun mutwillig die Sicherheitsvorkehrungen umgehen, um eine Erweiterung zu produzieren, die Anfällig gegen die üblichen Probleme wie XSS, SQL-Injection oder Cross-Site Request Forgery ist. Alleine diese Vorkehrung macht bereits viele Code-Reviews überflüssig.

Derartige Mechanismen haben einen hohen Nutzen für die Anwender (nämlich weniger Arbeit und sichere Websites), bedeuten aber gleichzeitig einen größeren Aufwand bei der Entwicklung des Frameworks. Und so waren die letzten Jahre nicht nur für die Phoenix-Entwickler, sondern auch für die Community eine lange Durststrecke. Denn ein Großteil der Funktionalität der aktuellen 4er-Version von TYPO3 machen Codeteile aus, die ohne die Benutzeroberfläche nicht sichtbar wären.

Ein Blick auf die beiden Screenshots auf der vorherigen Seite verdeutlicht das Problem: Die Entwicklung der oberen Website dauerte etwa zehn Stunden, für die untere waren knapp drei Jahre nötig. Erkennen Sie den Unterschied? Nein? Kein Wunder, denn sie sind optisch zwar identisch, die erste Website ist aber ein Klick-Dummy, die zweite basiert auf FLOW3.

Eine solide Basis ist nicht auf den ersten Blick zu erkennen: TypoScript, Content Model, Benutzerauthentifizierung, Caching, Content Repository und Plugin-Unterstützung sind allesamt keine Bereiche, die man sich im Browser mal eben ansehen kann – genau diese müssen aber entwickelt werden, bevor es sich lohnt, ein grafisches Benutzerinterface zu implementieren. Entwickler wissen, dass sehr unterschiedliche Wege und Qualitätsstandards zu denselben sichtbaren Ergebnissen führen können. Wenn man auf einem Eisberg eine Weile schwimmen will, lohnt es sich aber eine solide Basis zu schaffen, und nicht die nächstbeste Eisscholle zu kapern.

Der Eisberg, auf dem TYPO3-Phoenix [1] errichtet wird, ist mittlerweile tragfähig. Und da das grundlegende Motto des TYPO3-Projekts lautet: „Inspiring People to Share“, haben die Phoenix-Entwickler diese Basis (ein vollwertiges PHP-Framework) unter dem Namen FLOW3 [2] auch anderen PHP-Entwicklern zugänglich gemacht. Derzeit liegt der Arbeitsschwerpunkt der 5.0-Entwickler auf der Benutzeroberfläche, denn sichtbare Ergebnisse sind für die Akzeptanz des Projekts enorm wichtig.

Versionen und Codenamen

Aktuell gibt es zwei Entwicklungszweige: TYPO3 4.x und TYPO3 5.x. Der Codename für die nächste TYPO3-Generation, also der 5er-Zweig, lautet „Phoenix“. Die nach den jeweiligen Sprints veröffentlichten Pakete entsprechen im Funktionsumfang noch nicht der endgültigen Version 5.0, sondern werden als „TYPO3 Phoenix Sprint Release“ bezeichnet. Parallel zu den Phoenix-Releases werden neue Versionen des zugrunde liegenden Frameworks FLOW3 freigegeben.

Ermutigt durch den erfolgreichen Einsatz der agilen Entwicklungsmethoden für FLOW3 haben die Phoenix-Entwickler kürzlich damit begonnen, das Phoenix-Projekt mit Methoden aus der Scrum-Werkzeugkiste in regelmäßigen Sprints weiterzuentwickeln [3]. Davon versprechen sie sich vor allem zweierlei:

1. Fokussierung auf die Funktionen, die aktuell den Anwendern den größten Nutzen bringen.
2. Regelmäßige Veröffentlichung von sichtbaren Ergebnissen in Form einer Demo-Site und herunterladbarer Paketen.

Die ersten Sprint-Releases sind mit der Funktionsvielfalt von TYPO3 v4 natürlich nicht zu vergleichen – es wird noch eine Weile dauern, bis es eine ähnliche Menge an Erweiterungen für TYPO3 v5 gibt. Dennoch wird Phoenix von Anfang an Nutzen bringen und sich anfangs besonders in Großprojekten beweisen: Erfahrungsgemäß sind es nämlich die größeren Anwendungen, die wenige Erweiterungen „von der Stange“ verwenden und stattdessen spezialisierte Plugins benötigen, die individuell für das Projekt entwickelt werden. Genau hier glänzt die nächste Generation von TYPO3 schon von Beginn an, denn sie basiert auf einem PHP-Framework, das speziell für Anforderungen an Enterprise-Applikationen entworfen wurde.

Während das Phoenix-Team in unwegsamem Gelände Neuland erforscht, widmet sich das 4er-Team um Releasemanager Benjamin Mack den berühmten letzten 20 Prozent: TYPO3 4.4 wird insgesamt aufgeräumter und vollständiger wirken und weiterhin als umfangreiches Enterprise-CMS seinen Dienst tun [4]. Mit Extbase [5] und Fluid [6] lassen sich bereits jetzt Erweiterungen entwickeln, die viele der Techniken und Schnittstellen verwenden, die für Phoenix entworfen wurden.

Die Rahmenbedingungen für einen sanften Übergang von Version 4 zu Version 5 sind damit gesetzt. Und dennoch beginnt die Zukunft für viele TYPO3-Anwender mit einem Problem: Wann lohnt sich der Umstieg auf die neue Version? Glücklicherweise haben die Phoenix-Entwickler auch darauf bereits eine Antwort gefunden: Nutzen Sie doch einfach beide – die Feature-Liste wird Ihnen zeigen, welche Version für Ihr Projekt am besten geeignet ist.