Quasi 2 mesi dopo l’annuncio dell’acquisizione di Mautic da parte di Acquia, la community Mautic resta in attesa delle comunicazioni previste entro 90 giorni che dovrebbero fornire un po’ più di dettagli sul funzionamento che la società adotterà in futuro.
Questo grande cambiamento per la community è un’immensa opportunità per beneficiare dell’esperienza di Acquia con Drupal e ridefinire alcune regole. Essendo tra i principali contributori di questa community, condividiamo alcune linee di lavoro emerse dal nostro ragionamento e dai nostri scambi con altri membri della community, con l’obiettivo di renderne la gestione più efficace.
1. Le regole di governance, rendiamole più chiare
Acquia ha acquisito la società Mautic ma anche il marchio e, di conseguenza, la community stessa, poiché porta lo stesso nome. Anche se siamo liberi di unirci o lasciare questa community quando vogliamo, se desiderate investirci, sarà sotto la gestione di Acquia.
Tuttavia, tutti dovrebbero sentirsi a proprio agio con questo! Hanno pagato per avere questo, e non c’è nulla di sbagliato finché è chiaro per tutti. Questo è il mio primo punto e probabilmente non è nemmeno il più complicato da gestire! Semplicemente scrivere regole di governance chiare su chi possiede cosa e chi gestisce cosa. Con questo, non è possibile avere sorprese negative. A tal proposito, ci porta ai 2 prossimi argomenti: alcune proposte su come gestire la community, per darle più comfort e migliori metodi di lavoro.
2. Nominare un Community Manager
Lavoro ormai con la community da quasi 4 anni (dai suoi inizi) e ho avuto la fortuna di vederla crescere incredibilmente in fretta. Ho anche constatato che alcune persone si sono assunte sempre più responsabilità (come la gestione e la messa a disposizione delle versioni, ad esempio), mentre un certo tempo fa tutto si basava sulle spalle di DB Hurley (fondatore di Mautic). Purtroppo, oggi è un po’ disorganizzato.
Per quanto riguarda la community di Mautic, questa ha bisogno di un ottimo manager, una persona completamente dedicata a questo compito ; aiutare le persone, mantenere una pianificazione e una roadmap sempre aggiornate, delegare responsabilità, ecc. Per illustrare questa idea, qui parlerò piuttosto dei contributi tecnici alla community, ma sono convinto che questo modello possa essere applicato a qualunque altro tema che Acquia vorrà delegare alla community (marketing, blog, definizione funzionale, ecc.).
Lasciatemi condividere un esempio: il modo in cui Symfony funziona (framework PhP usato da Mautic e… Drupal). Infatti, ogni nuovo contributore tecnico (sviluppatore) entusiasta dell’idea di unirsi e contribuire al progetto open source Symfony dovrà contattare Nicolas Grekas. Nicolas ha un ruolo cruciale ed è lui a svolgerlo egregiamente: condividerà un elenco di bug “facili” da prendere in carico per un primo contributo. Gli riconosce anche il tempo necessario per rivedere il codice, aiutare e rispondere alle domande che il contributore potrebbe porsi. Questo «first-step-in process» è estremamente efficace per far crescere il gruppo di contributori assicurandosi al contempo che siano ben integrati. Dopo un po’ di esperienza, il contributore sarà autonomo nell’affrontare argomenti più complessi.
Come ho già menzionato, penso che questo modello di manager/referente sia applicabile a molti altri argomenti. Ma per quanto riguarda gli aspetti tecnici, penso che una persona come DB Hurley stesso, che ha messo così tanta energia nel far nascere questa community, sarebbe la persona perfetta. Si possono anche prendere in considerazione altre persone che sono sempre state al servizio dei membri della community e che hanno un numero di contributi straordinario al progetto, Alan Hartless ed Jan Linhart.
3. Dei comitati per le roadmap: tecnici e funzionali
È un tema delicato e un’importante aspettativa della community. Alcune roadmap sono state comunicate in passato, ma penso che la community non sia stata coinvolta a sufficienza nella loro realizzazione per farne un successo.
Per questo suggerirei la creazione di 2 comitati per la roadmap del prodotto (le roadmap possono essere applicate anche ad altri argomenti), uno riguardante gli aspetti tecnici (aggiornamenti di PhP, Symfony e delle dipendenze, l’obiettivo di implementare un’architettura a microservizi, ecc.) e un altro riguardante i aspetti funzionali. Questi comitati dovranno prestare attenzione a seguire la strategia e l’orientamento scelti per il progetto, includendo al tempo stesso le aspettative della community. In questo approccio, un sistema di voto per le funzionalità sarebbe molto utile per identificare i bisogni reali degli utenti. Penso anche che l’implementazione di GitHub Sponsors sarebbe un ottimo modo per motivare gli sviluppatori a unirsi alla community e a contribuire a questo bellissimo progetto.
Queste roadmap apporteranno visibilità agli utenti e ai marketing manager. Sarebbero anche un’ottima fonte di contenuti per la comunicazione su Mautic nel mercato del marketing automation. Infine, è il modo migliore per unire sempre più membri attorno alla community.
Per queste linee di lavoro è tutto. Come sempre, Webmecanik sarebbe orgogliosa di partecipare a queste nuove idee e iniziative che renderanno la community di Mautic ancora migliore e più performante.
