Directeur général chez Webmecanik, nous sommes éditeur de logiciels. Nous hébergeons et supportons Mautic open source (comme d’autres entreprises de services le proposent), cela permet d’offrir à nos utilisateurs une version du logiciel open source maintenue, débeuguée, avec un support client, des services de formation, un programme partenaire, etc. Tout cela est géré et orchestré depuis la France, tout comme notre hébergement qui se fait principalement en France (nos utilisateurs peuvent aussi choisir la Suisse, les Etats-Unis et l’Australie comme destination de leurs données en fonction de leur besoin). Nous comptons maintenant plus de 300 clients dans 8 pays.
Le propos d’aujourd’hui concerne l’opinion de l’équipe Webmecanik à propos de l’excitante nouveauté qui se prépare pour Mautic, l’arrivée de Mautic 3. Veuillez lire cet article avec précaution, ce n’est que notre opinion, probablement pas le meilleur et certainement pas l’unique. Seulement notre reflexion après 3 ans d’expérience sur ce projet open source comme principal contributeur.
Introduction : Mautic fait face à 2 challenges majeurs
David Hurley, le fondateur de Mautic, a commencé à publier une série d’articles de blog à propos de sa vision pour Mautic 3, en commençant par ces postes, Looking ahead to Mautic 3 et Headless marketing automation. On peut retenir les principaux challenges suivants :
- Maintenance : garder une version de Mautic durable dans le temps
- Performance : apporter aux utilisateurs une application performante qui leur permet de faire ce qu’ils veulent
Pour répondre à ces contraintes, plusieurs pistes de travail s’offrent à nous :
- Une mise à jour majeure du framework (Symfony 2 ne sera plus maintenu après 2019)
- Une meilleure séparation de l’application entre les différents services (front-end, back-end, etc.) en ce concentrant sur une structure « API first »
- Garder les plugins d’intégrations en dehors du coeur de l’application pour éviter des problèmes de maintenance
- Améliorer les performances en évitant les problèmes de vitesse et de scalabilité de l’application.
Les premières conclusions de ces articles et de nombreuses discussions qui ont eu lieu sur le canal #core du Slack de la communauté Mautic tendent à choisir une nouvelle stack (Laravel + React), impliquant au passage la ré-écriture complète de l’application (on ne garderait que l’expérience acquise du marketeur). Nous pensons que c’est un choix technologique moderne, performant et relativement logique vu les contraintes. Cependant, nous ne nous lançons pas dans le développement d’un nouveau logiciel, un nouveau projet, mais dans la continuité du projet, une version majeur. Cela change pas mal de choses.
Nous pensons que démarrer le projet d’une page blanche n’est pas forcément la manière la plus pertinente d’adresser les enjeux mis en évidence. Rentrons un peu dans le détail.
Symfony est un framework très puissant : le changer impliquerait de nouvelles problématiques
Premièrement, Symfony c’est bien, c’est même très bien, très solide et très puissant, spécialement si l’utilisation de Doctrine est pertinente. En conséquence, en prenant en compte la contrainte de fin de vie de Symfony 2 en migrant vers la version LTS de Symfony 3 (ou 4) offrira au projet toutes les chances d’atteindre le succès. Vous pouvez lister aujourd’hui de nombreuses et très grandes entreprises du web qui utilisent Symfony comme Blablacar, Spotify ou même YouPorn (source stfalcon.com).
L’expérience acquise pas les développeurs de la Communauté
Mautic existe maintenant depuis plus de 3 ans. Comme tout projet open source, il se repose sur un ensemble de développeurs communautaires qui contribuent au développement de nouvelles fonctionnalités, correction de bugs et améliorations. Cette communauté est précieuse et doit être soignée, de notre point de vue. Une communauté open source est faite de deux types de contributeurs – utilisateurs et développeurs. Ils amènent chacun une valeur très importante au bon développement du projet – besoins fonctionnels, rapport de bugs vs. développement de fonctionnalités, correction de bugs, etc.
Prendre le risque de faire fuir certains membres communautaires par des changements drastique est un danger pour la pérennité du projet open source. L’expérience de la communauté sur ce socle technique, et spécialement celui des développeurs est maintenant acquise sur Symfony. Certains seront probablement excité d’un tel changement, d’autres n’étant pas compétents pourraient quitter le navire pour rester dans leur zone d’expertise et de confort.
« Assurez vous que vos développeurs se sente confortable avec le language de code choisi, et encouragez les développeurs à s’entraider. »
C’est également une des leçons principales présentée par Basecamp dans un de leur article de blog.
Temps de mise en oeuvre
Redémarrer de zéro implique le re-développement de toutes les fonctionnalités. Changer la stack implique également un changement de structure de tous les process et architectures. La version actuelle de Mautic (2.13.1) est le résultat de 3 ans de travail.
« Malgré ce que vous pouvez penser, re-écrire votre logiciel vous prendra probablement autant de temps la seconde fois que la première. Effectivement, vous avez plus d’informations maintenant qu’auparavant, mais ces informations sont peut être déjà obsolètes. »
C’est une citation tirée d’un article très intéressant s’intitulant « why you should (almost) never rewrite your software ».Ils mettent en évidence leur opinion et la raison pour laquelle on ne doit pas tout refaire ; si votre code ne convient plus, il est possible de faire évoluer cela dans le bon sens avec toute l’expérience acquise.
Ceci étant dit, il semble légitime de se dire qu’il ne sera pas possible de délivrer une version stable en peu de temps alors que la version stable d’aujourd’hui a été construite sur du long terme.
Faire face aux mêmes problèmes
Dernier point et pas des moindres. Si vous changez votre stack, vos développeurs vont perdre leur expérience. Vous n’êtes pas plus intelligents qu’avant. La conséquence est évidente, vous allez faire face aux même problématiques en découvrant un nouveau framework, et si ce n’est pas le cas, ca en sera des nouveaux.
« Ils l’ont fait en faisant la plus grosse erreur qu’un éditeur de logiciel peut faire : Ils ont décidé de ré-écrire le code depuis zéro. »
« L’idée que le nouveau code sera meilleur que le précédent et complètement absurde. L’ancien code a été utilisé et éprouvé. Il a été testé. De nombreux bugs ont été découverts et corrigés. Il n’y a rien de mal à cela. »
Ces citations viennent d’un article à propos de la stratégie adoptée par Netscape et vue par Joel Spolsky. Et c’est vrai ! Ce n’est pas parce que l’on veut refaire tout avec attention que l’on fera mieux.
La position de Webmecanik vis à vis de Mautic 3
C’est la logique conclusion des paragraphes précédents et vous avez probablement déjà compris notre point de vue. Nous encourageons la communauté mautic à choisir l’amélioration de l’existant en améliorant la distinction du front / back / api, tout en faisant une mise à jour du framework vers Symfony 3 (ou4) LTS version.
Concernant notre stratégie d’entreprise comme hébergeur de mautic open source en Cloud et principal contributeur :
- si la communauté choisi notre opinion, nous continuerons à contribuer comme le contributeur principal que nous sommes et nous offrirons cette nouvelle version à nos clients existants,
- s’ils choisissent de créer une nouvelle application sur une nouvelle stack, nous ne forcerons pas nos clients à changer la solution au risque de devoir re-créer une partie de leurs campagnes. Nous offrirons alors à nos clients le choix entre mautic 2 sur une version forkée et maintenue par nos soins et Mautic 3, cela comme 2 produits différents.
Ces options ont été inspirées par Basecamp notamment lorsqu’ils ont lancé Basecamp 3 après Basecamp 2. La philosophie et la structure est différente, ils ont donc décidé de garder les deux solutions (ils ont même gardé Basecamp Classic, leur première version).
