Analisi delle caratteristiche dei progetti open source

Introduzione 
 
 
2
Lo studio inizialmente si è scontrato con l’impossibilità di poter 
utilizzare i dati di FLOSSmole (progetto open source che mette a 
disposizione alcuni dati del CVS Sourceforge) e per questo si è 
deciso di usare le informazioni contenute del database di Notre 
Dame (stessa finalità di FLOSSmole ma con dati più pertinenti).  
L’analisi ha mostrato immediatamente una scelta infelice nella 
progettazione del meccanismo di tracking di SourceForge, perché di 
default i bugs, le patches, le release etc, se non espressamente 
specificato, sono assegnate al livello di priorità cinque 
(SourceForge utilizza nove livelli di priorità), facendo crescere di 
molto le componenti di questa categoria. Ma ciò, nel caso dei bugs, 
espone i prodotti ad un controllo “superficiale”, perché gli 
sviluppatori, non potendo discriminare “a vista d’occhio” i 
problemi critici (quelli con i livelli più alti), potrebbero preferire 
continuare lo sviluppo del progetto piuttosto che controllare 
periodicamente la scoperta di problemi critici. 
Lo studio dei bugs ha permesso di capire che questi ultimi sono 
distribuiti in ordine crescente rispetto all’aumentare della stabilità 
dei prodotti (SourceForge classifica i prodotti in cinque livelli 
prealpha, alpha, beta, stabile e maturo) fino al livello stabile, mentre 
i progetti maturi presentano mediamente un numero di bugs molto 
inferiore. Di contro, analizzando le patches rilasciate, abbiano 
notato che i progetti ricevono anche loro un numero di 
miglioramenti crescenti finché non si raggiunge l’ultimo livello di 
stabilità (maturo) i quali non ricevono più un cospicuo numero di 
Introduzione 
 
 
3
componenti aggiuntivi, ma, essendo ormai i prodotti consolidati, 
ricevono maggiormente solo le correzioni dei bugs scoperti. 
Inoltre, continuando lo studio dei bugs, è emerso che gli 
sviluppatori tendono a risolvere prima i problemi (bugs) sui progetti 
con una stabilità maggiore (comportamento che ci aspettavamo) e 
successivamente si “dedicano” a sviluppare soluzioni per i software 
appena nati. 
Un risultato opposto a quello che ci si aspettava è stato ottenuto 
studiando il tempo medio di soluzione dei bugs, infatti è stato 
evidenziato che non appena i progetti vengono dichiarati maturi, 
subiscono una sorta di abbandono e il tempo medio di soluzione 
aumenta in misura maggiore rispetto agli altri. 
Un altro risultato inatteso si è avuto nello studio della 
documentazione, perché è emerso che all’interno di SourceForge è 
inserita poca documentazione. Infatti, in valore assoluto i 
documenti presenti confrontati con il numero di progetti gestiti da 
SourceForge (circa 130.000 al momento in cui si è stato compiuto 
lo studio) rappresentano appena il 10%. C’è da dire (ad onor del 
vero), che un’analisi fatta fuori da SourceForge, ha mostrato che 
molte comunità forniscono la documentazione del proprio progetto 
direttamente dal proprio sito, usando il CVS espressamente per lo 
sviluppo ed il download. 
Questo lavoro di tesi ci ha permesso di capire che la strada 
intrapresa è quella giusta, infatti una prima sensibilizzazione 
Introduzione 
 
 
4
potrebbe essere fatta verso le comunità che sviluppano i sistemi di 
tracking al fine di evitare i problemi visti con quello di SourceForge 
(si ricordi infatti la cattiva gestione di assegnamento alla priorità 
intermedia). Inoltre i problemi riscontrati ci hanno permesso di 
comprendere quali caratteristiche migliorare per effettuare analisi 
più pertinenti, come ad esempio la centralizzazione dei dati in un 
unico database e l’accesso diretto allo stesso.  
 
Struttura della Tesi 
 
 
5
Struttura della Tesi 
 
 
Nel primo capitolo, si introduce il mondo open source descrivendo, 
tramite le licenze e i metodi di distribuzione dei software, la 
filosofia che si trova dietro questo mondo e i problemi etici che ne 
hanno permesso la nascita. Viene inoltre sottolineata la differenza 
tra il software libero e l’open source, fino a giungere alla nascita dei 
CVS e dei repository, illustrandone le funzionalità e le potenzialità 
messe a disposizione. 
Nel secondo capitolo, viene introdotto il problema della scelta dei 
software open source e come questi vengono valutati al fine di 
trovare quello più adatto alle proprie esigenze. Vengono inoltre 
presentati e analizzati i principali metodi di valutazione esistenti.  
Il terzo capitolo mostra le caratteristiche che saranno analizzate 
suddividendole in tre grosse macro aree: la valutazione delle qualità 
esterne, l’attività delle comunità ed il supporto a breve termine.  
Il quarto capitolo analizza in primis il CVS di SourceForge, e le sue 
peculiarità, successivamente si occupa dell’approccio ai dati del 
database di FLOSSmole prima e quelli di Notre Dame dopo, 
spiegando nel dettaglio il perché non è stato possibile utilizzare gli 
elementi di FLOSS. Questi due database seppur con approcci 
diversi e ampiamente spiegati nel capitolo, mettono a disposizione 
Struttura della Tesi 
 
 
6
delle comunità scientifiche i dati del CVS SourceForge. Vengono 
inoltre illustrati i problemi riscontrati anche con il database di Notre 
Dame e le sue incongruenze.  
Nel quinto capitolo invece si mostrano i risultati dell’analisi di tutte 
le caratteristiche studiate, le scoperte ottenute e i risultati inattesi 
che si sono avuti. Lo studio viene presentato con l’ausilio di grafici 
che permettono di illustrare le differenze tra le varie componenti 
esaminate.  
Il sesto capitolo è dedicato infine alle conclusioni a cui siamo giunti 
e agli sviluppi futuri di cui questo lavoro di tesi può essere il 
principio. Si riportano le appendici con le query sviluppate per 
reperire i dati, i valori di timestamp usati per l’analisi sul semestre e 
le tabelle del database di Notre Dame che posseggono i dati di 
questo lavoro. 
 
Capitolo Primo 
 
 
7
Capitolo Primo 
 
1.1. PREMESSA 
 
 
n questi ultimi anni si sente sempre più parlare di software 
Open Source, software free, proprietario etc…, confondendo 
spesso il software e la sua licenza con il modo in cui viene 
distribuito. Non è difficile, infatti, sentir parlare di software Open 
Source allo stesso modo in cui si parla di software Freeware, ma 
questo è errato. Proviamo a fare un po’ di chiarezza. 
Il software nel 1984 viene definito dall’OMPI
1
 come “Espressione 
di un insieme organizzato e strutturato di istruzioni (o simboli) 
contenuti in qualsiasi forma o supporto (nastro, disco, film, 
circuito), capace direttamente o indirettamente di far eseguire o far 
ottenere una funzione, un compito o un risultato particolare per 
mezzo di un sistema di elaborazione elettronica dell’informazione”. 
Ma il software è un’opera di ingegno e, pertanto, un bene 
immateriale, infatti “il valore del software, anche sotto il profilo 
giuridico, non sta nel supporto su cui è registrato, ma nel suo 
                                                 
 
1
 OMPI Organizzazione Mondiale della Proprietà Intellettuale; 
I
Capitolo Primo 
 
 
8
contenuto ideativo e il pericolo che corre il suo autore non è tanto 
che gli sia sottratto quel supporto, ma che sia plagiato 
indebitamente da altri quel contenuto”.
2
 
Quindi, a differenza di quanto asserito dall’OMPI che utilizza una 
definizione riduttiva, il software è un prodotto dell’ingegno e come 
tale deve essere tutelato. Per tale motivo ogni prodotto software 
viene, quindi, distribuito associandolo ad una licenza d’uso, ed è 
questa licenza che stabilisce come può essere utilizzato ed 
eventualmente ridistribuito. 
 
1.2. CATEGORIE DI LICENZE 
 
 
La licenza del Software Libero
3
 rispetta le caratteristiche richieste 
dalla Free Software Foundation, la quale prevede che un software 
può essere utilizzato, studiato, adattato, migliorato e ridistribuito 
liberamente. La disponibilità del codice sorgente deve essere un 
prerequisito. Questo tipo di licenza ha una maggiore valenza etica, 
in quanto valorizza la libertà del software e di chi lo produce. 
Questo non significa che produrre software libero implichi la non 
commercializzazione, infatti nulla vieta di scrivere software 
utilizzando questa licenza ma commercializzando il prodotto finito. 
                                                 
 
2
 R. Borruso, La tutela giuridica del software. Diritto d’autore e brevettabilità, Milano, 1999, 
pag. 3 
3
 http://www.fsf.org/licensing/essays/free-sw.html 
Capitolo Primo 
 
 
9
Ovviamente nel corso della storia questa licenza è stata criticata 
ferocemente soprattutto dalle grandi industrie costruttrici di 
software che utilizzano software proprietario.  
Simile è la licenza del software Open Source che soddisfa le 
condizioni della Open Source Definition
4
 elaborata dall’Open 
Source Initiative
5
. Tale definizione si avvicina a quella espressa 
dalla Free Software Foundation, ma è stata pensata per motivi e 
destinatari diversi. Il software viene lasciato nella disponibilità 
degli sviluppatori che vorranno modificarlo, in modo tale che, con 
la collaborazione libera (ma nulla vieta che possa essere pagata), il 
prodotto finale possa raggiungere una complessità maggiore 
rispetto a quella che potrebbe ottenere un singolo gruppo di 
programmatori. 
Altro tipo di licenza è quella del Software Copylefted
6
, in cui le 
condizioni di distribuzione non permettono ad eventuali altri 
ridistributori di apporre restrizioni al momento della ridistribuzione 
o modifica del software. Ciò implica che ogni copia del software, 
anche se modificata, deve essere rilasciata come software libero e 
con la stessa licenza, quindi il software derivato deve essere ancora 
libero. La licenza Copylefted più diffusa è la GPL
7
 (General Public 
License). 
                                                 
 
4
 http://opensource.org/docs/osd 
5
 http://opensource.org 
6
 http://www.gnu.org/copyleft/copyleft.html 
7
 http://www.gnu.org/copyleft/gpl.html 
Capitolo Primo 
 
 
10
Ispirata a principi totalmente differenti è la licenza del Software 
Proprietario che concede all’utente solo ed esclusivamente l’utilizzo 
del prodotto, e sotto condizioni e restrizioni dettate dal proprietario 
stesso. Queste restrizioni possono essere di tipo tecnico rendendo 
pubblico solo il codice binario e non divulgando il codice sorgente. 
In questi casi la modifica del software risulta molto difficile, ed 
ottenibile solo con metodi di “reverse engineering” ovviamente 
vietati dalla licenza stessa. Altre restrizioni sono invece di tipo 
giuridico e consistono nella protezione del software con brevetti e 
copyright. 
Un altro termine utilizzato per indicare solitamente il software 
proprietario è: Closed Source Software, che si pone in diretta 
contrapposizione con il concetto di “Open Source Software”. Tale 
termine è utilizzato anche per indicare quel software distribuito con 
il codice sorgente, ma senza la possibilità di modificarlo.  
Altro esempio di licenza è quella del Software semi-libero che 
attribuisce esclusivamente ai privati il permesso di usare, copiare, 
distribuire e modificare il software purché ciò avvenga senza scopo 
di lucro (incluse le versioni distribuite con modifiche). Infatti i 
vincoli maggiori vengono posti proprio sulla vendita.  
Molto più generica è la definizione di Software non libero, in 
quanto tratta in generale quel software la cui licenza non soddisfa 
tutte le richieste della definizione di software libero. 
Capitolo Primo 
 
 
11
Il software di pubblico dominio, invece, è quel software privo di 
proprietario e di copyright. E’ un caso speciale di software libero 
senza permesso d'autore: chi lo utilizza gode della maggior parte 
dei diritti del software libero, ma non ha nessuna garanzia che tali 
diritti permangano, in quanto chiunque può appropriarsene e 
rendere proprietarie le versioni modificate, inserendo vincoli sulle 
modifiche e distribuendo il prodotto come software proprietario. 
 
1.3. DISTRIBUZIONE DEL SOFTWARE  
 
Dopo aver esaminato i diversi tipi di licenze è necessario 
scongiurare un’altra confusione che di solito si fa in questo campo: 
confondere la licenza che accompagna il tipo di software (quelle 
appena descritte es. open source vs software proprietario) e come 
questo venga distribuito. In generale la distribuzione è indipendente 
dalla libertà offerta dalla licenza. 
Il Software commerciale è quello che viene venduto in qualsiasi 
modo. Il software commerciale per eccellenza è quello prodotto da 
Microsoft
8
 che utilizza una licenza di tipo proprietario.  Tuttavia, ci 
sono anche software open source che hanno lo stesso tipo di 
distribuzione come ad esempio EMACS scritto da Richard Matthew 
                                                 
 
8
 http://www.microsoft.com 
Capitolo Primo 
 
 
12
Stallman
9
 (il fondatore della Free Software Foundation) e venduto 
dalla Free Software Foundation stessa.  
Altro metodo di distribuzione è lo Shareware. Con tale termine si 
indica la distribuzione di quei programmi che possono essere 
utilizzati in prova per un determinato periodo di tempo, ma che 
necessitano del pagamento di una quota di registrazione per essere 
utilizzati oltre il tempo stabilito. Questo tipo di distribuzione viene 
usata sia per programmi di tipo proprietario, sia per quelli liberi, 
attraverso la richiesta di una donazione agli autori o al progetto.  
A differenza della distribuzione di tipo shareware, i software 
distribuiti come Adware possono essere utilizzati senza richieste di 
pagamento, ma in cambio mostrano delle inserzioni pubblicitarie 
durante il funzionamento. Alcuni tipi di programmi sfruttano questa 
distribuzione per installare piccoli moduli che oltre a scaricare la 
pubblicità in linea con le abitudini degli utenti, inviano alla 
software house informazioni personali degli stessi. Questa 
distribuzione viene usata per software proprietario, anche perché la 
disponibilità dei codici sorgenti renderebbe facile l’individuazione 
di queste minacce alla privacy.  
Infine, abbiamo il Software gratuito che, come indica la parola 
stessa, viene ceduto gratuitamente. Solitamente i programmi open 
source rientrano in questa categoria ed è proprio questa situazione 
che genera le incomprensioni tra licenza e tipo di distribuzione. 
                                                 
 
9
 http://www.stallman.org/