Drupal 9 erscheint 2020, und schon ein Jahr später endet der Support für die aktuelle Version 8. Ist Drupal 8 nun eine “lame duck” geworden, auf die man nicht mehr setzen sollte?
Auf seiner traditionellen “Driesnote” bei der Drupal Europe in Darmstadt hat Drupal-Gründer Dries Buytaert verkündet, dass die kommende Version 9 von Drupal definitiv im Verlauf des Jahres 2020 erscheinen wird. Gleichzeitig wurde die kontrovers diskutierte Entscheidung veröffentlicht, dass die aktuelle Version 8 von Drupal nur noch bis Ende 2021 supported werden wird. Grund ist das Auslaufen der Unterstützung für die von Drupal 8 verwendete Version von Symfony, welche ebenfalls für das Ende des Jahres 2021 angekündigt ist. Damit wird Drupal 8 noch genau so lange supported wie Drupal 7, dessen Unterstützung wiederum verlängert wird und dann ebenfalls zum Jahresende 2021 ausläuft. Mit dieser Entscheidung bricht Drupal massiv mit der bisherigen Tradition. Bisher war es so, dass eine Drupalversion immer bis zum Erscheinen der übernächsten Version supportet wurde. Sprich, Drupal 5 verlor seine Unterstützung beim Erscheinen von Drupal 7, die Version 6 war ab dem Release-Datum von 8 “end of life”. Nun wird es erstmals so sein, dass der Support sowohl für den Vor-Vorgänger als auch den direkten Vorgänger der neuen Version enden wird, nachdem das aktuelle Release erst ein gutes Jahr am Markt sein wird.
War es das für Drupal 8?
Websitebetreiber, die Drupal entweder einsetzen oder den Einsatz planen, werden diese Ankündigung erst einmal mit Schrecken vernehmen. Was bedeutet das für das D8-Projekt, das gerade im Bau ist? Muss es in nur 3 Jahren schon wieder ersetzt werden? Was bedeutet das für ein Projekt, bei dem Drupal 8 eingesetzt werden soll? Macht es jetzt überhaupt noch Sinn, damit anzufangen, oder wartet man lieber auf Drupal 9?
Auch für Dienstleister, die mit Drupal arbeiten, wird die Situation schwierig. Denn sie müssen genau diese Ängste und Vorbehalte nun adressieren, wollen sie nicht anderthalb Jahre lang warten, bis die Kunden sich wieder “trauen”, auf Drupal zu setzen. Hier hilft daher nur genaue Aufklärung, was diese Entscheidung für die Weiterentwicklung Drupals wirklich bedeutet, und warum sie letztlich gar nicht so dramatisch sein dürfte.
Drupal 7 vs. Drupal 8 – Unterschiede in der Produktentwicklungsstrategie
Um einschätzen zu können, was ein Wechsel von Drupal 8 auf 9 bedeuten könnte, muss man sich erst einmal vergegenwärtigen, was ein Wechsel von D7 auf D8 heißt. D8 war ein fast vollständiger Rewrite des Systems, es hat mit D7 also nur sehr wenige technische Gemeinsamkeiten. Das Ziel beim Wechsel von D7 nach D8 war es unter anderem, Altlasten loszuwerden und auf neue, quelloffene Frameworks wie Symfony zu setzen.
Das heißt: außer dem Namen und gewisser Konzepte haben Drupal 7 und 8 eher wenig gemein, es sind eigentlich zwei unterschiedliche Content-Management-Systeme. Entsprechend war auch ein “Upgrade” von D7 auf 8 praktisch unmöglich. Wer von D7 auf D8 wechseln wollte, kam an einem kompletten Relaunch seiner Website oder Applikation nicht vorbei.Nun ist die Strategie, alte Zöpfe abzuschneiden und sich voll auf neue, effizientere Technologien zu konzentrieren aus Produktentwicklersicht sehr attraktiv. Enterprise-Nutzer indes, die extrem hohe Summen in sehr komplexe Projekte investieren, die sich über den Zeitraum von Jahren hinweg amortisieren müssen, haben ein großes Problem mit dieser Vorgehensweise. Die Zeit- und Geldmittel, die in solche Projekte fließen, sind einfach zu groß, als dass man das Investment alle paar Jahre komplett wiederholen könnte. Enterprise-Kunden benötigen vielmehr Systeme, die sich graduell entwickeln, ohne dabei das Abstoßen von Altlasten oder das Einsetzen neuer Technologien außen vor zu lassen.
Genau diesem Bedürfnis trägt Drupal seit der Version 8 Rechnung. Während der Kern der Vorversion 7 seit deren Erscheinen im Jahr 2011 praktisch unverändert geblieben ist und nur noch Sicherheitsupdates erhält, erhält Drupal 8 seit seinem Release Ende 2015 in einem Halbjahreszyklus tatsächlich auch nennenswerte Upgrades und Veränderungen im Kern. Das heißt: während D7 seit Erscheinen mehr oder weniger “eingefroren” ist, entwickelt D8 sich graduell weiter und kommt damit genau den eben angesprochenen Bedürfnissen der Enterprise-Kunden entgegen. Das lässt sich sogar an der Nomenklatur der Versionsnummer ablesen. Während Drupal 7 immer direkt nach der Releasenummer hochzählt (7.59 mit Stand April 2018), hat Drupal 8 eine dreiteilige Versionsnummer (8.5.4 mit Stand vom 6. Juni 2018). Nach der Releasenummer steht die zweite Ziffer nun für ein Upgrade (also funktionale Änderungen am Kern), und erst die dritte Nummer kennzeichnet Updates (also lediglich Verbesserungen und Fixes).
Es gibt also seit Drupal 8
-ebenfalls Patch-Releases (die eben angesprochenen Sicherheitsupdates und Detailverbesserungen, wie schon in Drupal 7 auch, und die nun durch die dritte Ziffer in der Versionsnummer gekennzeichnet sind)
-nun aber neu auch Feature-Releases (manchmal auch als Minor Releases bezeichnet), die das System tatsächlich um neue Funktionen erweitern, und für die die zweite Ziffer in der Versionsnummer steht
Letztere sind besonders interessant, denn sie adressieren das Problem von “Upgrade-Schwellen”.
Upgrade-Schwellen
In jeder Software, die neue Versionen bekommt, existieren “Upgrade-Schwellen” unterschiedlicher Höhe. Wie beschrieben, ist die Upgrade-Schwelle zwischen D7 und D8 praktisch unüberwindbar – man kann sie nur umgehen durch einen Produkt-Relaunch und einer Migration. Zwar ist beispielsweise der Migrationsaufwand hier immer noch geringer als von einem Drittsystem zu Drupal – aber nichtsdestotrotz sind die Aufwände sehr groß. Das Ziel bei der Weiterentwicklung von Drupal ab Version 8 war es daher von Beginn an, beim nächsten Major-Release (also der Sprung von 8 nach 9) diese Upgrade-Schwelle so niedrig wie möglich halten zu können. Aber wie ermöglicht man das?
Die technische Entwicklung bleibt nicht stehen, und komplexe Software wie Drupal es ist, muss dieser Entwicklung Rechnung tragen, um am Markt bestehen zu können. Technische Weiterentwicklung bedingt aber auch Inkompatibilitäten zu früheren Lösungen, die es dann auszuräumen gilt.
Wie löst Drupal das? Fakt ist, dass Upgrade-Schwellen sich nicht vermeiden lassen, will man das System auf dem aktuellen Stand des technisch möglichen halten. Die Produktentwicklungstrategie seit Drupal 8 ist daher, die Schwellen nicht als einzelne hohe Hürde zwischen den Major-Releases zu platzieren, die entweder gar nicht oder nur mit immensen punktuell anfallenden Kosten bewältigt werden kann.
Statt dessen werden nun viele, dafür aber relativ niedrige Schwellen innerhalb des Major-Release platziert. Wie angesprochen, erscheint halbjährlich eine neue Version von Drupal 8, bei der sich die zweite Ziffer in der Versionsnummer ändert (z.B. von 8.4.x auf 8.5.x). Diese “Feature-Releases” stellen nun die Upgrade-Schwellen dar.
Was heißt das nun für den Produktiveinsatz?
Da seit Drupal 8 die Upgrade-Schwellen innerhalb des Major-Release verortet sind, und nicht mehr nur zwischen den Major-Releases, entstehen bei Drupal 8 tendenziell etwas höhere Wartungsaufwände als beim Drupal 7-Betrieb. Außerdem ist der “Druck” höher geworden, das System sauber zu implementieren und auch regelmäßig instand zu halten. Zwar laufen Upgrades zwischen zwei Feature-Releases innerhalb von Drupal spätestens seit Version 8.3.x relativ problemlos durch, sofern eine Seite solide und gemäß der Coding-Standards für Drupal entwickelt wurde. Wenn das System allerdings mangelhaft implementiert ist oder auch wartungstechnisch vernachlässigt wurde, ist die Wahrscheinlichkeit jetzt noch höher als bei Drupal 7, in ernste Probleme zu geraten und erhöhte Wartungsaufwände tragen zu müssen, wenn dann doch irgendwann ein Upgrade auf die aktuelle Version versucht wird.
Das heißt also für Betreiber wie für Dienstleister: sie müssen mehr noch als bei Drupal 7 darauf achten, die Aufwände für den Betrieb und die regelmäßige Aktualisierung eines Drupal 8 Projektes einzukalkulieren, und sich auch disziplinieren, diese Upgrades durchzuführen, respektive auf Kundenseite einzufordern. Denn nur so ist gewährleistet, dass das Projekt von der Produktentwicklungsstrategie Drupals seit der Version 8 profitiert.
Und die guten Nachrichten?
Auszahlen wird sich diese Strategie bei einem neuen Major-Release, also beim Erscheinen von Drupal 9. Während die Upgrade-Schwelle zwischen Drupal 7 und Drupal 8 praktisch unüberwindbar war, wird sie zwischen 8 und 9 sehr viel niedriger liegen. Tatsächlich lautet das Versprechen von Drupal-Gründer Dries Buytaert, dass das Upgrade einer stets gepflegten und sauber umgesetzten Drupal 8 Instanz in der letzten Feature-Release-Version auf Drupal 9 nur unwesentlich komplexer und aufwändiger ausfallen wird, als es die Upgrades zwischen zwei Feature-Releases von Drupal 8 gewesen sind.
Ob das in der Praxis so funktionieren wird, muss sich natürlich erst erweisen. Es gibt Risiken, die man nicht ignorieren darf, etwa beim Einsatz von Erweiterungen (Contrib-Modulen) von Drittentwicklern, wenn diese auf veralteten Programmierschnittstellen (APIs) aufbauen.
Insbesondere bei großen Webprojekten mit vielen Contrib-Modulen kann hier beim Versionswechsel durchaus Anpassungsbedarf bestehen, der über ein “einfaches” Upgrade hinaus geht.
Aber sicher ist: Drupal 8 wird nach Drupal 9 upgradebar sein, denn dieses Ziel war bei der Entwicklung von Drupal 8 von Beginn an eine zentrale Vorgabe. Somit wird ein Wechsel zwischen dem aktuellen und dem kommenden Major-Release definitiv mit einem Bruchteil der Kosten möglich sein, der in der Vergangenheit für einen Wechsel von D7 nach D8 angefallen ist – denn hier brauchte der Kunde im Regelfall eine komplett neue Website, und alle Individualleistungen in Bezug auf Informationsarchitektur, Layout, Design, abgebildete Arbeits- und Datenverarbeitungsprozesse etc., die zuvor für das alte System erbracht wurden, und die die eigentlichen Kosten eines auf Open Source Software basierenden Webprojekts darstellen, mussten erneut erbracht werden.
Und dies ist die zentrale Botschaft für alle, die das Erscheinen von Drupal 9 nicht ohnehin zum Anlass nehmen wollen oder können, ihr Projekt komplett zu erneuern: sie können den Relaunch schon jetzt auf Drupal 8 durchführen, und müssen später lediglich ein Systemupgrade von D8 nach D9 vornehmen, ohne die Individualleistungen alle erneut implementieren zu lassen. Da die Individualleistungen im Regelfall das größte Investment bei einem Webprojekt sind, kann dieses Investment somit künftig beim Upgrade auch komplexer Projekte von D8 auf D9 weitgehend erhalten bleiben und geht nicht verloren, wie es beim Wechsel von Drupal 7 auf 8 noch unvermeidlich war.
Selbst wenn also gesteigerte Aktualisierungsaufwände beispielsweise durch die Notwendigkeit der Anpassung von Drittmodulen entstehen, weil diese noch nicht auf die aktuellen Programmierschnittstellen abgestimmt sind, so ist das immer noch ein um viele Größenordnungen geringeres Investment, als ein erneuter Relaunch. Der Gewinn aus diesem Investment ist jedoch immens. Denn durch das Upgrade auf D9 bleiben nicht nur die für D8 entwickelten Individualleistungen weitgehend erhalten, sondern der Kunde kann das System versionsübergreifend sogar deutlich länger betreiben, als es je zuvor mit Drupal möglich war. Dies ist insbesondere für geschlossene Systeme wie beispielsweise Intranets oder interne Webapplikationen interessant, da deren Erneuerungszyklen in der Regel deutlich weiter auseinanderliegen als bei öffentlichen Websites, wo in der Regel schon nach 4 bis 6 Jahren Betriebszeit zumindest über einen “Facelift” nachgedacht wird.
Das Major Release als psychologische Hürde
Rein technisch klingt das alles erst einmal großartig, und es ist genau die Strategie, die Enterprise-Kunden, die über einen Zeitraum von vielen Jahren Planungssicherheit benötigen, bei einem CMS-Framework erwarten. Dennoch ist ein Wechsel der Versionsnummer immer noch eine Hürde – hier insbesondere eine psychologische. Vor allem Kunden, die mit der Problematik des Wechsels von D7 nach D8 vertraut sind, werden wie eingangs bemerkt große Vorbehalte und Bedenken haben, neue Drupal 8-Projekte zu beginnen, wenn sie glauben, das Investment in die erforderlichen Individualleistungen dann in nur wenigen Jahren wiederholen zu müssen. Diese Vorbehalte können nur ausgeräumt werden, wenn sie verstehen und nachvollziehen können, dass der Wechsel von Drupal 8 auf 9 eine um ein Vielfaches niedrigere Upgrade-Schwelle bedeuten wird, welche Methoden verwendet werden, um das zu erreichen, und dass es eben sehr wichtig ist, in die hierfür notwendigen Betriebs- und Wartungsaufwände zu investieren. Dies sollte zwar sowieso selbstverständlich sein, wenn man sein D8-Projekt ordentlich betreibt. Es ist aber praktisch alternativlos, wenn man sein D8-Projekt perspektivisch unter D9 weiterbetreiben möchte.
Fazit
Der verkürzte Lebenszyklus von Drupal 8 klingt erst einmal wie ein großer Nachteil für die Konkurrenzfähigkeit von Drupal. Dies werden Mitbewerber sicherlich auch nutzen, indem sie die Situation unvollständig darstellen werden, um Angst und Zweifel beim Kunden gegenüber seiner Präferenz für Drupal zu erzeugen. Jedoch ist die Situation bei Lichte besehen gar nicht so dramatisch. Durch die bereits mit Drupal 8 eingeführte Entwicklungspolitik, Upgrade-Hürden nicht mehr zwischen zwei Major-Releases zu platzieren, sondern diese Schwelle auf innerhalb eines Major-Releases in regelmäßigen Abständen veröffentlichte Feature-Releases zu verteilen, bleibt der Kern von Drupal 8 technisch nicht “eingefroren”, wie es bei der Vorgängerversion der Fall war. Vielmehr entwickelt sich Drupal 8 graduell bereits in die Richtung von Drupal 9 weiter. Softwarearchitektonische Entscheidungen, die für Drupal 9 getroffen werden, werden direkten Einfluss auf die Weiterentwicklung von Drupal 8 haben, und es wird mit Sicherheit sehr viel Energie und Einsatz darauf verwendet werden, den letztlichen Übergang von einer Version zur anderen so komfortabel und einfach wie möglich zu machen. Wer auf Drupal 9 warten kann, kann dies natürlich tun. Wer nicht darauf warten kann, sollte nach wie vor auf Drupal 8 bauen und sich vergegenwärtigen, dass die Entwicklungspolitik von Drupal ja genau hierfür geändert wurde: Verlässlichkeit, Langfristigkeit, Upgradefähigkeit. Alle drei unverzichtbare Aspekte im Business-Bereich und damit starke Argumente dafür, warum Drupal im Enterprise-Sektor immer beliebter wird.
Ein Beitrag von Fabian Lorenzen, erdfisch Geschäftsführer
erdfisch ist einer der führenden Drupal Experten im deutschsprachigen Raum und Organisator der ersten Drupal Business & Community Days. erdfisch konzipiert und realisiert Web-Projekte für Unternehmen und Organisationen und optimiert damit interne Prozesse und die Präsenz im Internet. Ihre Leistungsfähigkeit hat erdfisch in vielen Projekten erfolgreich unter Beweis gestellt. erdfisch feierte im Jahr 2015 sein zehnjähriges Firmenjubiläum.
Firmenkontakt
erdfisch; Stefan Auditor, Frank Holldorff & Fabian Lorenzen GbR
Frank Holldorff
Hans-Bunte-Str. 6
69123 Heidelberg
+49 6221 751 560 0
+49 6221 751 560 99
frank.holldorff@erdfisch.de
http://erdfisch.de
Pressekontakt
erdfisch; Stefan Auditor, Frank Holldorff & Fabian Lorenzen GbR
Anja Rietzel
Hans-Bunte-Str. 6
69123 Heidelberg
+49 6221 751 560 0
+49 6221 751 560 99
presse@erdfisch.de
http://erdfisch.de