Open Source
Development Model
Modelli e strumenti per lo sviluppo di sistemi
open source
Alberto Ornaghi 2002
1
Di cosa NON parleremo…
•
•
•
•
•
•
Free software foundation
Filosofia open source
Licenze (GPL e BSD)
Progetto GNU
Comunita’ open source
Marketing
Alberto Ornaghi 2002
2
Di cosa parleremo…
•
•
•
•
•
•
•
Caratteristiche di un OSP
Principi di sviluppo
Confronto con altri modelli
Pre-requisiti
Aspetti organizzativi
Strumenti
Critiche al modello
Alberto Ornaghi 2002
3
Open Source
Development Model
Non esiste un modello di sviluppo
software open source…
…possiamo pero’ delineare alcuni punti
in comune tra i diversi progetti Open
Source.
Alberto Ornaghi 2002
4
Open Source
Development Model
Differenti approcci anche da parte
degli autori…
• Eric Raymond
Cathedral and Bazaar
• Nikolai Bezroukov
Paradigma scientifico
Alberto Ornaghi 2002
5
Caratteristiche di un OSP
Definizione
“Ogni gruppo di persone che sviluppa
software e rende disponibili i propri
risultati al pubblico sotto una licenza
open source, costituisce un Progetto
Open Source.” [Evers].
Alberto Ornaghi 2002
6
Caratteristiche di un OSP
Sviluppatori






Istituzioni scolastiche
Enti di ricerca
Utenti organizzati
Utenti privati
Governi e pubbliche amministrazioni
Distributori di software / hardware
Alberto Ornaghi 2002
7
Caratteristiche di un OSP
Come inizia un progetto Open Source (1)
1.
“Ogni buon lavoro software inizia dalla frenesia
personale di uno sviluppatore” [Raymond]
2.
Chiede ad amici o colleghi cosa sanno sull’argomento.
Alcuni hanno lo stesso problema o problemi simili, ma
nessuno ha una soluzione.
3.
Le persone interessate cominciano a scambiarsi pareri
e conoscenze sull’argomento
4.
Le persone interessate che intendono spendere delle
risorse (a questo livello si tratta del proprio tempo
libero) sulla soluzione del problema danno il via ad un
progetto informale.
Alberto Ornaghi 2002
8
Caratteristiche di un OSP
Come inizia un progetto Open Source (2)
5.
I membri del progetto lavorano al problema fino a che non
raggiungono dei risultati presentabili.
6.
Si rende noto il lavoro svolto dal gruppo
7.
Arrivano i primi suggerimenti esterni al gruppo
8.
Interazione tra vecchi e nuovi membri del gruppo
9.
Nuove informazioni vengono acquisite
10.
Si ritorna al punto 5
Alberto Ornaghi 2002
9
Caratteristiche di un OSP
Vantaggi (1)
“Se dai a tutti il codice sorgente, ognuno di essi
diventa un tuo ingegnere" [John Gage]
1. Peer review del codice
“Se ci sono abbastanza occhi [che cercano errori],
gli errori diventano di poco conto” [Raymond]
Alberto Ornaghi 2002
10
Caratteristiche di un OSP
Vantaggi (2)
2. Segnalazione e correzione errori
“Se tratti i tuoi beta-tester come se fossero la tua
risorsa piu’ importante, essi risponderanno
diventando la tua risorsa piu’ importante.”
[Raymond].
Trattare gli utenti come co-sviluppatori è la strada
migliore per ottenere rapidi miglioramenti del
codice e debugging efficace.
Alberto Ornaghi 2002
11
Caratteristiche di un OSP
Vantaggi (3)
3. Sviluppo distribuito
La disponibilita’ dei codici sorgenti permette a
chiunque sia interessato e ne abbia le capacita’ di
partecipare allo sviluppo di un programma. La
misura ed il modo in cui i nuovi sviluppatori
possono collaborare dipende molto, oltre che da
loro, dalla spinta data dall’autore del programma
e dal core-team che guida lo sviluppo.
Alberto Ornaghi 2002
12
Principi di sviluppo
Stile di programmazione (1)





I bravi programmatori sanno cosa scrivere. I migliori
sanno cosa riscrivere (e riusare)
“Preparati a buttarne via uno; dovrai farlo comunque.”
Se hai l'atteggiamento giusto, saranno i problemi
interessanti a trovare te.
Distribuisci presto. Distribuisci spesso. E presta ascolto
agli utenti.
Bad code is better than no code…
Alberto Ornaghi 2002
13
Principi di sviluppo
Stile di programmazione (2)

Non esitare a buttar via opzioni inanellate una
sull'altra quando puoi rimpiazzarle senza perdere in
efficienza. Quando il codice diventa migliore e più
semplice, allora vuol dire che va bene
“La perfezione (nel design) si ottiene non quando
non c'è nient'altro da aggiungere, bensì quando non
c'è più niente da togliere.” [Raymond]

Se scrivi programmi per tutto il mondo, devi dare
ascolto ai tuoi clienti – e ciò rimane valido anche se
non ti ricompensano in denaro.
Alberto Ornaghi 2002
14
Principi di sviluppo
Stile di programmazione (3)

Meglio combinare una struttura dati intelligente e
un codice non eccezionale che non il contrario.
“Mostrami il codice e nascondimi la struttura dati, e
io continuerò a essere disorientato. Mostrami la
struttura dati, e non avrò bisogno del codice; sarà
del tutto ovvio.” [Brooks]

“Il debugging è parallelizzabile” [Jeff Dutky]
Alberto Ornaghi 2002
15
Principi di sviluppo
Co-developers e betatesters


Stabilita una base di beta-tester e co-sviluppatori
sufficientemente ampia, ogni problema verrà
rapidamente definito e qualcuno troverà la
soluzione adeguata. ”Qualcuno scopre il problema e
qualcun altro lo comprende” [Torvalds]
Delega dei compiti
“Praticamente sono una persona molto pigra cui piace
prendersi il merito di quel che sono gli altri a fare.”
[Torvalds]
Alberto Ornaghi 2002
16
Principi di sviluppo
Accettazione nuove idee (apertura mentale)


La cosa migliore, dopo l'avere buone idee, è
riconoscere quelle che arrivano dagli utenti.
Qualche volta sono le migliori.
Spesso le soluzioni più interessanti e innovative
arrivano dal fatto di esserti reso conto come la tua
concezione del problema fosse errata.
“quando non riesci piu’ ad andare avanti, spesso e’ ora
di chiedersi non se hai la risposta giusta, ma se ti stai
ponendo la giusta domanda. Forse bisogna inquadrare
nuovamente il problema.” [Raymond]
Alberto Ornaghi 2002
17
Principi di sviluppo
Fine di un progetto

“Quando hai perso interesse in un programma,
l'ultimo tuo dovere è passarlo a un successore
competente.” [Raymond]
Alberto Ornaghi 2002
18
Caratteristiche di un OSP
Modello e confronti

In fase larvale e’ quasi un Fix & Code

E’ un modello senza dubbio iterativo

Simile al modello evolutivo incrementale


Dal modello COTS riprende la riusabilita’ delle librerie
esistenti
Molti principi sono simili a XP (feedback rapido, semplicita’,
modifiche incrementali, accettazione del cambiamento,
integrazione continua, refactoring)
Alberto Ornaghi 2002
19
Principi di sviluppo
Confronto Cattedrale vs Bazaar

Cattedrale
– Mastodontiche release di versioni definitive
– Debugging tra versioni
– Aspettative di perfezione smentite dai rilasci

Bazaar
– I bug sono intrinseci e marginali
– Rapidita’ di diffusione per ottenere le correzioni
Alberto Ornaghi 2002
20
Pre-condizioni per OSP (1)



Lo stile bazaar non consente la scrittura del codice
partendo da zero.
Si possono fare test, trovare i bug, migliorare il
tutto, ma sarebbe molto difficile dar vita dall'inizio a
un progetto in modalità bazaar.
Bisogna essere in grado di presentare
promessa plausibile (anche piena di bug).
Alberto Ornaghi 2002
una
21
Pre-condizioni per OSP (2)

Gli sviluppatori devono avere qualcosa da far girare
e con cui giocare.

E’ l’idea che deve convincere non il codice

E’ indispensabile un elevato livello di intuizione e
bravura da parte di chi guida il progetto ?
“Non credo sia essenziale che il coordinatore possa
produrre design eccezionali, ma è assolutamente
centrale che sia capace di riconoscere le buone idee
progettuali degli altri.” [Raymond]
Alberto Ornaghi 2002
22
Aspetti organizzativi
Risorse (1)




Informazione e software
L’informazione e’ la risorsa fondamentale per un
progetto open source
Il software e’ un particolare tipo di informazione
L’informazione libera (senza vincoli di trasmissione)
e’ una risorsa inesauribile
Alberto Ornaghi 2002
23
Aspetti organizzativi
Risorse (2)



Risorse personali
In genere la maggior parte dei Progetti Open
Source non dispone di proprie risorse da distribuire
In genere le risorse materiali piu’ diffuse sono
quelle appartenenti al singolo soggetto collaborante
al Progetto. Esse possono essere di vario tipo:
apparecchiature, pubblicazioni e documentazione,
abilita’.
Alberto Ornaghi 2002
24
Aspetti organizzativi
Risorse (3)

Hardware

Risorsa fondamentale per l’esistenza del progetto
– Hardware personale
(di proprieta’ dello sviluppatore)
– Hardware generalmente disponibile
(accesso remoto da parte degli sviluppatori)
– Hardware parzialmente disponibile
(accesso fisico)
Alberto Ornaghi 2002
25
Aspetti organizzativi
Risorse (4)




Risorse umane
I partecipanti di solito sono volontari non pagati
(con qualche eccezione)
In genere gli sviluppatori utilizzano risorse proprie.
Si mette a disposizione dell’azienda solo la propria
professionalita’
Alberto Ornaghi 2002
26
Aspetti organizzativi
Risorse (5)

Risorse finanziarie

Un progetto, di norma, non ha entrate dirette


Le imprese interessate pagano gli sviluppatori per
lavorarci, non finanziano il progetto
Donazioni, sponsorizzazioni meeting, etc …
Alberto Ornaghi 2002
27
Aspetti organizzativi
Risorse (6)

Internet

Infrastruttura virtuale
(base di tutte le comunicazioni)

Strumenti di gestione distribuita
(vedremo in seguito)
Alberto Ornaghi 2002
28
Aspetti organizzativi
Coordinazione ed incentivi (1)

Gestione risorse condivise
“Laddove diverse attivita’ condividano delle risorse
limitate [...], e’ necessario un processo di
allocazione
delle
risorse
per
gestire
le
interdipendenze tra queste attivita’.” [Malone]
– Le risorse illimitate (informazioni) non necessitano di
alcun processo di allocazione, sono disponibili a
chiunque
– Le risorse limitate (umane, tecniche) devono essere
allocate correttamente
Alberto Ornaghi 2002
29
Aspetti organizzativi
Coordinazione ed incentivi (2)

Allocazione risorse umane
Non si puo’ forzare qualcuno a fare qualcosa che
non gli piace fare. Come punizione piu’ grande (non
essendoci retribuzioni) ci sarebbe l’espulsione dal
gruppo, ma questo nuoce piu’ al progetto che allo
sviluppatore.
e’ importante quindi trovare le giuste motivazioni
Alberto Ornaghi 2002
30
Aspetti organizzativi
Coordinazione ed incentivi (3)

Problema Bottleneck
– Nessuno vuole fare lo “sporco lavoro”
– Tutte le attivita’ dipendenti da quello vengono
rallentate fino al freeze.
– A quel punto la noia dara’ la motivazione giusta
per svolgere il lavoro pendente
Alberto Ornaghi 2002
31
Aspetti organizzativi
Coordinazione ed incentivi (4)

Gestione relazioni prod/cons
La natura altamente modulare del software favorisce alti livelli
di riuso. Questo fenomeno e’ molto accentuato nei Progetti
Open Source per due motivi:


Il software usato nel mondo open source e’ fortemente basato
su architetture Unix, concepite per la massima modularita’.
La
disponibilita’
dei
codici
sorgenti
permette
la
cannibalizzazione, il riuso di parti di codice, altrimenti non
disponibili ne’ visibili.
Alberto Ornaghi 2002
32
Aspetti organizzativi
Coordinazione ed incentivi (5)

Relazioni prod/cons
– All’interno del progetto
(dipendenza tra moduli)
– Con altri progetti
per “... non dover inventare la ruota ogni volta”
si usano librerie sviluppate da altri
Alberto Ornaghi 2002
33
Aspetti organizzativi
Coordinazione ed incentivi (6)

Gestione vincoli di simultaneita’
“Un [...] tipo comune di dipendenza tra attivita’ e’
quando devono svolgersi nello stesso momento (o non
devono svolgersi nello stesso momento).” [Malone]
“e’ come se tutti partecipassero alla costruzione di un
grosso puzzle in cui tutti vogliono mettere un tassello
nella stessa posizione. E’ necessario qualcuno che
coordini questa frenesia” [Dave Jones]
Alberto Ornaghi 2002
34
Aspetti organizzativi
Coordinazione ed incentivi (7)

Dipendenze tra compiti e sottocompiti

Scomposizione obiettivi

Unione degli obiettivi (merge tra progetti diversi)
“Diversi attori realizzano che cio’ che stanno gia’
facendo [...] puo’ essere unito per il raggiungimento
di un nuovo obiettivo” [Malone].
Alberto Ornaghi 2002
35
Aspetti organizzativi
Ruoli dei partecipanti al progetto

Ruoli dei partecipanti ad un OSP
– Project manager
– Maintainer
– Sviluppatore
– Utente attivo
Alberto Ornaghi 2002
36
Strumenti e mezzi di com.
Version Control
Le sue principali funzioni sono:
– Conservare l’history del progetto
– Collaborazione distribuita
– Risoluzione conflitti tra commit (merge)
Alberto Ornaghi 2002
37
Strumenti e mezzi di com.
Version Control - (CVS)
Concurrent Versioning System (CVS)
http://www.cvshome.org/
Alcuni pro e contro
Non fornisce (volutamente) lock sui file
 Necessita comunicazione tra i developers
 Gestione dei conflitti

Alberto Ornaghi 2002
38
Strumenti e mezzi di com.
Version Control - (CVS)
Struttura:
- Repository entrale
CVS
repository
Alan
Linus
Alberto Ornaghi 2002
Dave
39
Strumenti e mezzi di com.
Version Control - (BK)

BitKeeper (BK) –
http://www.bitkeeper.com
– Risolve i problemi di CVS
Changeset (tagged tree)
 Possibilita’ di rinominare i file
 Supporto per aree multiple
 Registrazione di tutti gli eventi (merge/unmerge)
 Data integrity (checksum)

Alberto Ornaghi 2002
40
Strumenti e mezzi di com.
Version Control - (BK)

Struttura:
Main
repository
- Multiple areas
Group
repository
Group
repository
Linus
Alan
Marcelo
Rik
Alberto Ornaghi 2002
Andrea
41
Strumenti e mezzi di com.
Messaggistica (1)
E’ necessario avere la possibilita’ di
scambiare informazioni nel modo piu’ rapido
e meno costoso possibile.
–
–
–
–
Discussioni
Modifiche al programma
Comunicazione di difetti o nuove idee
Informazioni relative all’organizzazione interna
del progetto
Alberto Ornaghi 2002
42
Strumenti e mezzi di com.
Messaggistica (2)

Mailing list, Usenet
– Molti a molti (asincrono)

IRC
– Molti a molti (sincrono)

Mail private
– Uno a uno (asincrono)

Instant messaging
– Uno a uno (sincrono)
Alberto Ornaghi 2002
43
Strumenti e mezzi di com.
Bug Tracking system (1)

Tiene traccia e gestisce tutte le segnalazioni sui
difetti di un software.
– Un database dei bug
– Un mezzo di comunicazione per la segnalazione
degli stessi.
– E’ uno strumento di assegnazione compiti
Alberto Ornaghi 2002
44
Strumenti e mezzi di com.
Bug Tracking system (2)

Anatomia del BUG
– Componenti affetti (eventuali dipendenze)
– Versione (milestone)
– Descrizione

Ciclo di vita del BUG
Unconfirmed
New
Fixed
Invalid
Mail owner
Wontfix
Resolved
Moved
Duplicated
Alberto Ornaghi 2002
45
Strumenti e mezzi di com.
Bug Tracking system (3)

Alcuni esempi :
– BugZilla - http://www.mozilla.org/bugs
– Scarab -
http://scarab.tigris.org/
– GNATS -
http://www.gnu.org/software/gnats
– BugManager – http://www.bitmover.com
Alberto Ornaghi 2002
46
Strumenti e mezzi di com.
Build system

Controlla che il repositoy del Version Control sia
compilabile
–
–
–
–
–
Make e affini (il piu’ usato negli scrip automatici)
Gump (compila java – cocoon)
Kbuild (compilazione kernel)
Ant (sostituto di make multipiattaforma)
Ecc ecc
http://www.cmtoday.com/yp/free.html
Alberto Ornaghi 2002
47
Strumenti e mezzi di com.
Visibilita’ del progetto
La visibilita’ e’ di fondamentale importanza
– Sourceforge – http://sourceforge.net




CVS
Bugtracker
Mailing list
Compile farm
– Freshmeat – http://freshmeat.net

Annunci nuove release
Alberto Ornaghi 2002
48
Conclusioni
Critiche al modello open source (1)

Conflitti all’interno del gruppo
–
–
–
–
Competizione basata sullo status
Creazione di strutture gerarchiche
Favoritismi
Cade il principio di “programmazione senza ego”
[Weimberger]
– Esclusione dal gruppo
– Forking del progetto
Alberto Ornaghi 2002
49
Conclusioni
Critiche al modello open source (2)

Mancanza di incentivi
– I progetti tendono ad essere di successo e di
qualita’ solo se c’e’ un interesse da parte degli
sviluppatori attivi
– Poca visibilita’ non porta sviluppatori nuovi
– Bottleneck non risolti
– Perdita di interesse nel progetto
– Progetti che non escono mai dalla fase alpha o
beta (o addirittura rimangono solo astratti)
Alberto Ornaghi 2002
50
Conclusioni
Confronto con modelli Closed Source
Proprietario
OpenSource
Modello
Cattedrale
Bazaar
Risorse
Definite
Sconosciute
Planning
Intero progetto
Step by step
Utenti
Utente pagante
Co-developers
Obiettivo
Risp. del contratto Risolvere un prob.
Motivazione
Forte (stipendio)
Debole (voglia)
Stato di progresso Segreto
Pubblico
Collaborazione
Faccia a faccia
Internet
Assic. di Qualita’
Management
Peer review
Alberto Ornaghi 2002
51
Bibliografia
Eric Raymond - La cattedrale e il bazaar
Steffen Evers - Introduction To Open Source Software Development
Luca Didone’ - Modelli di business per il software libero
Selena Sol - The Open Source Business Model
Christopher Browne - Linux and Decentralized Development
Alberto Ornaghi 2002
52