Carlo Daffara: Collaborative development, sustainability models and licenses in Open Source Software (OSS)

Carlo Daffara: Collaborative development, sustainability models and licenses in Open Source Software (OSS)

La lezione di oggi 4 marzo 2009 è cominciata con una nota del relatore sull’inizio del Free Software: secondo Carlo Daffara questo infatti non risale agli anni ’80 bensì al 1955 con gruppi quali SHARE e DECUS, i quali mostravano per la prima volta già un modo collaborativo di condivisione del codice in giornali accademici (si pensi alla colonna “Algorithms” nel “Communication of ACM Journal”).
Successivamente poi il concetto è stato ampliamente sviluppato e realizzato da Stallman.

La definizione legale di Open Source è che un codice è OS se la sua licenza è riconosciuta dall’OSI (Open Source Initiative) Foundation.
Vi sono due modelli diversi di sviluppo software, così come spiegato da Eric Raymond in “The cathedral and the bazaar”, in cui enuncia il concetto di sviluppo condiviso:

1. modello “cattedrale”: molto stretto e ben definito, è simile al modello “a cascata” (waterfall model); è usato da industrie che sviluppano software proprietario (un esempio è Windows);
2. modello “bazaar”: ognuno può collaborare allo sviluppo che risulta pertanto aperto, non definito a priori e in divenire; un esempio è il caso di Linux.

Questa analisi mostra come tra un modello di licenza e un modello di sviluppo del codice non vi sia alcuna correlazione: dalla licenza di un software non si può capire il modello secondo il quale il programma è stato sviluppato.
Mentre però le licenze FLOSS coprono soltanto il regime delle licenze appunto, per estensione invece il concetto di “openness” del codice introduce la possibilità di condividere sviluppi all’interno di gruppi differenti.
Per quanto riguarda le licenze open source approvate dalla FSF (Free Software Foundation) o dall’OSI, queste risultano essere più di 70, nonostante quelle poi usate siano 10 o forse meno.
Le licenze possono essere classificate come

1. “provide credit”: permettono l’uso, la modifica e la redistribuzione; in quest’ultimo caso è obbligatorio citare l’autore originale; esempi sono la licenza BSD o la licenza ApacheV2.
2. “Provide fixed”: permettono l’uso, la modifica e la redistribuzione ma in quest’ultimo caso è necessario fornire il codice sorgente modificato all’autore originale; un esempio di tale licenza è la Mozilla Public License (MPL).
3. “Provide all”: permettono l’uso, la modifica e la redistribuzione ma in quest’ultimo caso è necessario fornire il codice modificato; esempi sono la licenza GPL e la licenza AGPL.

Da una ricerca del marzo 2008 risulta che il 45% del software usa almeno una licenza OS. Alcuni esempi sono il caso di Open Cascade, il cui valore del software è rappresentato per circa il 20% da contributi esterni ed il caso di Open Office in cui solo il 41% del valore del software è rappresentato dallo sviluppo del prodotto, mentre la restante percentuale è divisa tra promozione, supporto, distribuzione, estensioni, linguaggio, ecc.. L’esempio di Open Office è molto interessante perché mostra un progetto che ha più contributori che sviluppatori.
Il perché un’azienda dovrebbe usare software OS è – a detta del relatore – il fatto che fa risparmiare soldi. Al momento però il software OS rappresenta soltanto il 20% del mercato di tutto il software.

Una compagnia OS è un’azienda che sviluppa un prodotto licenziato sotto una licenza OS.
Per fare soldi dal mondo dell’OS, vi sono varie possibilità:

1. Dual licensing: questo sistema implica il rilascio del prodotto software con due licenze differenti (per esempio licenza commerciale e licenza GPL) a seconda dell’uso che si vuole fare (per scopi commerciali o no). Lo svantaggio principale di tale modello è che gli utenti contribuiscono soltanto per circa 1/10 del valore totale perché devono accettare lo stesso regime di licenza (dual licensing).
2. Dividere OSS da prodotti commerciali: distinguere tra un software base FLOSS ed una versione commerciale basata sulla versione FLOSS ma con l’aggiunta di plugins proprietari. Tipica licenza usata in questo modello: MPL.
3. Badgeware: licenza basata sulla MPL ma con l’aggiunta di una “restrizione di visibilità” come un badge. In questo caso chi usa software badgeware deve quindi mostrare un badge (generalmente un’immagine) che mostri chiaramente l’autore originale.
4. Specialisti del prodotto: questo è il pure modello OS che fa riferimento alle compagnie che hanno creato e mantengono uno specifico progetto software licenziato con una licenza FLOSS. I guadagni vengono esclusivamente da servizi quali corsi per l’uso del software e servizi di consulenza (si suppone infatti che gli sviluppatori siano il miglior aiuto per spiegare o fornire aiuti sul software da loro sviluppato).
5. Platform providers: compagnie che forniscono selezione, supporto, integrazione e servizi su un gruppo di progetti che insieme formano una piattaforma verificata e testata. In questo modo è garantita la qualità del software.
6. Compagnie di selezione/consulenza: compagnie (non necessariamente di sviluppatori) che forniscono servizi di consulenza e di selezione/valutazione di servizi su una vasta gamma di progetti, in modo simile al ruolo di un analista.

La tendenza attuale è quella di spostare il maggior guadagno del software dal prodotto come tale ai servizi aggiuntivi.

Per quanto riguarda l’effettiva possibilità di un lavoro di sviluppo collaborativo, in aree anche diverse dal software, l’esempio più lampante è quello di Wikipedia che risulta essere circa tre volte più vasta dell’Enciclopedia Britannica. Ciò dimostra che in condizioni ideali, l’approccio OSS può essere usato anche in scenari diversi da quello proprio del software con risultati tuttavia sorprendentemente simili.

Considerazioni personali
Il seminario di oggi è stato molto interessante perché ha mostrato come sia possibile e soprattutto conveniente per aziende produttrici di software utilizzare il modello Open Source.
Sebbene forse a tutt’oggi questa scelta non sia ancora particolarmente diffusa, tuttavia è pur vero che vi è un significativo incremento nel numero di aziende che stanno modificando il proprio modello di sviluppo in favore di uno OS.
Sicuramente quindi assisteremo nei prossimi anni a questo radicale mutamento e vedremo quali effettivi vantaggi porterà agli utenti finali.