Es ist mehr als 10 Jahre her, da kamen im offiziellen Kernteam die ersten Gedanken auf, Typo3 nicht nur weiter, sondern von Grund auf neu zu entwickeln. Die Gründe dafür lagen und liegen jedem, der mal mit Typo3 gearbeitet hat – egal ob als Redakteur, Web Worker oder Entwickler – klar auf der Hand. Typo3 ist, wie viele andere PHP CM Systeme auch, historisch und hysterisch gewachsen und ursprünglich von Leuten entwickelt, die mit Programmierung und sauberer Softwarearchitektur, vornehm ausgedrückt, nicht so viel zu tun hatten. Wie bei so vielen PHP basierten Redaktionssystemen hat eine naive Begeisterung für Gefrickel Typo3 zu dem gemacht, was es heute ist – im positiven wie im negativen.
Ein großer Vorteil bei der Programiersprache PHP ist die Tatsache, das niemand verleitet wird, sich in großen Konzepten zu verlieren bevor er eine Zeile Code schreibt. Anfänger nicht, weil sie diese Konzepte nicht kennen und verstehen, PHP ihnen aber sofort Erfolgserlebnisse ermöglicht, Profis nicht, weil das seltsame PHP einem solche Pläne sehr schnell austreibt. PHP ist gemäß seiner Natur und seinem Ökosystem, dem LAMP Stack, die mach-mal-eben-fertig Sprache. Die Folge davon sind krautige und schlecht konstruierte Produkte mit fürchterlicher Architektur aber mit fertigen, funktionierenden Endnutzerfeatures.
So auch Typo3. Casper Skarhöj und seine Crew waren an guter Featureritis nicht wenig interessiert und frühe Ajax-UIs (bevor es den Begriff Ajax gab) und ausgefuchste State-Engines und Alleinstellungsmerkmale wie serverseitiges Copy/Paste und ähnlich abgefahrene Sachen machten Typo3 im Jahr 2001 zum Web-CMS der Wahl für große Webprojekte und Unternehmen. Ein flüchtiger Blick unter die Haube offenbart(e) jedoch extreme Fehltritte in der Entwicklung und die zahlreichen Versuche, diese zu korrigieren bzw. abzufedern. Notwendige aber fehlende Normaliserung bei solchen Dingen wie Versionierung, inkonsistente Modelle, Entities und Attribute offenbarten lange Flüge auf kurzer Sicht bei der Entwicklung von Features.
TypoScript, T3s eigene integrierte „Konfigurationssprache“ war damals schon und ist immer noch das klassische Beispiel des Inner Plattform Effekts und ein wahres Gruselkabinett an grundlegenden konzeptionellen Fehlern. „Oh, guck mal, ich kann Strings Parsen und PHP Arrays sind auch ganz toll – lass uns mal damit was bauen…“ – so oder so ähnlich muss Casper gedacht haben als er damals in seinen stillen Kämmerlein saß und dann anhub TypoScript zu entwickeln. Und auch die Typo3 Admin UI zeigten schon immer z.T. sehr schrullige bzw. sinnfreie Eigenschaften.
Akademische Spielerei und Alarmglocken
Mit Altlasten aufzuräumen war das Ziel des Projektes Typo3 5.0, das parallel auf einem getrennten Entwicklungszweig eine neue Ära des Open Source „Enterprise“ CMS einleuten sollte. Irgendwann hieß das Projekt Phönix und dann Neos und das Team kündigte schließlich an, erstmal ein neues Framework entwickeln zu wollen. Flow sollte das neue Wunderkind heißen.
Zu dieser Zeit gingen bei sehr vielen Leuten die ersten Alarmglocken an. Geschacher bei der Namenspolitik? Wolltet Ihr nicht erstmal etwas programmieren? Und auch nicht das ein brauchbares PHP Framework eine schlechte Idee ist, im Gegenteil. Allerdings gab es damals schon mit Symfony und CakePHP schon mindestens zwei hervorragende ausgereifte Frameworks in aktiver Entwicklung, die das Typo3/Phönix/Neos Team sich ohne Probleme zu eigen hätte machen können. ZendFW als drittes zeichnete sich am Horizont ab. Stutzig wurden die Profis aus dem Nicht-T3 Lager.
„Dependency Injection“ war das große Zauberwort, das zu der Zeit den Neos Entwicklern große Begeisterung auslöste. So toll war dieses Konzept, dass man gleich ein ganzes neues Framework darauf neu aufbauen wollte. Das Dependency Injection ein Entwurfsmuster ist, das man in jedweder Programmiersprache und Situation, wenn es denn nötig und angebracht ist, nach Lust und Laune und ganz ohne spezielles Framework implementieren kann, das wollte den Neos Entwicklern zu der Zeit wohl keiner sagen.
Fortan war die Flow Subdomain das Surfziel für alle, die im PHP Framework Markt wissen wollten, was ansteht. Die ganze Aufregung und den Aufwand des Flow/Neos Teams verstand niemand so recht und das Framework selbst schien obskur, aber Website war schick und zeigte regelmäßige Aktivität, und so fühlte man sich nicht deplaziert, wenn man dort mal nach dem Rechten sah.
Wir erfinden das Rad nicht neu. Ach nee, aber doch. So halb. Dann aber richtig. Oder nicht?
Das nächste was vom Flow Team zu hören war, war das man Doctrine als DBAL einsetzen wollte. Aha. Doctrine für sich ist schon ziemlich zweifelhafte Bloatware mit ernsten Inner Platform Anwandlungen (*1), aber immerhin wollte man hier das Rad nicht neu erfinden. Doctrine ohne DQL sollte es auch sein. Nur das Doctrine ORM wollte man benutzen. Mag man über Doctrine geteilter Meinung sein, die Idee, DQL außen vor zu lassen war zumindest eine kluge Entscheidung, so waren sich die Beobachter dieses Faszinosiums „Projekt Phoenix“ einig. Irgendwer beim Flow/Neos Team hatte begriffen, dass diese Abfragesprachen ebenfalls ein Inner Platform Problem sind, ganz ähnlich wie TypoScript.
So dachten wir alle jedenfalls.
Die Ernüchterung folgte auf dem Fuße, als das Flow/Neos Team anfing, seine eigene Abfragesprache auf PHP aufbauend zu entwickeln. FlowQuery. (Kein Scherz!) Ab hier war klar, das Flow und Neos, wenn überhaupt, nur in marginalen Szenarien seinen Einsatz finden würde und dass das Flow/Neos Team den Bezug zur Realität im CMS- und Webentwicklungsalltag verloren hatte. Wahrscheinlich durch zu viel Umgang mit Typo3. Das Neos Projekt war nicht eine Befreiung von Typo3, sondern die Fortsetzung der Typo3 Schrulligkeit mit anderen, extremeren Mitteln.
Das kann doch jetzt nicht sein, oder?
Dass das Flow/Neos Team sehenden Auges sich in Bloatware und Inner Plattform Gefrickel verlieren und in die Katastrophe segeln würde, konnte und wollte niemand so recht glauben – aber Neos war ja noch nicht fertig, und so hielt sich jeder vornehm mit einem Urteil zurück. Man soll ja nie nie sagen. Und wünschte sich nicht jeder ein frisches Typo3 ohne das wirre legacy Zeug?
Es sollte noch viele Jahre dauern bis Flow fertig war und noch ein paar Jahre bis Neos das Licht der Welt erblickte. Als dies endlich geschah, war bereits ein Zerwürfnis mit der Typo3 Crew passiert. Für den Kram hätte man es auch bei Typo3 belassen können. Recht hatten die Leute, die das feststellen mussten. Was mit einem ersten Release dann schließlich offiziell das Licht der Welt erblickte, ist so absurd, das es jeder Beschreibung spottet.
Die schier unüberschaubare Zahl von Fehlentscheidungen, die das Produkt Neos geformt haben, lassen sich kaum in Worte fassen. Ich versuch’s mal trotzdem:
Fehler #1: TypoScript (neuerdings in ‚Fusion‘ umbenannt)
TypoScript. Eine absurde, unfunktionale und fehleranfällige innere Plattform, die als Anfängerexperiment vielleicht interessant, aber im Arbeitsalltag nur hinderlich ist. Nett für Caspars erste Gehversuche mit PHP, aber ganz sicher kein Werkzeug für das professionelle Web. Was TypoScript soll, weiß kein Mensch. Und wenn einer meint es zu wissen, irrt er sich. Die Gelegenheit, TypoScript zu einer schrulligen Fußnote der Geschichte zu machen, würde sich keiner entgehen lassen. … Nun ja, das Neos Team offenbar doch. Das Neos TypoScript übernimmt und verwendet, ist das erste und deutlichste Signal für die mangelnde Alltagstauglichkeit von Neos. Das Neos TypoScript neuerdings in Fusion umbenannt hat, ändert an diesem Fehler garnichts.
Fehler #2: YAML
YAML ist ein Fehler? Wieso? YAML ist natürlich was feines. YAML für sich genommen ist eine hervorragende Sache. Allerdings wurde YAML zusätzlich zu TypoScript, FlowQuery, Eel und Fizzle eingesetzt. Das macht aus den 4 Fehlern gleich noch einen fünften.
Fehler #3: Flow
Flow. Wir machen ein neues PHP Framework. Ja, genau, das hat die Welt jetzt gebraucht. Zeitverschwendung, vielleicht? Macht doch einfach bei Cake mit, verdoppelt an einem Nachmittag die Teamstärke und helft etwas richtig feines zu bauen. Oder macht bei Symfony mit. Oder bei ZendFW.
Fehler #4: Doctrine
Wir bauen ein eigenes Framework, aber wir nehmen ein DBAL, das unsere Möglichkeiten eher kastriert als erweitert. Nochmal: Wenn ihr Doctrine nehmt, ist das nicht falsch, aber warum entwickelt ihr dann noch Euer eigenes Framework? Und wenn ihr auf Krampf komm raus Euer eigenes Framework entwickelt, warum nehmt ihr dann Doctrine?
Fehler #5: FlowQuery
Wir nehmen Doctrine, aber lassen DQL weg. Schön. Aber – Haha! – wir bauen unsere eigene Abfragesprache! Echt jetzt. Weil die Skript und Templatingsprache PHP sich ja auch so hervorragend als Interpreter für eigene Sprachen eignet. Siehe TypoScript. … Nicht zu lange darüber nachdenken, Hirnblutungsgefahr!
Fehler #6: Irgend ein eigenes Templating Monstrum, …
… dass aus 3-5 Konzepten und neuen eigenentwickelten Technologien besteht und für nix taugt. Eel, Fizzle, Fluid, und noch irgendwas. Ich hab‘ ehrlich den Überblick verloren. Und ich glaube wir können feststellen, dass auch keiner im Neos Team noch den Überblick hat. Das PHP selbst eine Templating Engine ist, wird hier, wie bei ungefähr 300 anderen PHP Amateurprojekten dieser Art, geflissentlich ignoriert. Echte, eventl. sinnvolle Templatingfeatures wie bei TAL sucht man übrigens vergebens.
Fehler #7: Packages (und wie man sie nicht implementiert)
Wir machen was ganz tolles für Persistenz, Migration und Auslieferung: Neos „Packages“. Und dann machen wir damit alles falsch, was man nur irgendwie falsch machen kann. Das geht so: Wir kippen unser gesamtes live Datenmodel mit einem abenteuerlichen und extrem zickigen Prozess in einen riesigen XML Blob, das man dann mit ein ganz wenig Konfiguration auf ein anderes System mit dem umgekehrten Prozess migrieren kann. Man kann auch Umschalten! Ein Paket ist z.B. Staging/Experiment, dass andere ist Live/Produktion. Ganz toll. … Nachdem wir ca. 5000 Mannstunden in dieses Monstrum gesteckt haben, können wir allerdings immer noch nicht vernünftig Diffen und Syncen. Beziehungsweise gar nicht. Und Assets muss man nach wie vor von Hand verschieben. Genau wie bei WordPresss. Oder jedem anderen, fertigen, existierenden, funktionierenden, getesteten, erprobten PHP CMS auf diesem Planeten. Nur komplizierter. Ist das nicht toll? So kann man mehr Stunden buchen! Aber wir sind professionell! Echt jetzt!
Fehler #8: Composer
Ohne Composer geht nix. Das wirkt professioneller. Wer schon mal Neos ohne Composer und reinem frischen Linux zum laufen gekriegt hat, möchte sich bitte bei mir melden. Ich werd‘ wahrscheinlich nie etwas hören. Dependancy Management und Composer machen Sinn, keine Frage. Wenn man sauber entwickelt hat. Wer das nicht tut, sollte bei Zip-Dateien und manuellem FTP bleiben. Sonst wird’s schlimmer, nicht besser. Siehe Neos.
Fehler #9: Frontend Editing
Weil unser System ganz einfach, sauber und fehlerfrei ist, und unser Templating richtig überschaubar und schön vertikal mit Persistenz, Ajax und Co. integriert ist, klappt auch Frontend Editing richtig schön stressfrei. Selbst über das von den Kernentwicklern gebaute Demotemplate hinaus. … *Gelächter im Publikum* *Tusch von der Band*
Kommen wir hier mal zum traurigen Ende
Die Liste an Fehltritten und Fehlentscheidungen könnte doppelt so lang sein, aber ich denke, ich habe deutlich gemacht warum das Neos Projekt, meiner Bescheiden Ansicht nach, eine extreme Enttäuschung, komplette Zeit- und Resourcenverschwendung und damit keine gute Sache ist. Ca. 10 Jahre wurden für dieses Projekt verschwendet, es wurden – mal wieder – elementarste architektonische und konzeptionelle Fehler gemacht und Funktionen, nach denen es in der PHP Welt dürstet, wurden wieder nicht implementiert.
Um Typo3 tut es mir leid. Nicht das ein Verlust von T3 ein großer wäre. Aber T3 hatte eine solide Markenpräsenz mit den Entscheidern und Geldgebern im deutschsprachigen Raum. Und einen gesunden Zweitmarkt für Dienstleistungen und Entwickler. Ein Markenprodukt mit solidem Mindshare, sauber betreut duch die T3 Foundation, die sich auf das konzentriert hat, was sie am besten kann: Ein großes Dach für die gesamte T3 Community zu bieten.
Keine Frage, ein professionell umgesezter Neubau hätte T3 in den Olymp der Redaktionssysteme katapultiert, und zwar auch über den deutschen Sprachraum hinaus. Davon bin ich überzeugt. Ein Großumbau von T3 ist nach wie vor dringend nötig. Allerdings glaube ich, das selbst das T3 Classic Projekt, so deutlich man sich jetzt auch vom Neos Team getrennt hat, hat Schaden genommen hat und, im Hinblick auf den Platzhirsch WordPress, wahrscheinlich auch nicht mehr die Kurve wird kriegen können.
Im Moment ist es tatsächlich sinnvoller WordPress – das eine ähnlich krautige Architektur vorzuweisen hat – zu forken und von Grund auf neu zu strukturieren. Neos wird in Obskurität versinken, da besteht für mich kein Zweifel – es sei den es wird komplett neu gebaut und kann mit einer Hauruck Aktion verlorenes Vertrauen wieder gut machen. Das ist allerdings wohl unwahrscheinlich.
Typo3 wird sich eventuell auch nie ganz von dem verlorenen Neos-Jahrzehnt erholen. Schade drum. Ich habe mich auf ein sauberes neues T3 mit n-dimensionalem Rechtemanagement, sinnvoller Backend-UI, professionellem Workflow und vernünftigen Daten/Typenmodell inkl. visuellem Backend Modeller und ähnlichem schicken Zeug gefreut. Und auch seit der Ankündigung von T3 V5 darauf gewartet. Leider vergeblich.
Fußnoten:
*1: Warum benutzt eigentlich keiner PDO? Und ich meine nur PDO! PDO ist die perfekte Lösung für all diese Sachen und jeder kann PDO in ungefähr 5 Minuten lernen. Und PDO ist eine C Extension für PHP – ergo: Richtig schön schnell. Und PDO ist schon fertig! … Ich versteh‘ es nicht.