L'open source vive solo se le aziende partecipano

La rinascita della community Drupal in Italia parte da un vuoto lungo anni: nessun camp nazionale, nessun palco su cui portare un progetto, nessuna stanza in cui incontrare chi lavora sugli stessi problemi in un’altra città. Nel resto del mondo, nello stesso periodo, Drupal ha continuato a essere quello che è da sempre: uno dei principali progetti open source esistenti, in produzione presso grandi imprese, pubbliche amministrazioni, università e organizzazioni media. Fuori dai nostri confini moduli, agenzie ed eventi sono cresciuti. Da noi la community si è spenta, e ripartire ha significato ricostruirla quasi da zero.

Va detto senza attenuanti: in Italia siamo indietro. Non sul codice, che è lo stesso ovunque, ma su tutto ciò che sta intorno al codice e che decide se un Paese pesa o non pesa in un progetto che usa ogni giorno.

La tesi di questo pezzo riguarda una responsabilità precisa. L’open source vive perché alcune aziende decidono di parteciparvi: non limitandosi a usare il software, ma sponsorizzando eventi, mandando speaker, portando i propri case study su un palco. Quando nessuna azienda lo fa, la community non si indebolisce: smette di esistere. È quello che è successo qui.

Questo testo nasce da un post che abbiamo pubblicato su LinkedIn. Lo riprendiamo come essay perché la questione merita più di dieci righe, e perché spiega il motivo per cui organizziamo DrupalCamp Italy 2026. Niente lamentele, niente da vendere.

Resta una domanda: come si è arrivati a quel vuoto, e di chi è la responsabilità?

Perché la community Drupal italiana si è spenta per anni?

Il silenzio della community Drupal italiana non è dipeso da un declino del software, ma dal fatto che le aziende hanno continuato a usarlo senza più partecipare, organizzare o sponsorizzare nulla a livello locale. Negli stessi anni in cui da noi il silenzio si allargava, il progetto è cresciuto fuori dai confini nazionali: ha raccolto nuove organizzazioni enterprise e pubbliche e ha visto nascere camp e conferenze in Paesi che prima non ne avevano. Anche in Italia la domanda per il software non è mai venuta meno: i siti sono rimasti in produzione, gli upgrade sono stati fatti, le agenzie hanno continuato a vendere progetti. È scomparsa la community, non Drupal.

Quello che è venuto meno è un’altra cosa: la partecipazione. In Italia è prevalso un modello di uso senza contributo. Si installa, si configura, si consegna, si fattura. Nessuna di queste attività richiede di incontrare qualcuno fuori dal proprio progetto, e per anni quasi nessuno ha sentito il bisogno di farlo.

Perché è potuto succedere senza che nessuno se ne accorgesse? La risposta sta nel modo in cui Drupal è governato. Il progetto non appartiene a una singola azienda: è guidato da una community globale e da una fondazione no-profit, la Drupal Association, e questo garantisce che il codice resti di pubblico dominio e non possa essere chiuso da un vendor. È un vantaggio concreto in termini di indipendenza e di assenza di vendor lock-in. Ma ha una conseguenza strutturale che raramente viene messa in conto.

In un modello proprietario il vendor ha un interesse commerciale diretto a tenere viva la scena locale: organizza eventi nazionali, paga la sede, invita i clienti, forma i partner, perché ogni persona in sala è pipeline. In un progetto governato da una fondazione quel ruolo è vacante per costruzione. Non esiste un reparto marketing centrale con il mandato di tenere in vita la community italiana, francese o brasiliana. La fondazione coordina il progetto globale; le community nazionali esistono solo se qualcuno del posto decide di farsi carico di organizzarle.

Il vuoto italiano, dunque, non è un’anomalia: è un incentivo mancante. Per anni nessun attore locale ha ritenuto che occupare quel ruolo valesse il costo, e la governance distribuita non prevede che qualcuno lo faccia al suo posto.

Ma se il vuoto è il risultato di una scelta collettiva, allora può essere disfatto da un’altra scelta. Ed è esattamente quello che è successo l’anno scorso.

Roma ha dimostrato che la rinascita della community Drupal in Italia era possibile: mancava solo l’occasione

L’anno scorso un piccolo gruppo di persone, tra cui noi di SparkFabrik, ha deciso che quel vuoto era durato abbastanza e ha fatto ripartire DrupalCamp Italy a Roma: le persone sono arrivate, hanno parlato, hanno contribuito.¹ Non c’è stato bisogno di convincere nessuno del valore di Drupal; è bastato offrire un giorno e un luogo.

Questo dato sposta l’onere della prova. Per anni la spiegazione implicita del silenzio italiano era che “qui non c’è interesse”. Roma ha mostrato che l’interesse c’era, latente, e che mancava l’offerta: la domanda esisteva, nessuno la stava servendo. Chi oggi sostiene che in Italia una community Drupal non abbia senso deve spiegare perché una sala si è riempita alla prima occasione disponibile dopo anni.

Cosa fa un DrupalCamp che un webinar non può fare? Il formato è quello classico degli eventi di community open source: sessioni di talk, una parte dedicata alla contribuzione al progetto, e soprattutto lunghi momenti informali tra una sessione e l’altra. La parte più produttiva raramente è sul palco. È il momento in cui un architetto che ha risolto un problema di migrazione su un progetto editoriale scopre che un collega di un’altra agenzia ha lo stesso problema su un portale universitario, e i due si scambiano il contatto. Nessuna documentazione online produce quell’incontro, perché nessuno dei due sa in anticipo cosa cercare.

L’open source non è solo codice. Sono le persone, le conversazioni, i case study condivisi in pubblico e le relazioni costruite in corridoio tra due talk.

DrupalCamp Italy 2026 si terrà a Bologna il 22 ottobre 2026 e, rispetto all’edizione romana, cambia su tre punti concreti:

• Sede: non più la sede di un’università, ma uno spazio specifico per conferenze, scelto per la città e per la raggiungibilità.

• Organizzazione: la macchina conferma la collaborazione delle tre aziende organizzatrici, con ruoli e budget divisi fin dall’inizio; lo organizziamo noi di SparkFabrik insieme a Bmeme e StripedCodex.²

• Internazionalizzazione: il programma vede una lineup di speakers italiani ed internazionali di altissimo livello. Anche lato sponsor si è visto un deciso movimento a livello internazionale, e la stessa Drupal Association supporta ufficialmente l’evento, inviando anche un keynote speaker. Tutto questo dimostra un forte interesse verso il mercato italiano. Ma per raggiungere questi risultati, programma e copertura dei costi si costruiscono con mesi di anticipo e non nelle settimane prima dell’evento.

Chi crede che una comunità nazionale in salute faccia bene a tutti quelli che lavorano su Drupal trova posto in una di queste due call. Le modalità di partecipazione e i dettagli dell’edizione bolognese sono raccolti nella pagina dedicata a DrupalCamp Italy 2026.

Un chiarimento serve a evitare fraintendimenti. Il punto di Roma non è “ce l’abbiamo fatta noi”. Il punto è che si è visto che si può, e che la premessa su cui il vuoto si giustificava da anni era falsa.

Resta però una domanda scomoda. Se funziona e serve a tutti, perché per così tanto tempo non l’ha fatto nessuno? Perché costa. E allora bisogna chiedersi chi paga.

La parte onesta: costa, e non è un business

Costa e non rende: mantenere questa impostazione assorbe budget, ore di sviluppo e attenzione del team senza restituire un ritorno misurabile. La spesa si accumula su tre fronti: licenze e infrastruttura, manutenzione continua, tempo sottratto alle funzionalità che producono valore; i benefici, al contrario, restano difficili da dimostrare con numeri. Il conto, voce per voce, è questo.

Organizzare un evento come DrupalCamp Italy significa affittare una sede, coprire i costi tecnici, gestire iscrizioni e comunicazione, e soprattutto sottrarre giornate di lavoro a persone senior che nel frattempo non sono su un progetto fatturabile. Nessuna delle aziende che lo organizzano ci guadagna: non c’è un margine nascosto, non c’è una pipeline commerciale che si ripaga a fine anno. Da questo dato parte tutto il ragionamento.

Questa asimmetria è il vero motivo del vuoto italiano, molto più della presunta mancanza di interesse. Chi organizza mette denaro e tempo senza un ritorno diretto; chi usa il software beneficia comunque della community, che partecipi o no. Ogni agenzia italiana che vende progetti Drupal trae vantaggio dal fatto che esistano sviluppatori formati, standard condivisi, un progetto che continua a evolvere. Nessuna di queste cose però si produce da sola.

Dries Buytaert, fondatore di Drupal, ha descritto questa dinamica come il problema maker/taker: in un progetto open source coesistono chi contribuisce a costruirlo (i maker) e chi ne trae valore senza restituire nulla (i taker), e quando i secondi crescono più dei primi la sostenibilità si incrina. Le sue riflessioni su come bilanciare maker e taker per sostenere l’open source e su come affrontare il problema in modo concreto riguardano il progetto globale, ma il meccanismo si applica in modo identico a una scena nazionale. Un Paese di soli taker non ha una community; ha soltanto utenti.

La community non è un servizio che qualcun altro fornisce gratis. È il terreno condiviso su cui sono costruiti i nostri business.

I modelli con cui le community open source restano in piedi sono noti: sponsorizzazioni degli eventi, contributi al codice e alla documentazione,³ volontariato organizzato in giornate di contribuzione collettiva, e aziende che decidono di mettere a bilancio una parte del proprio tempo per il bene comune del progetto. Nessuno di questi è gratuito, e Drupal lo ha reso esplicito. Il programma Drupal Certified Partner della Drupal Association formalizza la partecipazione aziendale richiedendo contribuzioni verificate e un impegno economico:⁴ l’appartenenza non si dichiara, si dimostra.

Lo citiamo perché rende misurabile un’idea altrimenti vaga. In SparkFabrik siamo stati la prima azienda italiana a raggiungere il livello Gold di quel programma,⁵ un percorso che abbiamo raccontato quando è arrivato il riconoscimento e che riportiamo qui per una sola ragione: quel tipo di impegno ha un prezzo, viene conteggiato e non è opzionale per chi vuole chiamarsi partner del progetto. Non è una gara con altre aziende italiane. È la prova che partecipare si può misurare, e quindi si può misurare anche la sua assenza.

Ammessa la logica dei costi, arriva l’obiezione più solida. Se costa e non rende, perché un’azienda razionale dovrebbe farlo?

L’obiezione più forte, e perché non regge

Mettiamola in bocca a chi ha in testa il proprio conto economico. Drupal va avanti comunque, con o senza l’Italia: il core viene rilasciato, i moduli vengono aggiornati, la sicurezza è gestita da un team globale che non ha bisogno di Bologna. Le giornate dei senior sono la risorsa più costosa che un’agenzia possiede, e ogni giornata su un palco è una giornata non fatturata. La conoscenza, poi, non richiede più la presenza fisica: la documentazione è online, i talk delle DrupalCon si guardano in streaming, e anche gli incontri locali finiscono registrati. Lo scettico potrebbe usare contro di noi persino il nostro esempio, come nel caso del nostro format Talks on My Machine: chi non c’era lo ha visto per intero su YouTube, senza spendere una giornata di viaggio. I clienti non chiedono se sponsorizzi un camp; chiedono il preventivo. Con margini stretti, un evento nazionale è un lusso culturale, e rinunciarvi è la scelta razionale.

È un’obiezione seria. Non regge per tre motivi, tutti concreti.

1. La questione dei developers. Il bacino di persone che sanno lavorare bene su Drupal in Italia non si allarga da solo. Si allarga quando esiste il luogo in cui uno sviluppatore junior scopre che questo mestiere esiste, e in cui un senior isolato sul proprio progetto capisce di non essere solo. Chi non contribuisce a formare quel bacino compete per gli stessi profili con chi lo forma, e li paga di più.
2. L’invisibilità dei progetti italiani. In Italia esistono progetti Drupal che affrontano problemi tecnici precisi e che quasi nessuno conosce fuori dal team che li ha costruiti: migrazioni multisito da Drupal 7 con decine di istanze da consolidare, gestione multilingua su portali istituzionali con flussi di traduzione e approvazione separati, integrazioni con protocolli e sistemi legacy di enti pubblici (SPID, PagoPA, anagrafiche su database ereditati), testate editoriali che reggono picchi di traffico su breaking news senza degradare il tempo di pubblicazione. Sono scelte architetturali che varrebbe la pena confrontare, e che invece restano confinate in un repository privato e in qualche riunione interna. Un case study presentato su un palco cambia il modo in cui il mercato, e le committenze pubbliche e private, valutano una tecnologia: se nessuno racconta come un portale della PA ha gestito la migrazione da Drupal 7 a 10, chi decide un appalto o un budget lo fa guardando altrove.
3. Il peso decisionale. Su un progetto governato da una fondazione, chi partecipa alla conversazione influenza le priorità: quali problemi vengono affrontati, quali moduli diventano standard, quali direzioni prende il core. Non è teoria, ed è il motivo per cui in SparkFabrik abbiamo costruito il nostro business attorno all’open source e non semplicemente sopra: le ore che i nostri sviluppatori dedicano a patch, moduli e giornate di contribuzione stanno a bilancio come una voce di costo, e i Contribution Credits che ne derivano sono quelli che ci hanno portato al livello Gold del programma partner. In cambio, quando un problema incontrato su un progetto italiano finisce in una issue del core, siamo noi a impostare i termini della discussione, invece di trovarlo risolto in un modo che non ci serve. Chi resta a guardare eredita scelte fatte altrove e le scopre in fase di upgrade, quando costano di più.

Nessuna di queste tre leve produce ritorno nel trimestre in cui si sostiene il costo. Tutte e tre producono un costo certo, e più alto, a chi decide di non muoversi: recruiting più caro, tecnologia percepita come meno matura dai committenti, roadmap subita invece che discussa.

Siamo indietro. Lo abbiamo detto in apertura e lo ripetiamo senza addolcirlo. Ma nello stesso Paese c’è materiale di prima qualità che non è mai stato messo in circolo: c’è una storia di livello nazionale da raccontare e una community nazionale da ricostruire attorno a quella storia. Le due cose insieme non sono una condanna. Sono un’occasione che aspetta solo qualcuno disposto a occuparla.

Partecipare è manutenzione, non generosità

La tesi da cui siamo partiti torna qui con una sfumatura in più. Partecipare a una community open source non è generosità né mecenatismo culturale: è manutenzione dell’infrastruttura condivisa da cui dipendono i business di tutti quelli che ci lavorano. Come ogni manutenzione, costa, non produce ricavi diretti e si nota soprattutto quando manca.

La partecipazione ha molte forme, tutte legittime. Se lavori con Drupal, le opzioni per DrupalCamp Italy 2026 sono queste:

• sponsorizzare un track;

• proporre un talk;

• portare il tuo team;

• raccontare il tuo case study;

• oppure semplicemente esserci, in sala.

Noi lo organizziamo perché crediamo che una community nazionale in salute faccia bene a tutti, non a chi la organizza. La pagina ufficiale dell’evento è su drupal.org; la registrazione è aperta su ti.to.

Bologna, 22 ottobre 2026.

Note e fonti