Un nuovo modo di sviluppare software

La crescita del fenomeno del software libero/open source e in particolare la creazione di programmi di qualità nati dalla collaborazione remota e decentralizzata di sviluppatori di diversi paesi ha rovesciato alcuni assunti classici dell’ingegneria informatica, secondo i quali il software di qualità sarebbe ottenibile soltanto attraverso una gestione centralizzata dei compiti dei programmatori e un rigido controllo dell’accesso ai sorgenti.

Uno dei primi tentativi di far luce sulle caratteristiche di questo modello è rintracciabile nel saggio di Raymond “La cattedrale e il bazaar” . Il sistema tradizionale di sviluppo del software viene qui paragonato allo stile di costruzione delle cattedrali medioevali, caratterizzato da un forte controllo centrale, in contrapposizione allo “stile di sviluppo a bazaar”, in cui la divisione dei compiti viene effettuata attraverso comunicazioni informali tra programmatori e buona parte del codice è costituito da piccoli moduli indipendenti sviluppati spontaneamente dagli interessati.

E’ necessario sfatare il mito che tutto il software libero sia basato su questo modello così come l’illusione che esso derivi in linea diretta dalla strategia di licenziamento “libera”.

Allo stesso tempo bisogna notare che i progetti open source di maggiore successo sono scaturiti proprio dall’applicazione di questo modello, in ogni caso inapplicabile nei progetti proprietari.

Attraverso un’attenta analisi dello sviluppo di Fetchmail (un programma di gestione della posta elettronica) e basandosi sull’esperienza di Linus Torvalds nella creazione del kernel Linux, Raymond evidenzia alcune caratteristiche interessanti dello stile “bazaar”.

Molti progetti open source nascono dalla necessità personale di un programmatore, in cerca di una particolare funzionalità per svolgere alcuni compiti. Diversi studi pongono l’accento sul desiderio di risolvere un particolare problema di programmazione come molla scatenante di un progetto.

Il punto di partenza generalmente è costituito da una certa quantità di codice già disponibile ma sporco o incompleto, che costituisce la base su cui iniziare a lavorare.

Questa base di codice deve essere portata dall’iniziatore del progetto ad un livello base di usabilità, in modo da attirare utenti desiderosi di vedere crescere il programma.

E’ qui importante far notare che  storicamente i sistemi basati su Unix sono utilizzati prevalentemente da programmatori e tecnici informatici. Su questi sistemi ogni utente è un potenziale co-sviluppatore.

Analizzando la strategia di coordinamento di Torvalds, Raymond fa notare come il rapido successo di Linux sia dipeso dalla tendenza a trattare tutti i suoi utenti come co-sviluppatori, rilasciando nuove release  a ritmo sostenuto, in modo da incoraggiarli a rispedire con frequenza le patch  di debug. Gli utenti venivano ricompensati dalla soddisfazione di prendere parte ad una azione collettiva che produceva risultati costanti.

Non venivano coinvolti soltanto gli sviluppatori veri e propri ma anche gli utenti che segnalavano dei bug o che fornivano dei semplici suggerimenti.

Le possibilità di successo di un progetto dipendono dalla capacità del leader-manutentore di ascoltare i propri utenti e di farli sentire importanti rispetto alla buona riuscita del progetto.

Uno stile di sviluppo di questo tipo è reso possibile dalle caratteristiche del medium Internet, adatto alla collaborazione volontaria, aperta, distribuita e flessibile.

Gli strumenti primariamente utilizzati dagli sviluppatori per comunicare tra loro sono molteplici: mailing list, forum, chat, sistemi di file-sharing per lo scambio di documenti e sistemi di telefonia via Internet.

La capacità di un progetto di attirare intorno a sé un grande numero di utenti co-sviluppatori dipende anche dalla struttura iniziale che viene data al codice del programma.

Il kernel Linux ha subito mostrato chiaramente che quanto ci serve è un sistema il più possibile modulare. Il modello di sviluppo open source lo vuole, per non avere gente che lavori simultaneamente sugli stessi punti .

La modularità permette una ottimale distribuzione dei compiti ed è fondamentale per assicurare ad ogni potenziale sviluppatore la possibilità di poter lavorare su ciò che più lo entusiasma senza interferire su altre parti di codice.

La suddivisione in moduli permette non solo l’aggiunta di nuove funzionalità senza interferire sull’intero sistema, ma anche la ripartizione del lavoro tra più sviluppatori.

Baldwin e Clark  considerano anche le proprietà “opzionali” dei moduli, ovvero la capacità di ogni modulo di supportare un nuovo design senza essere obbligato ad adottarlo.

L’opzionalità genera una situazione in cui ogni contributo (anche quando non verrà adottato) accresce il valore dell’intero sistema senza togliere valore agli altri contributi individuali.

Se da un lato la modularità permette l’aggiunta di nuove funzionalità e la sperimentazione senza rischi, da un’altro lato, come fa notare Bezroukov , essa può portare ad un approccio conservatore dell’architettura di un programma già sviluppato.

Il grande successo di alcuni progetti open source e in particolare il grande numero di sviluppatori coinvolti in alcuni di questi (uno per tutti il kernel Linux) hanno contribuito a diffondere l’idea che il software libero sia sempre creato da una  vasta comunità di programmatori.

Questa concezione, seppur capace di descrivere ottimamente alcuni progetti, non riflette il reale processo di creazione di un gran numero di programmi rilasciati sotto licenze libere.

Krishnamurthy , in uno studio basato sull’analisi di 100 progetti open source, rileva come gran parte di essi siano stati guidati da un numero ridotto di partecipanti, tanto da suggerire la sostituzione del termine comunità, sovente usato per indicare l’insieme degli sviluppatori di un particolare programma, con quello di associazione volontaria.

Dobbiamo però notare come il processo collettivo di creazione del software open source non venga alimentato solamente dagli sviluppatori che contribuiscono concretamente attraverso donazioni di codice: parte integrante del lavoro è svolto da un numero maggiore di persone che si occupano di fissare i bachi e da un numero ancora più ampio di utenti che li individuano.

Lo studio di Mockus, Fielding e Herbsled , incentrato sul processo di sviluppo del web server Apache e del browser Mozilla, indica come le persone che fissano i bachi siano di un  ordine di grandezza superiore rispetto ai componenti del team principale e quelle che li individuano siano di un ordine di grandezza superiore ai primi.

Una visione soddisfacente del processo di sviluppo open source si può ottenere soltanto includendo  nell’oggetto dell’osservazione tutti i suoi partecipanti, cercando di definirne i rispettivi ruoli e gettando luce sul grado di mobilità esistente tra i differenti livelli di coinvolgimento.

Segnala questa pagina a qualcuno
Stampa questa pagina