1 / 52

Open Source Development Model

Open Source Development Model. Modelli e strumenti per lo sviluppo di sistemi open source. Di cosa NON parleremo…. Free software foundation Filosofia open source Licenze (GPL e BSD) Progetto GNU Comunita’ open source Marketing. Di cosa parleremo…. Caratteristiche di un OSP

simone
Download Presentation

Open Source Development Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Open Source Development Model Modelli e strumenti per lo sviluppo di sistemi open source Alberto Ornaghi 2002

  2. Di cosa NON parleremo… • Free software foundation • Filosofia open source • Licenze (GPL e BSD) • Progetto GNU • Comunita’ open source • Marketing Alberto Ornaghi 2002

  3. 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

  4. 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

  5. Open Source Development Model Differenti approcci anche da parte degli autori… • Eric Raymond Cathedral and Bazaar • Nikolai Bezroukov Paradigma scientifico Alberto Ornaghi 2002

  6. Caratteristiche di un OSPDefinizione “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

  7. Caratteristiche di un OSPSviluppatori • Istituzioni scolastiche • Enti di ricerca • Utenti organizzati • Utenti privati • Governi e pubbliche amministrazioni • Distributori di software / hardware Alberto Ornaghi 2002

  8. Caratteristiche di un OSPCome inizia un progetto Open Source (1) • “Ogni buon lavoro software inizia dalla frenesia personale di uno sviluppatore” [Raymond] • Chiede ad amici o colleghi cosa sanno sull’argomento. Alcuni hanno lo stesso problema o problemi simili, ma nessuno ha una soluzione. • Le persone interessate cominciano a scambiarsi pareri e conoscenze sull’argomento • 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

  9. Caratteristiche di un OSPCome inizia un progetto Open Source (2) • I membri del progetto lavorano al problema fino a che non raggiungono dei risultati presentabili. • Si rende noto il lavoro svolto dal gruppo • Arrivano i primi suggerimenti esterni al gruppo • Interazione tra vecchi e nuovi membri del gruppo • Nuove informazioni vengono acquisite • Si ritorna al punto 5 Alberto Ornaghi 2002

  10. Caratteristiche di un OSPVantaggi (1) “Se dai a tutti il codice sorgente, ognuno di essi diventa un tuo ingegnere" [John Gage] • Peer review del codice “Se ci sono abbastanza occhi [che cercano errori], gli errori diventano di poco conto” [Raymond] Alberto Ornaghi 2002

  11. Caratteristiche di un OSPVantaggi (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

  12. Caratteristiche di un OSPVantaggi (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

  13. 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

  14. 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

  15. Principi di sviluppoStile 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

  16. Principi di sviluppoCo-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

  17. Principi di sviluppoAccettazione 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

  18. Principi di sviluppoFine di un progetto • “Quando hai perso interesse in un programma, l'ultimo tuo dovere è passarlo a un successore competente.” [Raymond] Alberto Ornaghi 2002

  19. Caratteristiche di un OSPModello 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

  20. Principi di sviluppoConfronto 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

  21. 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 una promessa plausibile (anche piena di bug). Alberto Ornaghi 2002

  22. 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

  23. Aspetti organizzativiRisorse (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

  24. Aspetti organizzativiRisorse (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

  25. Aspetti organizzativiRisorse (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

  26. Aspetti organizzativiRisorse (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

  27. Aspetti organizzativiRisorse (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

  28. Aspetti organizzativiRisorse (6) • Internet • Infrastruttura virtuale (base di tutte le comunicazioni) • Strumenti di gestione distribuita (vedremo in seguito) Alberto Ornaghi 2002

  29. Aspetti organizzativiCoordinazione 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

  30. Aspetti organizzativiCoordinazione 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

  31. Aspetti organizzativiCoordinazione 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

  32. Aspetti organizzativiCoordinazione 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

  33. Aspetti organizzativiCoordinazione 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

  34. Aspetti organizzativiCoordinazione 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

  35. Aspetti organizzativiCoordinazione 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

  36. Aspetti organizzativiRuoli dei partecipanti al progetto • Ruoli dei partecipanti ad un OSP • Project manager • Maintainer • Sviluppatore • Utente attivo Alberto Ornaghi 2002

  37. 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

  38. 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

  39. CVS repository Alan Linus Dave Strumenti e mezzi di com.Version Control - (CVS) Struttura: - Repository entrale Alberto Ornaghi 2002

  40. 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

  41. Struttura: - Multiple areas Main repository Group repository Group repository Linus Alan Marcelo Rik Andrea Strumenti e mezzi di com.Version Control - (BK) Alberto Ornaghi 2002

  42. 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

  43. 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

  44. 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

  45. New Mail owner Fixed Wontfix Resolved Invalid Moved Duplicated 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 Alberto Ornaghi 2002

  46. 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

  47. 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

  48. 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

  49. ConclusioniCritiche 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

  50. ConclusioniCritiche 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

More Related