Drupal ist keine Religion. Technologie braucht Urteilskraft.

Wir arbeiten seit über 20 Jahren mit Drupal. In dieser Zeit haben wir gelernt, was das System leisten kann, wo seine Grenzen liegen und wann eine andere Lösung sinnvoller ist. Diese Erfahrung prägt unsere Entscheidungen – sie nimmt sie uns nicht ab.

Wer eine Technologie lange begleitet, erlebt auch, wie sich vermeintliche Gewissheiten verändern. Module werden unverzichtbar und später überflüssig. Distributionen versprechen, ganze Projekttypen abzudecken. Neue Architekturen lösen vertraute Ansätze ab und bringen eigene Schwierigkeiten mit. Drupal hat sich dabei mehrfach grundlegend verändert, ebenso unsere Arbeit damit.

Aus dieser Geschichte lässt sich einiges lernen. Vor allem lohnt es sich, bei jeder neuen Aufgabe erneut zu fragen, ob das gewohnte Werkzeug noch passt. Eine Entscheidung wird nicht dadurch besser, dass sie schon oft getroffen wurde.

Erfahrung zeigt sich im Abwägen.

Schulungen, Zertifizierungen und der Austausch in der Community schaffen eine wichtige fachliche Grundlage. Mit den Jahren kommt das Wissen hinzu, das sich erst im Betrieb bewährt: Welche Architektur lässt sich gut weiterentwickeln? Wo erleichtert ein Modul die Arbeit tatsächlich? Welche vermeintliche Abkürzung verursacht beim nächsten großen Update zusätzlichen Aufwand?

Solche Erfahrungen helfen, neue Lösungen genauer zu beurteilen. Uns interessiert, welches Problem ein Werkzeug besser löst und welche Folgen sein Einsatz für das Projekt hat. Zum Funktionsumfang kommen deshalb Fragen nach Wartbarkeit, Schnittstellen und dem Wissen, das ein Team für die weitere Entwicklung braucht.

Der gleiche Maßstab gilt innerhalb des Drupal-Ökosystems. Auch ein etabliertes Modul oder eine häufig empfohlene Architektur muss zur konkreten Aufgabe passen. Der verfügbare Funktionsumfang allein ist noch kein guter Grund, ihn einzusetzen.

Damit wir Alternativen kennen, nehmen wir uns Zeit dafür.

Bei E-Fork stehen rund 20 Prozent der Arbeitszeit unserer Entwickler:innen für Forschung, Weiterbildung, Experimente und eigene Entwicklung zur Verfügung. In dieser Zeit entstehen kleine Prototypen, wir erproben Frameworks und Werkzeuge und untersuchen, wie andere Content-Management-Systeme vertraute Probleme lösen.

Dabei geht es auch um Ansätze, die noch nicht reif für ein Kundenprojekt sind. Ein Experiment kann zeigen, dass eine Idee technisch überzeugt, aber für den verlässlichen Betrieb noch zu viel fehlt. Es kann ebenso deutlich machen, dass eine bestehende Lösung die Aufgabe bereits gut erfüllt. Beides hilft bei der nächsten Entscheidung.

Diese Arbeit gehört für uns zur Verantwortung einer spezialisierten Agentur. Wer Drupal empfiehlt, sollte die Alternativen gut genug kennen, um die Wahl begründen zu können.

Eine Abkürzung kann zum eigenen Produkt werden.

Wie wichtig dieser prüfende Blick ist, haben wir an unseren eigenen Lösungen erfahren. Wiederkehrende Anforderungen legen es nahe, immer mehr vorzufertigen: Aus einzelnen Modulen wird eine Distribution, die sich im nächsten Projekt nur noch installieren lässt. Zunächst spart das Zeit.

Mit jeder zusätzlichen Anwendung wächst allerdings die Verantwortung für die gemeinsame Grundlage. Releases müssen geplant, Abhängigkeiten aktualisiert und Migrationen vorbereitet werden. Dazu kommen Dokumentation und die Frage, wie sich neue Anforderungen mit früheren Entscheidungen vereinbaren lassen. Irgendwann bindet die Pflege der eigenen Komplettlösung mehr Arbeit, als ihre Wiederverwendung rechtfertigt.

Deshalb haben wir unseren Ansatz verändert. Das Wissen aus wiederkehrenden Projekten steckt heute in Developer Kits für Commerce, Hochschulen, Theater und Festivals. Sie bündeln bewährte Strukturen, Komponenten und Architekturentscheidungen, die wir für die jeweilige Aufgabe aufgreifen und anpassen.

So bleibt die Erfahrung wiederverwendbar, während sich das einzelne Projekt eigenständig entwickeln kann. Es muss nicht dauerhaft den Vorgaben und Release-Zyklen einer eigenen Distribution folgen.

Warum die Wahl weiterhin oft auf Drupal fällt.

Viele Plattformen, die wir entwickeln, müssen strukturierte Inhalte, komplexe Rechte und Rollen, redaktionelle Workflows und Mehrsprachigkeit zusammenbringen. Hinzu kommen Schnittstellen zu anderen Systemen. Für diese Kombination bietet Drupal eine Grundlage, die sich in unserer Arbeit über viele Jahre bewährt hat.

Seine Offenheit erlaubt es außerdem, Drupal als Teil einer größeren Architektur einzusetzen. Das System kann die Inhalte und redaktionellen Prozesse verwalten, während andere Komponenten deren Darstellung oder weitere Aufgaben übernehmen. Zusammen mit dem großen Open-Source-Ökosystem macht diese Flexibilität Drupal für viele unserer Projekte weiterhin zu einer guten Wahl.

Eine solche Entscheidung gilt jedoch für eine bestimmte Aufgabe unter bestimmten Bedingungen. Ändern sich diese, gehört auch die technische Grundlage wieder auf den Prüfstand. Manchmal genügt eine Anpassung innerhalb des Systems, manchmal ist ein anderer Ansatz sinnvoller.

Nach über 20 Jahren mit Drupal können wir seine Stärken gut einschätzen und ebenso klar benennen, wo wir anders vorgehen würden. Darin liegt für uns der Wert der Spezialisierung. Sie soll zu besseren Entscheidungen führen und genügend Freiheit lassen, bei der nächsten Aufgabe zu einem anderen Ergebnis zu kommen.