di Vito Semeraro

In questo articolo scopriremo, partendo dalla storia dell’Open Source, come i modelli di business a pagamento intorno al software libero si sono evoluti, per minimizzare rischi e costi di startup e massimizzare la soddisfazione degli utilizzatori del software e di chi ci lavora.

Queste considerazioni sono frutto dell’esperienza vissuta da un team che ha evoluto il progetto Open Source forma.lms verso un servizio in SaaS, Forma Cloud.

Caratteristiche di un progetto Open Source

Intorno agli anni novanta, grazie alla diffusione di internet e la possibilità di scambiare velocemente opinioni e soluzioni, le barriere imposte dai software a pagamento iniziarono a vacillare.

Questo movimento, vicino alla subcultura del cyberpunk (che professava uno stile di vita lo-fi ma al contempo proteso verso le possibilità offerte dalla tecnologia) si è evoluto soprattutto in ambito sistemistico e applicativo trovando sostentamento principalmente nelle donazioni, sponsorizzazioni e formazione relativa all’utilizzo.

Le caratteristiche di un progetto sono l’aderenza ad alcuni principi facilmente intuibili:

  • accessibilità: tutto il codice è accessibile e documentato su repository pubblici;
  • trasparenza: il codice è ispezionabile, scaricabile e testabile da tutti;
  • perpetuità: il codice si evolve teorica- mente all’infinito grazie al contributo di una o più community;
  • interoperabilità: più persone lavorano su aspetti diversi del software evolvendolo e senza intaccarne la qualità;
    flessibilità: non si hanno vincoli di costi, licenze rendendolo flessibile alle esigenze più disparate;
    localizzazione: essendo gestito da una community eterogenea supporta peculiarità diverse (es: lingue).

Ogni software libero è comunque tute- lato da consorzi (Open Source Initiative) e una miriade di licenze (la GNU-GPL e MIT tra le più note, raccolte dalla macro FOSS). Alcune ne proibiscono l’uso per fini di lucro ma permettono tutti gli altri utilizzi. Quindi un software Open Sour- ce può essere usato liberamente anche per fini di lucro, l’importante è che venga rispettato il principio dell’accessibilità, quindi mantenendo il codice sempre aperto e disponibile.

Il modello di sviluppo di un progetto Open Source è molto vicino ai principi Agile e si basa su:

  • Collaborazione: Sullo stesso repository lavorano più persone che si aiutano a vicenda per evolvere verso un obiettivo comune
  • Rilasci ravvicinati: più sono ravvicinati i rilasci e maggiore è la qualità del software rilasciato
  • Integrazioni incrementali: Permettono di evolvere il software sviluppando solo quanto strettamente necessario
  • Partecipazione: Le decisioni sulle evoluzioni vengono prese in modo comunitario e senza gerarchie, permettendo al team di lavorare in una condizione di auto commitment proficua ed ingaggiante.

Questi principi rendono di fatto il software creato dal basso: sfruttano le diverse esigenze e skill dei partecipanti al progetto e permettono agli applicativi di seguire i trend di mercato velocemente e senza gerarchie frenanti.

Sono molti gli aspetti che creano valore nei progetti Open Source, oltre che per i contributori anche per gli utilizzatori; nonostante sia convinzione comune che i progetti Open Source creino vantaggi prevalentemente alla community, in realtà permettono di raggiungere standard di qualità pari a quelli dei colossi della new-economy gratuitamente, senza richiedere finanziamenti o investimenti particolari per chi ci lavora.

Modelli di business intorno all’Open Source

Ci sono vari modi per rendere sostenibile la crescita e la manutenzione di un software Open Source oltre al lavoro di chi lo supporta. Qui di seguito le maggiori fonti di proventi, divise tra passive (non richiedono effort da parte degli sviluppatori) e attive, da cui si possono creare entrate costanti.

Passive.

• Donazioni da enti società o individui
• Eventi sponsorizzati da aziende commerciali attive

Attive

  • Supporto a pagamento fornito per bug o issue
  • Formazione sull’utilizzo lato utente o implementazioni custom
  • Consulenza sulle strategie aziendali da implementare per l’utilizzo
  • Erogazione di servizi a pagamento

Da Open Source a Open Core

Le entrate attive si configurano come modello Open Core, ov- vero erogare servizi a pagamento intorno a uno o più nuclei di codice Open Source. Servizi come il supporto e il troubleshooting, lo sviluppo di funzionalità proprietarie sono una valida fonte di entrate per le aziende che lavorano su prodotti Open Source, ma non altrettanto sostenibili dato il segmento inflazionato e le complessità da gestire. Altro punto a sfavore è la difficoltà di scalare questo genere di business senza richiedere ingenti risorse umane e di tempo e non garantendo la sostenibilità del business nel lungo periodo.

Da Open Core a Open SaaS

Un boost al modello Open Core è arrivato dalla maggior accessibilità del cloud storage e delle architetture server ridondate come Amazon AWS e Google Cloud Platform.

L’abbassamento dei costi fissi e la possibilità di scalare le macchine e adottare logiche di “dockerizzazione” hanno dato un impulso notevole ai Servizi in SaaS / PaaS, modello che si basa sulle sottoscrizioni in abbonamento di servizi e applicativi web based di vario genere e livello.

Le soluzione in SaaS sono molto attraenti per i consumatori soprattutto per alcuni motivi:

  • Sicurezza (girano su infrastrutture altamente performanti con processi di data recovery avanzati)
  • Accessibilità (normalmente sono accessibili da più postazioni e più device)
  • Flessibilità (un servizio in SaaS può essere attivato per periodi di tempo brevi, anche solo 30 giorni) I punti negativi invece sono:
  • non si è proprietari del codice (non c’è possibilità di analizzarlo se non funzionalmente con le trial, né tantomeno manipolarlo);
  • si è soggetti a cambi di funzionalità / prezzo (non si ha visibilità sulle roadmap di progetto);
  • impossibilità di migrare verso altri provider (essendo un codice chiuso non è contemplato il porting dell’applicativo su un’infrastruttura proprietaria). Si può definire Open SaaS il modello in cui viene sviluppa- ta un’architettura/infrastruttura che permetta di erogare il software libero in Cloud, mediante abbonamento mensile o annuale. Questo approccio ibrido può portare i benefici di due mondi a sé (quello libero dell’Open Source e quello Enterprise SaaS) da cui poter evolvere costantemente un progetto in modalità Open Source ma fornendo agli utenti SLA ben definiti e rassicuranti. Ecco una tabella riassuntiva dei vantaggi portati agli utenti dal modello Open SaaS rispetto all’Open Source e al SaaS:

Open Source: Codice libero, Assenza di supporto, Portabilità del codice, Codice aperto, Necessità di effort lato sistemistico

SaaS: Codice proprietario, Supporto incluso, Il codice vive solo in cloud, Chiusura ai contributi esterni, On Demand su infrastruttura chiusa

Open SaaS
Codice del core libero
Supporto incluso secondo KPI definiti
Possibilità di usare l’applicativo sia in Cloud che onPremise
Codice del core aperto
Può essere attivato On Demand o su infrastruttura cliente

Ma lato evoluzione del software cosa cambia? Anche qui i benefici di avere un modello Open SaaS sono molteplici:

  • poter contare su una community che alimenta, innovandolo a titolo gratuito, il nucleo upstream del codice;
  • poter migliorare le performance di un dev team che deve interfacciarsi con la community per la scrittura del codice downstream (quello di produzione del prodotto SaaS);
  • poter diminuire drasticamente il technical debt del codice downstream;
  • essere competitivi con colossi della new economy anche senza avere le stesse risorse;
  • Innescare un circolo virtuoso dove il software in SaaS porta migliorie (bugfixing, evolutive) verso il nucleo upstream del codice e viceversa.

Ovviamente una domanda viene spontanea: non è rischioso strutturare un business intorno a un prodotto Open Source che potrebbe essere utilizzato da un competitor per la stessa finalità? Un minimo di rischio c’è ma molto basso. Infatti potenziali concorrenti dovrebbero modificare una quantità di configurazioni, processi e sistemi per poter adattare il proprio business al software Open Source e alla sua erogazione in SaaS. Inoltre occorrerebbe diverso tempo per ricreare alla base la stessa community, rendendo di fatto il business case non sostenibile.

Conclusioni, il caso forma.lms

Negli ultimi 6 anni in forma.lms siamo stati protagonisti di questa transizione, sperimentando su noi stessi tutti e tre i livelli precedentemente descritti.


Siamo partiti dal lavorare su un progetto Open Source nato da un fork circa 6 anni fa ed evoluto principalmente per esigenze aziendali interne di alcune delle quattro società fondatrici.

Data una sempre maggiore domanda di formazione a distanza da parte delle aziende clienti è andato via via ad aumentare l’indotto intorno al progetto LMS, testando quindi la modalità Open Core.

Solo nell’ultimo anno le richieste di erogazione del software in SaaS si sono decuplicate permettendoci di sviluppare un sistema di deploy in Cloud dell’applicativo.

Questo non ha minato però la fiducia nelle potenzialità dell’Open Governance, anzi le ha rafforzate come lo dimostra questa analisi: forma.lms resta e resterà un progetto alimentato dal basso e fieramente Open Source.