Geschäftsführer bei Webmecanik: Wir sind ein Software-Editor. Wir hosten und unterstützen Mautic Open Source (wie es auch andere Dienstleistungsunternehmen anbieten), sodass unseren Nutzern eine Version der Open-Source-Software bereitgestellt wird, die gepflegt, entbuggt und mit Kundensupport, Schulungsservices, einem Partnerprogramm usw. versehen ist. All dies wird von Frankreich aus verwaltet und orchestriert – ebenso unser Hosting, das hauptsächlich in Frankreich erfolgt (unsere Nutzer können auch die Schweiz, die Vereinigten Staaten und Australien als Ziel für ihre Daten je nach Bedarf wählen). Wir haben mittlerweile mehr als 300 Kunden in 8 Ländern.
Das heutige Thema bezieht sich auf die Meinung des Webmecanik-Teams zur aufregenden Neuigkeit, die für Mautic in Vorbereitung ist: das Erscheinen von Mautic 3. Bitte lesen Sie diesen Artikel mit Vorsicht: Es handelt sich nur um unsere Meinung – wahrscheinlich nicht die beste und auf keinen Fall die einzige. Nur unsere Überlegungen nach 3 Jahren Erfahrung mit diesem Open-Source-Projekt als hauptsächlicher Mitwirkender.
Einführung: Mautic steht vor 2 großen Herausforderungen
David Hurley, der Gründer von Mautic, hat begonnen, eine Reihe von Blogartikeln über seine Vision für Mautic 3 zu veröffentlichen, beginnend mit diesen Beiträgen, Looking ahead to Mautic 3 und Headless marketing automation. Dabei lassen sich vor allem folgende Herausforderungen festhalten :
- Wartung: eine langfristig tragfähige Version von Mautic über die Zeit hinweg sicherstellen
- Performance: den Nutzern eine performante Anwendung bereitstellen, die es ihnen ermöglicht, das zu tun, was sie möchten
Um auf diese Anforderungen zu reagieren, bieten sich uns mehrere Arbeitsansätze an :
- Ein großes Update des Frameworks (Symfony 2 wird nach 2019 nicht mehr gepflegt)
- Eine bessere Trennung der Anwendung zwischen den verschiedenen Diensten (Front-End, Back-End usw.), indem man sich auf eine Struktur „API first“ konzentriert
- Die Integrations-Plugins außerhalb des Kernbereichs der Anwendung lassen, um Wartungsprobleme zu vermeiden
- Die Performance verbessern, indem man Probleme mit Geschwindigkeit und Skalierbarkeit der Anwendung vermeidet.
Die ersten Schlussfolgerungen aus diesen Artikeln sowie viele Diskussionen, die auf dem #core-Kanal des Slack der Mautic-Community stattgefunden haben, tendieren dazu, eine neue Stack-Lösung (Laravel + React) auszuwählen, was in der Folge auch eine vollständige Neuschreibung der Anwendung bedeutet (man würde nur die gesammelte Erfahrung des Marketings übernehmen). Wir glauben, dass es eine moderne, leistungsfähige und angesichts der Rahmenbedingungen eine ziemlich logische technologische Entscheidung ist. Allerdings starten wir nicht die Entwicklung einer neuen Software, eines neuen Projekts, sondern setzen das Projekt fort – eine große Version. Das verändert einiges.
Wir denken, dass es nicht zwingend der sinnvollste Weg ist, die Herausforderungen, die herausgearbeitet wurden, anzugehen, mit einem Projekt „auf weißer Seite“ zu beginnen. Gehen wir etwas ins Detail.
Symfony ist ein sehr leistungsstarkes Framework: Ein Wechsel würde neue Probleme mit sich bringen
Erstens, Symfony ist gut, sogar sehr gut, sehr solide und sehr leistungsstark, insbesondere wenn die Nutzung von Doctrine sinnvoll ist. Infolgedessen wird das Projekt durch die Berücksichtigung der End-of-Life-Frist von Symfony 2 beim Umstieg auf die LTS-Version von Symfony 3 (oder 4) die besten Chancen haben, erfolgreich zu sein. Sie können heute zahlreiche sehr große Web-Unternehmen auflisten, die Symfony nutzen, etwa Blablacar, Spotify oder sogar YouPorn (Quelle stfalcon.com).
Die von den Entwicklern der Community gewonnene Erfahrung
Mautic gibt es jetzt seit über 3 Jahren. Wie jedes Open-Source-Projekt stützt es sich auf eine Gruppe von Community-Entwicklern, die zur Entwicklung neuer Funktionen, zur Fehlerbehebung und zu Verbesserungen beitragen. Diese Community ist wertvoll und sollte aus unserer Sicht gepflegt werden. Eine Open-Source-Community besteht aus zwei Arten von Mitwirkenden – Nutzer und Entwickler. Beide bringen einen sehr wichtigen Beitrag für die erfolgreiche Entwicklung des Projekts – funktionale Bedürfnisse, das Verhältnis von Bug-Meldungen zum Entwickeln von Funktionen, Bugfixes usw.
Das Risiko, bestimmte Community-Mitglieder durch drastische Änderungen zu verprellen, ist eine Gefahr für die langfristige Tragfähigkeit eines Open-Source-Projekts. Die Erfahrung der Community auf dieser technischen Grundlage – insbesondere die der Entwickler – ist heute bereits mit Symfony vorhanden. Einige werden sich vermutlich über einen solchen Wandel freuen, während andere, denen die Kompetenz dafür fehlt, das „Schiff“ möglicherweise verlassen, um in ihrem Bereich und in ihrer Komfortzone zu bleiben.
„Stellen Sie sicher, dass sich Ihre Entwickler mit der gewählten Programmiersprache wohlfühlen, und ermutigen Sie die Entwickler, sich gegenseitig zu unterstützen.“
Das ist auch eine der wichtigsten Lektionen, die Basecamp in einem ihrer Blogartikel vorstellt.
Dauer der Umsetzung
Bei einem Neustart bei Null müssen alle Funktionen neu entwickelt werden. Ein Wechsel der Stack-Lösung bedeutet außerdem eine Umstellung der Struktur sämtlicher Prozesse und Architekturen. Die aktuelle Version von Mautic (2.13.1) ist das Ergebnis von 3 Jahren Arbeit.
„Ungeachtet dessen, was Sie vielleicht denken: Das Neuschreiben Ihrer Software wird Sie wahrscheinlich genauso viel Zeit kosten wie beim zweiten Mal wie beim ersten Mal. Sie haben zwar jetzt mehr Informationen als zuvor, aber diese Informationen könnten bereits veraltet sein.“
Das ist ein Zitat aus einem sehr interessanten Artikel mit dem Titel „why you should (almost) never rewrite your software.“ Sie machen ihre Meinung und den Grund deutlich, warum man nicht alles neu machen sollte; wenn Ihr Code nicht mehr passt, ist es möglich, ihn in die richtige Richtung weiterzuentwickeln – mit all der gesammelten Erfahrung.
Damit gesagt, erscheint es dennoch legitim zu sagen, dass es nicht möglich sein wird, in kurzer Zeit eine stabile Version bereitzustellen, während die stabile Version von heute über lange Zeit hinweg aufgebaut wurde.
Mit den gleichen Problemen konfrontiert sein
Letzter Punkt und nicht der unwichtigste. Wenn Sie Ihre Stack-Lösung ändern, verlieren Ihre Entwickler ihre Erfahrung. Sie sind nicht intelligenter als zuvor. Die Konsequenz ist offensichtlich: Sie werden bei der Entdeckung eines neuen Frameworks auf dieselben Probleme stoßen – und falls das nicht der Fall ist, dann auf ganz neue.
„Sie haben das gemacht, indem sie den größten Fehler begangen haben, den ein Software-Editor machen kann: Sie haben entschieden, den Code von Grund auf neu zu schreiben.“
„Die Idee, dass der neue Code besser sein wird als der vorherige und komplett absurd. Der alte Code wurde verwendet und erprobt. Er wurde getestet. Viele Bugs wurden entdeckt und behoben. Daran ist nichts falsch.“
Diese Zitate stammen aus einem Artikel über die von Netscape verfolgte Strategie, wie von Joel Spolsky gesehen. Und das stimmt! Nur weil man alles mit Sorgfalt neu machen will, wird man es nicht automatisch besser machen.
Die Position von Webmecanik in Bezug auf Mautic 3
Das ist die logische Schlussfolgerung aus den vorherigen Absätzen, und Sie haben vermutlich bereits unsere Sichtweise verstanden. Wir ermutigen die Mautic-Community, die Verbesserung des Bestehenden zu wählen, indem sie die Unterscheidung zwischen Front / Back / API verbessert – und gleichzeitig ein Framework-Update auf Symfony 3 (oder 4) LTS vornimmt.
In Bezug auf unsere Unternehmensstrategie als Cloud-Hoster für Mautic Open Source und als wichtigster Mitwirkender :
- Wenn die Community unsere Meinung wählt, werden wir weiterhin beitragen, wie wir als Haupt-Mitwirkender es tun, und wir werden diese neue Version unseren bestehenden Kunden anbieten,
- Wenn sie sich dafür entscheiden, eine neue Anwendung auf einer neuen Stack-Lösung zu erstellen, werden wir unsere Kunden nicht dazu zwingen, die Lösung zu wechseln – mit dem Risiko, einen Teil ihrer Kampagnen neu erstellen zu müssen. Dann bieten wir unseren Kunden die Wahl zwischen Mautic 2 auf einer von uns gepflegten und gewarteten Fork-Version und Mautic 3 – als zwei unterschiedliche Produkte.
Diese Optionen wurden unter anderem von Basecamp inspiriert, insbesondere als sie Basecamp 3 nach Basecamp 2 eingeführt haben. Die Philosophie und die Struktur sind unterschiedlich, daher haben sie beschlossen, beide Lösungen beizubehalten (sie haben sogar Basecamp Classic, ihre erste Version, behalten).
