Le comunità di sviluppo di Open Source Software: analisi delle pratiche di coordinamento 1 Barbara Scozzi, Politecnico di Bari bscozzi@poliba.

Transcript

1 Le comunità di sviluppo di Open Source Software: analisi delle pratiche di coordinamento 1, Politecnico di Bari Introduzione Negli ultimi anni un interesse crescente è stato rivolto sia da parte di ricercatori che manager verso i progetti di sviluppo di Open Source Software (OSS). Esistono centinaia di progetti open source attualmente sviluppati in tutto il mondo. Tali progetti coprono differenti campi di applicazione come, ad esempio, applicazioni utente (ad es. GIMP, OpenOffice), tool per l infrastruttura di Internet (ad es. Sendmail, Bind), linguaggi di programmazione (ad es. Perl, Python) e giochi (ad es. Paradise). Per la loro dimensione, il successo e l influenza, il sistema operativo Linux e il web server Apache sono probabilmente i più noti. Molti progetti di OSS sono gestiti da team di sviluppo distribuiti. Si tratta di team che si avvalgono del supporto di una comunità di sviluppatori distribuiti su scala mondiale. Questi, a volte senza percepire alcun compenso economico, possono ispezionare e modificare il codice attivando così processi di debugging parallelo ritenuti da molti la maggiore causa per la velocità di sviluppo e, spesso, l affidabilità, portabilità e scalabilità del software risultante (Di Bona et al. 1999, Wayner 2000). Lo sviluppo di OSS rappresenta ancora una questione aperta e un ricco campo di indagine per i ricercatori interessati allo studio delle pratiche di lavoro adottate nell ambito dei team di sviluppo distribuiti. Tali team sono in misura crescente adottati dalle imprese, in particolare per la gestione di processi knowledge intensive (es. sviluppo prodotto). La loro adozione garantisce, infatti, alcuni benefici. Le imprese, in particolare, sono attratte dalla possibilità di fare lavorare i propri dipendenti su una varietà di progetti senza sopportare i costi associati ai viaggi e alle trasferte, e dalla possibilità di riconfigurare velocemente i team per soddisfare le mutevoli esigenze del business (DeSanctis e Jackson 1994). I team distribuiti consentono inoltre di sfruttare le competenze disponibili e l esperienza distribuita su una ampia scala geografica. Si pensi, ad esempio, alla possibilità di una impresa multinazionale di sfruttare la conoscenza degli sviluppatori di prodotto o di individui vicini ai clienti, ma geograficamente distanti dalla casamadre (Orlikowski 2002). Tuttavia, la separazione fra i membri dei team spesso crea problemi nell ambito del coordinamento, della collaborazione e dell apprendimento. Tali problemi possono determinare il fallimento dei team (Jarvenpaa e Leidner 1999, Kraut et al. 1999). Caratterizzati da un insieme di sviluppatori globalmente distribuiti e un processo di sviluppo in molti casi (sebbene sicuramente non in tutti) rapido e affidabile, molti team di sviluppo di OSS in qualche modo eludono le sfide mentre si avvantaggiano dei benefici del lavoro distribuito. L aspetto più sorprendente dei progetti OSS è che essi sembrano non ricorrere ai tradizionali meccanismi di coordinamento adottati dalle imprese (Mockus et al. 2002). I partecipanti descrivono infatti il processo di sviluppo di OSS come mancante dei meccanismi tradizionalmente adottati per coordinare lo sviluppo software, come la gerarchia, i programmi, le progettazioni a livello di sistema e le schedulazioni (Herbsleb e Grinter 1999). Tali considerazioni, sebbene molto diffuse in letteratura, sono ancora basate su pochi casi ben documentati, alcuni dei quali sono particolarmente controversi (si veda a tal proposito Cubranic 1999). Come notato da Scacchi (2002, pag. 1) ancora si sa poco su come le persone in queste comunità coordinano lo sviluppo software tra differenti sedi o su quali processi software, pratiche di lavoro e contesti organizzativi siano necessari al loro successo. 1 In questo lavoro vengono descritti il piano di lavoro e alcuni iniziali risultati dell attività di ricerca correntemente svolta della autrice in collaborazione con il prof. Kevin Crowston (Syracuse University, USA). Il presente lavoro si avvale dei risultati di alcuni lavori precedenti (Crowston e Scozzi, 2002; Crowston, Scozzi e Buonocore, 2002) ed è attualmente in revisione per la pubblicazione. Si prega pertanto di non citare senza il consenso dell autrice. 1

2 Obiettivo del lavoro e research question Il presente studio è finalizzato a investigare le pratiche di coordinamento adottate nell ambito dei progetti di sviluppo di OSS. In particolare le research question a cui si intende trovare una risposta sono le seguenti: Quali sono la struttura organizzativa, le funzioni e le pratiche di coordinamento adottate dai team di sviluppo di OSS, in particolare nell ambito del processo di bug-fixing? Esistono differenze di gestione fra progetti di maggiore e minore successo? Come iniziale ambientazione per lo studio, sarà considerato il processo di bug-fixing, che costituisce un microcosmo di problemi di coordinamento (Crowston 1997). Tale processo è stato scelto perché 1. una soluzione rapida ai bachi esistenti nel software è stata menzionata come un particolare forza del processo di sviluppo di OSS e 2. il processo coinvolge l intera comunità. Lo studio è orientato a capire come vengono trattati i rapporti relativi ai bachi (ad esempio quale è la sequenza delle attività, chi esegue realmente le attività e come sono gestite le dipendenze fra queste), come sono gestiti i rapporti relativi ai sintomi e come sono integrate e testate le procedure di correzione. In questo lavoro viene presentato il piano della ricerca che si intende svolgere ed alcuni iniziali risultati dell attività sin qui condotta. Metodologia di ricerca Per rispondere alle research question si intende condurre un approfondito caso di studio multiplo su circa 10 progetti di sviluppo (Eisenhardt 1989). In particolare verranno svolte le seguenti attività: 1. Selezione dei progetti I progetti da analizzare saranno selezionati adottando una strategia di campionamento basata su due principali dimensioni. Primo, saranno considerati progetti nell ambito dei quali sono coinvolti più di 7-8 sviluppatori. Team più piccoli è, infatti, probabile che debbano affrontare problemi di coordinamento poco significativi. Secondo, saranno selezionati progetti per i quali i dati necessari (es. archivi delle mailing list) sono pubblicamente disponibili. Si tenterà infine di confrontare dati relativi a progetti di maggiore e minore successo (la definizione di successo utilizzata sarà quella proposta in Crowston e Scozzi 2002). I progetti saranno selezionati tra quelli disponibili su SourceForge ( un host creato per supportare progetti OSS. Sourceforge ospita più di progetti, la maggior parte dei progetti dispone di una home page, CVS, mailing lists, servizi di bug tracking, software di gestione delle attività e archivi permanenti di file (tuttavia questi dati non sono sempre accessibili per tutti i progetti). 2. Raccolta dei dati I dati analizzati saranno quelli creati e immagazzinati nei vari sistemi usati dai team (ad esempio i siti web e gli archivi per le ) durante il processo di bug-fixing. In particolare, saranno esaminati dati sui progetti e sugli sviluppatori oltre che dati relativi alle tracce delle interazioni (mailing list e sistemi di bug-tracking) Dagli archivi delle mailing list, saranno estratti la data, il nome di colui/colei che ha spedito il messaggio e di chi l ha ricevuto, il nome di chi l ha inviato inizialmente (in caso di risposte ad uno stesso messaggio) e il testo dei messaggi. Dai sistemi di bugtracking saranno inoltre estratti dati relativi alla tipologia dei bachi, i nomi di coloro che li hanno individuati e/o risolti, e gli step seguiti nell ambito del processo. 2

3 3. Analisi dei dati Il processo di bug-fixing sarà mappato utilizzando una codifica, determinata in maniera induttiva, delle attività svolte per fissare i bachi e registrate nei bug log, messaggi e nel codice. Sarà adottato un metodo simile a quello proposto da (Yamauchi et al. 2000, van de Ven e Poole 1990). Analisi di alcuni risultati iniziali In questa relazione si riportano brevemente i primi risultati dello studio. Sono stati selezionati da SourceForge dieci progetti soddisfacenti i criteri riportati al precedente paragrafo Sinora solo quattro di questi sono stati analizzati: KICQ, DynAPI, Gaim e PhpMyAdmin (Tabella 1). Relativamente ad alcuni di questi sono ancora disponibili solo dei risultati iniziali. KICQ DynAPI Gaim PhpMyAdmin Development 4 Beta, 5 5 Production 5 Production 5 Production Status Production Stable Stable Stable Stable License GPL LGPL, GPL GPL GPL Progr. Language C, C++ JavaScript C Php Operating Sys. Linux OS independent Windows, Bsd, OS independent Linux, Others Bugs 26open/88 total 45open/220 total 269 open/ open/639 total total Support request 12 open/18 total 20 open/107 total Patches 1 open/8 total 14 open/144 total 75 open/ 556 total 7 open/ 131 total Features 9 open/9 total 5 open/12 total 214 open/ open/447 Requests total total Forums 469 messages in 5 forums 5383 messages in 2 forums Mailing lists 813 messages in messages in 304 messages in messages in mailing lists 5 mailing lists mailing list 5 mailing lists Team members Tabella 1. Breve descrizione dei 4 progetti. Sono stati analizzati i bug chiusi contenuti nel bug tracking system dei quattro progetti. In particolare, sono stati esaminati la totalità di bug chiusi di KICQ (62 bug), 100 bug chiusi di Dynapi, 51 bug chiusi di Gaim e 53 di PhPMyAdmin. Per ogni bug chiuso sono stati esaminati i messaggi contenuti nel sistema. Il testo è stato codificato seguendo una procedura induttiva. Ad esempio, il messaggio: I ve been getting this same error every FIRST time I load the dynapi in NS (win32). After reloading, it will work loading/init problem? riguarda evidentemente un rapporto inviato da un utente differente da colui che ha identificato il bug e avviato la procedura di bug fixing. Il messaggio è stato codificato come Report da utenti che hanno lo stesso problema. In questo modo si è pervenuti all identificazione di 25 diverse attività svolte nell ambito del processo di bug fixing. Non sono state identificate sequenze tipo, sebbene chiaramente il processo inizi sempre con l apertura di un bug e termini con la sua chiusura. Alcuni iniziali risultati della suddetta analisi sono riportati nella tabella seguente (Tabella 2). 3

4 Kicq DynAPI Gaim PhpMyAdmin Bug identificati da membri del team 5% 21% 0% 20% Bug identificati da membri esterni al team 55% 43% 84% 41% Bug assegnati a membri del team 73% 6% 47% 78% Bug assegnati a membri esterni al team 6% 11% 0% 4% Bug fissati da membri del team 73% 54% 80% 98% Bug fissati da membri esterni al team 7% 36% 17% 2% Tabella 2. Principali risultati. Questi dati mostrano una netta divisione di compiti tra i membri del team di sviluppo e la comunità (molto più ampia) che generalmente partecipa ai progetti. I bug sono identificati principalmente dalla comunità, mentre sono essenzialmente assegnati e comunque fissati da membri del team di sviluppo. I team sono generalmente costituiti da membri, mentre i membri della comunità che partecipano ai singoli progetti sono spesso almeno di un ordine di grandezza superiore. Peraltro dall analisi si evince che anche nell ambito dei team vi è un numero ristretto di partecipanti più attivi, che generalmente svolgono il ruolo di sviluppatore o amministratore (secondo quanto indicato su SourceForge). Questi primi risultati appaiono coerenti con altri studi svolti in questo ambito. In particolare Iniziatore Utenti Utenti attivi Co-sviluppatori Release coordinat. Core team Figure 1. Struttura delle comunità OSS. questi dati sembrano fornire la verifica empirica dei modelli proposti in (Cox, 1998; Moon & Sproull, 2000), dove la struttura delle comunità di sviluppo viene descritta secondo una forma onion-like come mostrato in Figura 1. Conclusioni Lo studio fornirà importanti approfondimenti sul processo di sviluppo di OSS e sulle ragioni del suo successo. Il progetto presenta due punti di forza. Primo, rappresenta un tentativo iniziale di colmare il gap presente nella letteratura sui team di sviluppo OSS, contribuendo ad allargare le conoscenze e aumentare la comprensione del funzionamento dei team. Identificando la struttura e le pratiche di coordinamento adottate dai team OSS di successo, lo studio sarà utile ai manager che hanno intenzione di adottare queste nuove forme organizzative, eventualmente anche in settori differenti dallo sviluppo software. 4

5 I risultati di uno studio basato sull analisi di 10 progetti non sono ovviamente generalizzabili all intero universo OSS. Le ipotesi sulle pratiche di coordinamento e il successo dei progetti alle quali si perverrà attraverso lo studio saranno pertanto in futuro testate su un numero maggiore di casi. Bibliografia Carmel E., 1999, Global Software Teams. Upper Saddle River, NJ: Prentice-Hall. Cox, A. 1998, Cathedrals, Bazaars and the Town Council, from URL: Crowston K., 1997, A coordination theory approach to organizational process design, Organization Science, 8(2). Crowston K., Scozzi B., 2002, Open source software projects as virtual organizations: Competency rallying for software development, IEE Proceedings Software, 149(1). Crowston K., Scozzi B., Buonocore S., 2002, An exploratory study of open source software development team structure, Rapporto Interno, Syracuse University. Cubranic D., 1999, Open-source software development, 2nd Workshop on Software Engineering over the Internet, Los Angeles. DeSanctis G., Jackson B.M, 1994, Coordination of information technology management: Teambased structures and computer-based communication systems, Journal of Management Information Systems, 10(4). Di Bona C., Ockman, S., Stone M. (Eds.), 1999, Open Sources: Voices from the Open Source Revolution, Sebastopol, CA: O'Reilly and Associates. Eisenhardt K.M., 1989, Building theory from case study research. Academy of Management Review, 14(4). Ghosh R.A., 2002, Free/Libre and Open Source Software: Survey and Study. Report of the FLOSS Workshop on Advancing the Research Agenda on Free / Open Source Software, from Herbsleb J.D., Grinter R.E. 1999, Architectures, coordination, and distance: Conway's law and beyond. IEEE Software September/October. Jarvenpaa S.L., Leidner D.E., 1999, Communication and trust in global virtual teams. Organization Science, 10(6), Kraut R.E., Steinfield C., Chan A.P., Butler B., Hoag A., 1999, Coordination and virtualization: The role of electronic networks and personal relationships, Organization Science, 10(6). Mockus A., Fielding R.T., Herbsleb J.D., 2002, Two Case Studies Of Open Source Software Development: Apache And Mozilla, ACM Transactions on Software Engineering and Methodology, 11(3). Moon, J. Y., & Sproull, L., 2000, Essence of distributed work: The case of Linux kernel. First Monday, 5(11). Orlikowski W.J., 2002, Knowing in Practice: Enacting a Collective Capability in Distributed Organizing, Organization Science, 13(3). Raymond E.S., 1998, The cathedral and the bazaar, First Monday, 3(3). Scacchi W., 2002, Software Development Practices in Open Software Development Communities: A Comparative Case Study (Position Paper). Van de Ven A.H., Poole M.S., 1990, Methods for studying innovation development in the Minnesota Innovations Research Program, Organization Science, 1(3), Wayner P., 2000, Free For All, New York: HarperCollins. 5

6 Yamauchi Y., Yokozawa M., Shinohara T., Ishida T., 2000, Collaboration with lean media: How open-source software succeeds, Proceedings of CSCW 00, Philadelphia, PA. 6