Zusammenarbeit in der Drupal-Community: Wettbewerber, die kooperieren

Drei Module, drei Maintainer, ein Gespräch — und warum das weit über Open-Source hinausgeht.

Es gibt Momente in einer Community, die zeigen, wofür sie wirklich steht.

Shibin Das, Maintainer von FlowDrop, hat sich kürzlich mit den Modul-Maintainern Jürgen Haas (ECA) und Randy Kolenko (Maestro) zusammengesetzt. Drei Menschen auf drei verschiedenen Kontinenten, jeder mit seinem eigenen Modul, seiner eigenen Nutzerbasis, seiner eigenen Roadmap. Technisch gesehen: Konkurrenten im selben Bereich. In der Praxis: Mitstreiter.

Ihr Thema war Orchestrierung in Drupal. Ihr Befund: weniger Überschneidungen, als die Außenwelt gewöhnlich annimmt — und mehr Komplementarität, als selbst sie erwartet hatten. Und eine gemeinsame Frage, die sie seitdem begleitet: Wie lässt sich eine gemeinsame Grundlage schaffen, damit Nutzende nicht mehr zwischen Modulen wählen müssen, sondern sich einfach fragen können, was sie eigentlich bauen wollen?

Das ist keine Kleinigkeit. Es bedeutet, Energie in etwas zu investieren, das dem eigenen Projekt nicht unmittelbar nützt. Es erfordert Vertrauen, Offenheit und die Bereitschaft, die eigene Arbeit im Kontext zu sehen — nicht im Gegensatz zu anderen, sondern neben ihnen.

Die andere Geschichte, die gerade erzählt wird

Wer in der Drupal-Community aufmerksam verfolgt, was gerade passiert, wird eine zweite, parallele Debatte bemerkt haben: darüber, wie Unternehmen, die auf Open Source aufbauen, miteinander konkurrieren wollen.

Dries Buytaert, der Gründer von Drupal, hat seine Position klar formuliert: Unternehmen, die vom Open-Source-Ökosystem profitieren, tragen eine Verantwortung — gegenüber dem Projekt, der Community und dem Ökosystem insgesamt. Auf Kosten anderer zu wachsen, statt gemeinsam mit ihnen zu wachsen, bricht den sozialen Vertrag, auf dem Open Source beruht.

Man muss nicht jedem Detail dieses Arguments zustimmen. Aber die Grundfrage ist berechtigt: Wie wollen wir miteinander konkurrieren?

Was FlowDrop, ECA und Maestro zeigen

Das Gespräch zwischen Shibin Das, Jürgen Haas und Randy Kolenko ist keine Absage an den Wettbewerb. Es ist ein Beispiel dafür, wie Wettbewerb aussehen kann, wenn das Ökosystem und die Bedürfnisse der Nutzenden an erster Stelle stehen — nicht Marktanteile.

FlowDrop konzentriert sich auf gezielte Orchestrierung — gut geeignet für Use Cases, bei denen Events aus dem Drupal-Core direkt verarbeitet werden sollen, ohne ein komplexes Framework vorauszusetzen. ECA (Event-Condition-Action) liefert eine leistungsstarke regelbasierte Engine für anspruchsvolle Workflows. Maestro bringt visuelles Prozessmodellieren und strukturiertes Aufgabenmanagement mit. Drei eigenständige Ansätze, die sich in der Praxis häufig ergänzen.

Die Vision, auf die sie hinarbeiten: eine gemeinsame technische Basis, auf der alle drei aufbauen können. Damit die erste Frage in einem Projekt nicht mehr lautet „Welches Modul nehme ich?“ — sondern einfach: Was will ich eigentlich bauen?

Über FlowDrop

Für Enterprise-Drupal-Teams und KI-Agent-Entwickler ist FlowDrop das einzige Drupal-native Orchestrierungssystem, in dem ein expliziter, typisierter Datenflussgraph zugleich Spezifikation, Ausführungs-Engine und Audit-Trail ist — aus einer Definition heraus synchron, asynchron und stateful ausführbar, versioniert als Git-freundliche Konfiguration.

Man könnte es so beschreiben: die Breite von n8n oder Activepieces, kombiniert mit dem KI-Flow-Building von Flowise oder Langflow — aber Drupal-nativ, durchgängig typisiert und als versionierte Konfiguration deploybar, nicht als Zeilen in einer externen SaaS-Datenbank.

Der entscheidende Unterschied: Der Graph selbst ist das lesbare, deploybare Artefakt. Die Logik steckt in typisierten, inspizierbaren Knoten, die Daten sind auf den Verbindungen sichtbar. Spezifikation, laufende Engine und Audit-Trail sind ein und dasselbe.

Warum FlowDrop existiert

FlowDrop ist ein Community-Beitrag. Es wurde entwickelt, um eine echte Lücke in Drupals Orchestrierungslandschaft zu schließen und dem Projekt eine Fähigkeit zu geben, die es bislang nicht hatte — und dann an die Community zurückzugeben.

Der visuelle Editor im Kern ist von Drupal entkoppelt und darüber hinaus wiederverwendbar, sodass das Design in mehr als einem Kontext validiert wurde — nicht nur in diesem Modul.

Das Ziel: Drupal etwas Echtes und Nützliches geben.

Was Zusammenarbeit für uns bedeutet

Factorial arbeitet täglich mit dem Drupal-Ökosystem — als Entwickler, als Integratoren, als Partner für Organisationen, die ihre digitalen Prozesse strukturieren und orchestrieren wollen. Die Idee hinter FlowDrop — Drupal eine nahtlose Lösung für die Integration von KI-Fähigkeiten in Content- und Redaktions-Workflows zu geben — hat einen Funken erzeugt, den es sich lohnte zu unterstützen. Von Anfang an hat Factorial entschieden, die Entwicklung von FlowDrop zu sponsern, um Innovation in der Drupal-Community zu fördern.

Was Shibin Das, Jürgen Haas und Randy Kolenko hier tun, ist keine Randnotiz aus der Community. Für uns ist es ein Qualitätssignal über ein Ökosystem, auf das wir stolz sind.

Open Source beruht auf der Überzeugung, dass gemeinsames Bauen bessere Ergebnisse hervorbringt als das Verteidigen von Territorium. Manchmal braucht dieses Prinzip ein konkretes Gesicht. Drei Maintainer, die sich zusammensetzen — weil sie es wollen, nicht weil sie müssen — sind genau das.

Wenn Sie in Drupal Orchestrierungs-Workflows aufbauen oder weiterentwickeln: Wir kennen das Ökosystem. Und wir wissen, welche Module wann sinnvoll sind.