La sostenibilità dei progetti open source è un tema che mi appassiona da anni, tanto da aver già scritto su questo tema basandomi sulle interessanti elucubrazioni di Dries Buytaert, fondatore del Content Management System open source Drupal ed Executive Chairman di Acquia, l’azienda che utilizza Drupal per fornire servizi alle aziende e nel farlo sviluppa il CMS aggiungendo funzionalità.
Secondo la mia personale opinione, Dries è una delle menti più lucide e autorevoli sul tema della sostenibilità, e non solo perché – vivendo il problema sulla propria pelle – lo ha analizzato in modo approfondito nel suo blog, ma anche perché è riuscito a sintetizzare tutti gli aspetti all’interno di un disegno strutturale che forse andrebbe studiato un po’ di più (e con questo non sto affermando che dovremmo seguire i suggerimenti di Dries, ma solo di tenerli in dovuta considerazione).
Indice degli argomenti
Crisi di sostenibilità e necessità di modelli strutturati
Detto questo, nell’ articolo cercherò di ignorare le considerazioni di Dries e analizzerò i nove modelli per la sostenibilità dei progetti open source che sono nati nel corso degli anni per rispondere alla stessa sfida: garantire le risorse (tempo, talento, server, supporto legale) necessarie per mantenere un progetto open source in buona salute. Senza un piano consapevole per la sostenibilità, i progetti possono inaridirsi (anche molto lentamente: Apache OpenOffice non è sviluppato dal 2014, ma continua a essere usato nonostante i problemi di sicurezza), fino a perdere prima gli sviluppatori e poi gli utenti.
La sostenibilità economica come fattore trascurato
Per ogni modello, cercherò di esaminare i punti di forza e i punti di debolezza, per aiutare nella comprensione da parte di chi contribuisce ai progetti e di chi utilizza le librerie o i software open source.
Purtroppo, la sostenibilità economica del progetto è l’aspetto più trascurato in assoluto nel settore del software open source, e questo da un lato spiega perché i progetti che non hanno alle spalle un’azienda o non sono espressione di un gruppo di aziende hanno difficoltà nel medio e lungo periodo, quando l’entusiasmo diminuisce e i fondatori invecchiano.
I limiti organizzativi e culturali nei progetti open source
È opportuno sottolineare che alcuni dei modelli funzionano solo per aree specifiche di un progetto, come la quality assurance, o per sottoprogetti specifici, come sprint per la raccolta di fondi nell’area del marketing.
L’industria del software open source deve maturare, e in questo senso l’aspetto della sostenibilità è uno dei più importanti. Purtroppo, i progetti che nascono dalla comunità esprimono al loro interno visioni contrastanti, e senza un management in grado di indirizzare il progetto stesso ed espellere i portatori di negatività – che sono statisticamente presenti in tutte le organizzazioni complesse – alla fine perdono gli elementi migliori, che se ne vanno per stanchezza, mentre i peggiori restano fino alla morte del progetto stesso.
Analisi dei nove modelli per la sostenibilità open source
Questo è l’elenco dei modelli per la sostenibilità del software open source:
Volontariato puro
Adatto per progetti di piccole e medie dimensioni con gestori appassionati e esigenze infrastrutturali modeste. Un team centrale di sviluppatori non retribuiti si occupa della gestione del codice, mentre gli utenti contribuiscono segnalando bug, apportando modifiche alla documentazione e inviando patch occasionali. L’hosting è spesso gratuito e il supporto viene fornito dalla comunità con mailing list, sistemi di chat o forum pubblici.
Gli aspetti problematici sono i tempi di risposta, che possono essere molto lenti, indipendentemente dal problema. I principali sviluppatori possono andare incontro a burnout, e la crescita può essere rallentata o addirittura ostacolata dall’assenza di personale retribuito e dai limiti dell’hosting gratuito.
Donazioni e crowdfunding
Adatto a progetti con una base di utenti fedeli e pronti a contribuire, al punto da generare un flusso di denaro in entrata sufficiente per sostenere i costi dello staff e dell’infrastruttura. In genere, le donazioni sono libere, e nella maggior parte dei casi sono individuali, perché le aziende – culturalmente – non sono abituate al concetto di donazione.
Gli aspetti problematici sono legati alla trasparenza nella gestione dei fondi, che deve essere cristallina e scevra da conflitti di interesse. Inoltre, i fondi potrebbero non essere sufficienti a garantire un’attività di sviluppo adeguata alle aspettative degli utenti, e questo nel medio e lungo periodo si può tradurre in una disaffezione da parte degli utenti, e una implosione del progetto.
Sponsorizzazioni aziendali e Fondazioni
Adatto a progetti integrati in prodotti commerciali o con un’ampia base di utenti aziendali. Lo sponsor paga gli stipendi dei responsabili dello sviluppo e del supporto o stipula contratti per lo sviluppo di specifiche funzionalità. Aziende come Red Hat e fondazioni come Linux Foundation sponsorizzano decine di progetti chiave, tra cui il kernel Linux.
L’azienda e/o la fondazione raccolgono i contributi in denaro, pagano i coordinatori, finanziano le infrastrutture, si occupano degli aspetti legali, organizzano conferenze e sostengono i progetti dei volontari. Gli aspetti problematici sono i costi strutturali, che rischiano di crescere più del progetto, e i potenziali conflitti di interesse tra gli esponenti delle aziende e lo status di not for profit dei progetti.
Doppia licenza con licenza commerciale
Adatto a progetti con una chiara esigenza aziendale di integrazione proprietaria. Il codice sorgente viene rilasciato con una licenza aperta e una licenza commerciale a pagamento, per consentire alle aziende che non desiderano rendere pubblico il proprio codice derivato di acquistare l’opzione proprietaria.
Gli aspetti problematici sono legati alla frammentazione del progetto che deriva dalla presenza di due licenze per lo stesso software. Storicamente, questo modello ha consentito a MySQL di costruire un business nell’area dei database che nel 2008 è stato oggetto della prima acquisizione miliardaria nel settore del software open source (da parte di Sun Microsystems).
Approccio “Open Core”
Adatto a progetti con un’architettura modulare e una chiara separazione tra funzionalità di base e funzionalità premium. Il prodotto di base rimane open source, mentre le funzionalità avanzate richiedono una licenza commerciale.
Gli aspetti problematici sono legati al fatto che spesso la licenza open source viene utilizzata per attrarre gli utenti, che poi scoprono che per lavorare hanno bisogno di una licenza commerciale.
Consulenza, assistenza e formazione
Adatto a progetti consolidati con una base di utenti aziendali che hanno bisogno delle garanzie tipiche dei progetti di software proprietario, come la consulenza per implementazione, funzionalità personalizzate e ottimizzazione delle prestazioni; un contratto di assistenza basato su SLA (Service Level Agreement); e la formazione a pagamento (workshop con istruttore, e corsi di certificazione).
Gli aspetti problematici sono legati al rischio di defocalizzazione sullo sviluppo del codice sorgente, a favore delle attività di tipo consulenziale, e viceversa. Infatti, non è facile creare un’organizzazione bilanciata tra sviluppo e consulenza, perché le due professioni sono profondamente diverse, e gli addetti non possono essere spostati da un’area all’altra (con rarissime eccezioni).
Offerte SaaS in hosting
Adatto a progetti in cui prevale l’aspetto del servizio rispetto a quello del software, come nel caso dei Content Management Systems. Gli utenti acquistano un servizio in abbonamento, senza preoccuparsi dell’infrastruttura o degli aggiornamenti della piattaforma, che può comprendere funzionalità avanzate di tipo proprietario, come dashboard, backup e analisi. La licenza open source consente in ogni momento il passaggio alla soluzione gestita direttamente dall’azienda.
Gli aspetti problematici sono quelli tipici delle soluzioni in abbonamento, ovvero il rischio di sottodimensionamento della struttura di supporto che deve funzionare 24 ore su 24 e 7 giorni su 7, e gli incidenti catastrofici all’infrastruttura come gli incendi dei datacenter.
Finanziamento per la soluzione di problemi
Adatto a progetti strutturati con un team di quality assurance, che è in grado di fornire una lista specifica dei problemi da risolvere o delle funzioni da sviluppare. Viene spesso utilizzato coinvolgendo più progetti open source, e finanziato da enti sovranazionali o fondazioni che raccolgono i fondi e li gestiscono per conto terzi (che possono essere governi, o amministrazioni pubbliche).
Gli aspetti problematici sono legati alla complessità amministrativa, che spesso è talmente elevata da scoraggiare la partecipazione. Infatti, la trasparenza comporta un sovraccarico di attività che rischia di ridurre i fondi disponibili per il lavoro vero e proprio di sviluppo e soluzione dei problemi.
Finanziamento con il merchandising
Adatto a progetti con un marchio forte, con un’ampia comunità di utenti, e con una presenza online che genera un traffico sufficiente a sostenere l’obiettivo economico del finanziamento, anche perché il prezzo dei singoli prodotti è spesso molto basso (come nel caso delle magliette o delle tazze per il caffè).E infatti, il vero problema sta nei ricavi, che sono abbastanza modesti.
I progetti più grandi e organizzati combinano spesso più modelli per la sostenibilità, come nel caso del progetto LibreOffice, dove la fondazione raccoglie le donazioni, coordina le attività di finanziamento legate alla soluzione dei problemi, e ha un negozio online per il merchandising.
Questo perché non esiste un modello per la sostenibilità del software open source valido per tutti i progetti.
