Direttore generale presso Webmecanik, siamo un editore di software. Ospitiamo e forniamo supporto a Mautic open source (come fanno altre aziende di servizi), ciò permette di offrire ai nostri utenti una versione del software open source mantenuta, corretta nei bug, con supporto clienti, servizi di formazione, un programma partner, ecc. Tutto ciò è gestito e orchestrato dalla Francia, così come il nostro hosting che avviene principalmente in Francia (i nostri utenti possono anche scegliere la Svizzera, gli Stati Uniti e l’Australia come destinazione dei propri dati in base alle loro esigenze). Ora contiamo più di 300 clienti in 8 paesi.
Il tema di oggi riguarda l’opinione del team Webmecanik su l’emozionante novità in preparazione per Mautic, l’arrivo di Mautic 3. Leggete questo articolo con attenzione: è solo la nostra opinione, probabilmente non la migliore e certamente non l’unica. Solo la nostra riflessione dopo 3 anni di esperienza su questo progetto open source come principale contributore.
Introduzione : Mautic affronta 2 sfide principali
David Hurley, il fondatore di Mautic, ha iniziato a pubblicare una serie di articoli di blog sulla sua visione per Mautic 3, partendo da questi post, Looking ahead to Mautic 3 e Headless marketing automation. Si possono riassumere le seguenti principali sfide :
- Manutenzione : mantenere nel tempo una versione di Mautic duratura
- Performance : offrire agli utenti un’applicazione performante che consenta loro di fare ciò che vogliono
Per rispondere a queste esigenze, a noi si offrono diverse piste di lavoro :
- Un aggiornamento importante del framework (Symfony 2 non sarà più mantenuto dopo il 2019)
- Una migliore separazione dell’applicazione tra i diversi servizi (front-end, back-end, ecc.), concentrandosi su una struttura “API first”
- Mantenere i plugin di integrazione al di fuori del cuore dell’applicazione per evitare problemi di manutenzione
- Migliorare le prestazioni evitando i problemi di velocità e di scalabilità dell’applicazione.
Le prime conclusioni di questi articoli e le numerose discussioni che si sono svolte sul canale #core dello Slack della community Mautic tendono a individuare una nuova stack (Laravel + React), implicando tra l’altro la riscrittura completa dell’applicazione (si terrebbe solo l’esperienza acquisita dal marketeer). Riteniamo che sia una scelta tecnologica moderna, performante e relativamente logica viste le limitazioni. Tuttavia, non ci stiamo lanciando nello sviluppo di un nuovo software, di un nuovo progetto, ma nella continuità del progetto, una versione major. Questo cambia parecchie cose.
Riteniamo che avviare il progetto da una pagina bianca non sia necessariamente il modo più pertinente per affrontare le sfide evidenziate. Entriamo un po’ nei dettagli.
Symfony è un framework molto potente : cambiarlo comporterebbe nuove problematiche
In primo luogo, Symfony è giusto, anzi è perfetto, molto solido e molto potente, specialmente se l’utilizzo di Doctrine è pertinente. Di conseguenza, prendendo in considerazione il vincolo di fine vita di Symfony 2 passando alla versione LTS di Symfony 3 (o 4) si offrirà al progetto tutte le possibilità di raggiungere il successo. Oggi puoi elencare molte e grandissime aziende web che usano Symfony come Blablacar, Spotify o anche YouPorn (fonte stfalcon.com).
L’esperienza acquisita dai sviluppatori della Community
Mautic esiste ormai da più di 3 anni. Come ogni progetto open source, si basa su un insieme di sviluppatori della community che contribuiscono allo sviluppo di nuove funzionalità, alla correzione di bug e ai miglioramenti. Questa community è preziosa e va curata, dal nostro punto di vista. Una community open source è composta da due tipi di contributori – utenti e sviluppatori. Ognuno porta un valore molto importante per il corretto sviluppo del progetto – esigenze funzionali, rapporto di bug vs. sviluppo di funzionalità, correzione dei bug, ecc.
Il rischio di far allontanare alcuni membri della community a causa di cambiamenti drastici è un pericolo per la sostenibilità del progetto open source. L’esperienza della community su questo substrato tecnico, e soprattutto quella degli sviluppatori, è ormai acquisita su Symfony. Alcuni saranno probabilmente entusiasti di un tale cambiamento, mentre altri, non essendo competenti, potrebbero lasciare la nave per restare nella propria area di competenza e di comfort.
“Assicuratevi che i vostri sviluppatori si sentano a proprio agio con il linguaggio di codice scelto e incoraggiate gli sviluppatori ad aiutarsi a vicenda.”
Questa è anche una delle principali lezioni presentate da Basecamp in uno dei loro articoli del blog.
Tempo di implementazione
Ripartire da zero implica la re-implementazione di tutte le funzionalità. Cambiare stack implica anche un cambiamento della struttura di tutti i processi e le architetture. L’attuale versione di Mautic (2.13.1) è il risultato di 3 anni di lavoro.
“Nonostante quello che potete pensare, riscrivere il vostro software vi richiederà probabilmente tanto tempo la seconda volta quanto la prima. In effetti, avete più informazioni ora che in precedenza, ma queste informazioni potrebbero essere già obsolete.”
Questa è una citazione tratta da un articolo molto interessante intitolato “why you should (almost) never rewrite your software.“. Mettono in evidenza la loro opinione e il motivo per cui non si dovrebbe rifare tutto; se il vostro codice non va più bene, è possibile farlo evolvere nel modo giusto con tutta l’esperienza accumulata.
Detto questo, sembra legittimo pensare che non sarà possibile rilasciare una versione stabile in poco tempo, mentre la versione stabile di oggi è stata costruita nel lungo termine.
Affrontare gli stessi problemi
Ultimo punto e non il meno importante. Se cambiate lo stack, i vostri sviluppatori perderanno la loro esperienza. Non siete più intelligenti di prima. La conseguenza è evidente: affronterete gli stessi problemi scoprendo un nuovo framework e, se non fosse così, allora sarebbero nuovi.
“Lo hanno fatto commettendo il più grande errore che un editore di software possa fare : hanno deciso di riscrivere il codice da zero.”
“L’idea che il nuovo codice sia migliore di quello precedente e completamente assurda. Il codice precedente è stato usato e sperimentato. È stato testato. Sono stati scoperti e corretti numerosi bug. Non c’è niente di sbagliato in questo.”
Queste citazioni provengono da un articolo che parla della strategia adottata da Netscape e vista da Joel Spolsky. E ha ragione ! Non è perché si vuole rifare tutto con attenzione che lo si farà meglio.
La posizione di Webmecanik rispetto a Mautic 3
È la naturale conclusione dei paragrafi precedenti e probabilmente avete già compreso la nostra posizione. Incoraggiamo la community mautic a scegliere il miglioramento dell’esistente , migliorando la distinzione tra front / back / api, procedendo al contempo con un aggiornamento del framework verso Symfony 3 (o 4) versione LTS.
Per quanto riguarda la nostra strategia aziendale come hosting provider di mautic open source in Cloud e principale contributore :
- se la community sceglierà la nostra opinione, continueremo a contribuire come principale contributore che siamo e offriremo questa nuova versione ai nostri clienti esistenti,
- se scelgono di creare una nuova applicazione su una nuova stack, non costringeremo i nostri clienti a cambiare la soluzione, con il rischio di dover ricreare una parte delle loro campagne. Offriremo allora ai nostri clienti la scelta tra mautic 2 su una versione forkata e mantenuta da noi e Mautic 3, come due prodotti diversi.
Queste opzioni sono state ispirate soprattutto da Basecamp quando hanno lanciato Basecamp 3 dopo Basecamp 2. La filosofia e la struttura sono diverse, quindi hanno deciso di mantenere entrambe le soluzioni (hanno anche mantenuto Basecamp Classic, la loro prima versione).
