diff --git a/_posts/2022-10-12-open-source.md b/_posts/2022-10-12-open-source.md deleted file mode 100644 index 8ea0a674d6c455b205957d40c9526df75704b7d0..0000000000000000000000000000000000000000 --- a/_posts/2022-10-12-open-source.md +++ /dev/null @@ -1,160 +0,0 @@ ---- -layout: post -title: "[04] Open source" -date: 2022-10-12 14:40:00 +0200 -toc: true ---- - -# Open source - -Apriamo ora le porte a un nuovo modo di sviluppare software che si è molto diffuso negli ultimi decenni ed è ora alla base di progetti applicativi molto importanti e famosi: il processo __open-source__. In due parole, un software open-source è un software il cui codice è liberamente consultabile online e il cui sviluppo si basa non su un singolo team ma su una community di sviluppatori indipendenti. - -Queste prospettive stravolgono l'idea di sviluppo classico, per cui affrontiamo le numerose differenze a partire da una famosa metafora forgiata da Eric Raymond. - -## _The Cathedral and the Bazaar_ - -Raymond propone nel suo [articolo](http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/) due immagini per descrivere i due mondi contrapposti closed-source e open-source: - -- la __cattedrale__ (closed source): si tratta di un ambiente molto gerarchizzato, fortemente legato al progetto iniziale di un unico "architetto" responsabile dei lavori; -- il __bazaar__ (open source): è l'ambiente più anarchico possibile, in cui ognuno lavora per sé e costruisce espandendo ciò che gli altri hanno già fatto. - -Entrambe le costruzioni risultano splendide e attraenti, ma sono chiaramente legate a modi di pensare la costruzione e la progettazione totalmente opposti. - -### Vita e vantaggi di un progetto open-source - -Nell'articolo Raymond prosegue a descrivere come nasce un progetto open-source, esordendo con la seguente citazione: - -> Ogni buon lavoro software inizia dalla frenesia personale di un singolo sviluppatore. - -Si delinea dunque la seguente timeline di un progetto open-source: - -1. Uno sviluppatore ha un problema e intende risolverlo sviluppando un'applicazione. -2. Lo sviluppatore 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. Coloro che intendono spendere delle risorse (di fatto il proprio tempo libero) per risolvere il problema danno il via ad un progetto informale. -5. I membri del progetto lavorano sul problema finché non raggiungono dei risultati presentabili. - - Fino a qui però il progetto non è ancora definibile open-source in quanto vi lavora solo un gruppo ristretto di amici e conoscenti: il vero progetto open nasce quando __viene messo online a disposizione di tutti il codice sorgente__. Continuando, dunque: - -6. Si rende noto il lavoro online e arrivano i primi suggerimenti esterni al gruppo: questi saranno tanto più frequenti quanto più il progetto pubblicato presenterà errori in quanto la comunità, principalmente composta da altri sviluppatori, sarà motivata a risolverli. -7. Si crea interazione tra i vecchi e i nuovi membri del gruppo di sviluppo. -8. Nuove informazioni e competenze vengono acquisite e si ritorna al punto 5. - -Raymond continua esponendo alcune delle caratteristiche e dei vantaggi dei progetti open-source, primo fra tutti il fatto che: - -> Se dai a tutti il codice sorgente, ognuno di essi diventa un tuo ingegnere. - -dove con questo si intende che la possibilità di vedere e commentare il codice sorgente permette a utenti esperti di suggerire modifiche e prendere parte attiva allo sviluppo. Talvolta si tende però a pensare che un progetto di questo tipo sia destinato unicamente ad altri informatici o sviluppatori, ma ciò non è affatto vero: tante attività utili a portare avanti un progetto open-source non richiedono necessariamente competenze informatiche, come per esempio la segnalazione di bug o la moderazione di contenuti nella comunità. - -A tal proposito, è importante il seguente concetto: - -> Se ci sono abbastanza occhi [che cercano errori], gli errori diventano di poco conto. - -Non c'è molto da spiegare: più sono le persone che controllano e leggono il codice più sarà probabile trovare gli errori in esso contenuti; inoltre, gli errori rilevati possono essere risolti più facilmente grazie al supporto della community di sviluppatori, che potrebbe già conoscere una soluzione. \ -L'accento posto sulla community viene ulteriormente rimarcato dal valore che viene attribuito ai beta-tester, che in un progetto open-source è chiunque utilizzi l'applicazione in qualunque suo stadio vista la sua estrema malleabilità: - -> Se tratti i tuoi beta-tester come se fossero la tua risorsa più importante, essi risponderanno diventando la tua risorsa più importante. - -Per mantenere attiva la community di sviluppatori è però necessario un costante monitoraggio e cura; per permettere al progetto open-source di sopravvivere anche quando l'interesse dei creatori originali si è spento è fondamentale passarne il controllo a qualcuno di fidato e competente, come ci ricorda Raymond nell'ultima citazione che riportiamo: - -> Quando hai perso interesse in un programma, l'ultimo tuo dovere è passarlo a un successore competente. - -Spesso questo passaggio di testimone non viene fatto e il progetto muore: occorre invece trovare qualcuno di interessato allo sviluppo, anche perché un programma in uso dovrà necessariamente cambiare ed evolvere in futuro. - -## Confronto tra modelli - -Per capire meglio i concetti fondanti del mondo open-source mostriamo in un modo sintetico un confronto tra lo stesso e i metodi di sviluppo tradizionale e agile nel riguardo di svariati concetti: - -| Cosa | Tradizionale | Agile | Open source | -|------|--------------|-------|-------------| -| __Documentazione__ | La documentazione è enfatizzata come strumento di controllo qualità e gestione. | La documentazione è de-enfatizzata. | Tutti i manufatti di sviluppo sono disponibili a chiunque, compresi il codice e la documentazione. | -| __Requisiti__ | Gli analisti traducono le necessità dell'utente in specifiche software. | Gli utenti fanno parte del team. | Gli sviluppatori spesso sono anche gli utenti. | -| __Assegnamento dello staff__ | Gli sviluppatori sono assegnati ad un unico progetto. | Gli sviluppatori sono assegnati ad un unico progetto. | Gli sviluppatori tipicamente lavorano su più progetti con diversi livelli di partecipazione (_impossibile pianificare lo sviluppo_). | -| __Revisione del codice paritaria__ | La revisione del codice tra pari è ampiamente accettata ma raramente effettuata. | La _pair programming_ introduce una forma di revisione del codice tra pari. | La revisione del codice è una necessità ed è praticata quasi universalmente. | -| __Tempi di rilascio__ | Tante feature in poche release massicce. | Tante piccole release incrementali. | Gerarchia dei tipi di release: _nightly_ (compilazione giornaliera dal branch master), _development_ e _stable_. | -| __Organizzazione__ | I team sono gestiti dall'alto. | I team sono auto-organizzati. | I contributori individuali decidono per sé come organizzare la propria partecipazione. | -| __Testing__ | Il testing è gestito dallo staff di _Quality Assurance_ (QA), che segue le attività di sviluppo. | Il testing è parte integrante dello sviluppo (TDD). | Il testing e la QA possono essere svolti da tutti gli sviluppatori. | -| __Distribuzione del lavoro__ | Parti differenti della codebase sono assegnate a persone differenti. | Chiunque può modificare qualsiasi parte della codebase. | Chiunque può modificare qualsiasi parte della codebase, ma solo i _committer_ possono rendere ufficiali le modifiche. | - -<p><!-- ugly spacer --></p> - -## _Care and Feeding of FOSS_ - -Ma come si inserisce il modello di sviluppo open-source in un panorama tecnologico sempre più accentrato nelle mani di poche e potenti aziende? Il timore è infatti quello che rendendo il codice disponibile a tutti si potrebbe essere subito vittima di plagio da parte di giganti del settore in grado di realizzare in poco tempo ciò che prenderebbe a un team open-source svariati mesi, accaparrandosi così una larga fetta di mercato. Craig James smentisce tuttavia tale visione nel suo [articolo](https://web.archive.org/web/20081015010505/http://www.moonviewscientific.com/essays/software_lifecycle.htm), in cui descrive il ciclo di vita di un software FOSS (Free and Open Source Software) come la sequenza delle seguenti fasi: - -1. __Invenzione__: qualcuno ha un'idea e la implementa facendola funzionare. -Dal momento in cui l'idea viene resa pubblica si assiste una grossa esplosione di progetti in tal senso finanziati da varie aziende che cercano di diventare leader nel nuovo mercato. -2. __Espansione e innovazione__: il mondo si accorge dell'invenzione e la tecnologia inizia a espandersi in quanto le aziende si 'rincorrono' a vicenda cercando di aggiungere più funzionalità possibili. Questa fase non rappresenta un buon momento per far nascere un progetto open source: un piccolo gruppo non riuscirebbe a prevalere sulle grandi aziende; poiché inoltre le specifiche non sono ancora ben definite si rischierebbe di implementare funzioni inutili. -3. __Consolidamento__: i prodotti di alcune aziende iniziano a dominare il mercato, mentre i competitor vengono assorbiti, falliscono o diventano di nicchia. Diminuisce complessivamente il numero di player e l'innovazione rallenta. -4. __Maturità__: il problema e le specifiche sono ora ben chiare e consolidate. Per un prodotto commerciale è ormai difficile entrare nel mercato, ma per uno open source è paradossalmente il momento migliore: il piccolo team ha uno slancio innovativo che le grosse aziende non hanno più e il loro prodotto può brillare dei vantaggi del mondo open-source, tra cui sicurezza e flessibilità. -5. __FOSS Domination__: lentamente, il prodotto open-source inizia a erodere il vantaggio tecnologico dei competitor commerciali, che d'altra parte non hanno alcun interesse ad innovare ulteriormente: ciascuna loro innovazione potrebbe infatti essere facilmente copiata ed essi sono inoltre già largamente rientrati del loro investimento iniziale. Il prodotto open-source inizia ad accaparrarsi fette di mercato. -6. __The FOSS era__: alla fine il progetto open-source domina completamente il nuovo mercato, mentre le grandi aziende devono ripiegare sulla vendita di servizi più che di software. - -Il vantaggio di un progetto open-source non è dunque tanto la rapidità di espansione o l'abilità di intercettare il mercato, quanto il fatto che esso permetta una continua innovazione che _segue_ le necessità del mercato, cosa che le grandi aziende faticano a conseguire in quanto ancora legate a un paradigma di investimento in cui una volta fatto il lavoro e guadagnato un tot è più costoso fare manutenzione del software piuttosto che lasciarlo morire. - -## _The Emerging Economic Paradigm Of Open Source_ - -Affrontiamo ora un fenomeno interessante: perché sempre più aziende investono in software open-source? A prima vista parrebbe un controsenso, perché da sempre i produttori di software proteggono il proprio prodotto tramite segreto aziendale: avere codice liberamente consultabile distrugge tale privatezza ed espone all'ascesa di competitor. Per rispondere a questa domanda ci serviamo di un [articolo](http://web.archive.org/web/20120724095330/http://perens.com/works/articles/Economic.html) di Bruce Perens sull'argomento. - -Perens fa in primo luogo notare che spesso per diverse aziende il software da sviluppare non è il prodotto, ma una __tecnologia abilitante essenziale__: per esempio, Amazon sviluppa molto software per il sito di e-commerce ma il suo prodotto non è il sito. In tali ambiti la scrittura di codice è un _costo_, non il prodotto su cui guadagnare. - -Dal punto di vista economico è poi importante stabilire se la tecnologia dà un vantaggio competitivo, ovvero se essa è __differenziante__ o __non differenziate__. Per fare ciò è sufficiente rispondere alle seguenti domande: - -- __Il cliente si accorge degli effetti del software?__ Per esempio, le persone si accorgono dell'esistenza del sistema di raccomandazione dei libri di Amazon? -- __I competitor non hanno accesso allo stesso software?__ Se Amazon usasse il sistema di raccomandazione venduto anche a Feltrinelli allora non avrebbe senso mantenerlo privato. - -Se la risposta a una delle due domande è no, avere un software proprietario non apporta alcun vantaggio: un modello di sviluppo open-source sparpaglia invece i costi e genera valore, motivo per cui sempre più aziende lo scelgono. - -Perens conclude il suo articolo riportando una matrice in cui confronta 4 diversi modelli di sviluppo, ognuno con le sue caratteristiche che ne determinano l'applicabilità in diverse situazioni: - -- __Retail__: il software è sviluppato per poter essere venduto a chiunque lo desideri; -- __In-House & Contract__: il software è sviluppato per un singolo committente; -- __Consortium & Non-Open-Source Collaboration__: un modello secondo cui diverse aziende concorrenti si mettono insieme per sviluppare un software comune (molto poco diffuso); -- __Open Source__: il software è disponibile gratuitamente e il suo codice è pubblico. - -Tali modelli vengono valutati in base all'efficienza (_quanti soldi vanno agli sviluppatori_), al tasso di fallimento del progetto, ai costi di distribuzione, al rischio di plagio, al fatto di proteggere o meno la differenziazione a livello commerciale del cliente e/o del venditore e alla dimensione richiesta del mercato perché il progetto sia un successo. - -{% responsive_image path: 'assets/04_confronto.png' %} - -Come si può notare dalla tabella, non tutti i paradigmi proteggono il vantaggio competitivo, con differenze dal punto di vista del cliente e del produttore: è dunque importante scegliere il modello di sviluppo che più si confà alle proprie esigenze. - -## _An empirical study of open-source and closed-source software products_ - -Concludiamo il discorso sul mondo open-source riportando uno [studio](https://www.researchgate.net/publication/3188403_An_empirical_study_of_open-source_and_closed-source_software_products) portato avanti da J.W. Paulson e altri con lo scopo di verificare alcune affermazioni ritenute vere nei riguardi del software open-source. - -{% responsive_image path: 'assets/04_empirical-study.png' %} - -Per ognuna di tali affermazioni l'articolo definisce una metrica e la calcola nei riguardi di progetti open-source e closed-source, concludendo così che solo alcune delle dicerie sull'open-source risultano vere mentre molte altre (es. _è più sicuro_, _è più veloce_) si rivelano essere al più circostanziali. - -## Le sfide del modello open-source - -Per sua natura il sistema di sviluppo open-source pone delle sfide peculiari sconosciute all'ambiente di sviluppo tradizionale; prima di affrontare dunque gli strumenti di design e organizzazione del lavoro che sono nati per risolvere queste problematiche diamone una breve panoramica. - -### Difficile integrazione del software - -Quella dell'integrazione del software è in realtà una vecchia sfida che viene enormemente amplificata nell'ambito FOSS. Per integrare le nuove feature sviluppate in un software stabile diversi modelli avevano costruito le proprie pratiche: - -- Nel modello a cascata l'integrazione era una fase circoscritta e a sé stante. -- A tale struttura molto rigida si contrappone lo schema innovativo _Stabilize & Synchronize_ nato in ambiente Microsoft: durante il giorno gli sviluppatori lavorano sul proprio pezzo di codice in cui sono responsabili, e di notte il software viene ricompilato da zero. La mattina dopo, si avevano dunque due possibilità: - - la compilazione falliva, il responsabile veniva trovato e _"punito"_; - - la compilazione aveva successo, il software integrato è quindi nella _"versione migliore possibile"_. -- In XP l'integrazione veniva eseguita più volte al giorno in modo esclusivo: un solo sviluppatore alla volta poteva integrare il proprio lavoro sull'unica macchina di integrazione disponibile; questo permetteva di individuare facilmente eventuali problemi di integrazione e risolverli con rapidità. - -Ma come organizzare l'integrazione nel mondo open-source? Per sua natura, in questo ambito l'integrazione viene eseguita continuamente e senza coordinazione a priori: è anarchia totale, con lo svantaggio che da un giorno all'altro una enorme parte della codebase potrebbe cambiare in quanto un singolo sviluppatore potrebbe integrare mesi e mesi di lavoro in un'unica botta. Vedremo più avanti che strumenti si sono costruiti per contenere tale problematica. - -### Sfaldamento del team - -Nell'open source nascono inoltre problemi riguardanti la gestione del team. Occorre decidere: - -- come comunicare -- come tenersi uniti -- come coordinarsi -- come ottenere nuove collaborazioni - -Per comunicare si utilizza di solito __internet__: si potrebbe dire che senza internet non potrebbe esistere il concetto stesso di open source. In particolare si utilizzano spesso dei __forum__ per organizzare il lavoro, in modo da tenere la community unita e rispondere dubbi ai nuovi utenti. - -Per quanto riguarda il coordinamento del lavoro approfondiremo nelle prossime lezioni vari strumenti per la sincronizzazione del lavoro e di versioning per codice e documentazione (come __git__). - -Deve poi essere facile, addirittura banale, poter compilare il codice e ricreare l'ambiente di sviluppo omogeneo per tutti; si utilizzano quindi strumenti di __automatizzazione delle build__ (come i __Makefile__) in modo che chiunque voglia partecipare possa farlo indipendentemente dalla propria configurazione software e hardware. - -È infine importante _educare_ i reporter dei bug e avere un sistema per organizzare per le __segnalazioni di errori__: il sistema dovrebbe essere accessibile a tutti in modo da evitare segnalazioni duplicate e consentire una facile organizzazione delle stesse. Vedremo più avanti come anche una segnalazione d'errore avrà il suo "ciclo di vita". diff --git a/src/04_open-source/00_index.md b/src/04_open-source/00_index.md new file mode 100644 index 0000000000000000000000000000000000000000..4fe929d46e83a9506375021fe4430f7e166fea5b --- /dev/null +++ b/src/04_open-source/00_index.md @@ -0,0 +1,6 @@ +# Open source + +Apriamo ora le porte a un nuovo modo di sviluppare software che si è molto diffuso negli ultimi decenni ed è ora alla base di progetti applicativi molto importanti e famosi: il processo __open-source__. In due parole, un software open-source è un software il cui codice è liberamente consultabile online e il cui sviluppo si basa non su un singolo team ma su una community di sviluppatori indipendenti. + +- [**Letteratura**](./01_letteratura/00_index.md): analisi di quattro brani sulla disciplina +- [**Sfide**](./02_sfide.md) rispetto allo sviluppo tradizionale diff --git a/src/04_open-source/01_letteratura/00_index.md b/src/04_open-source/01_letteratura/00_index.md new file mode 100644 index 0000000000000000000000000000000000000000..3a00328ea14bc2bf330bad514febb9a6eb7bcdcd --- /dev/null +++ b/src/04_open-source/01_letteratura/00_index.md @@ -0,0 +1,8 @@ +# Letteratura + +In questa sezione verranno analizzati i seguenti testi visti a lezione. + +- [**_The Cathedral and the Bazaar_**](./01_cathedral-bazaar.md) di Eric Steven Raymond +- [**_Care and Feeding of FOSS_**](./02_care-feeding.md) di Craig James +- [**_The Emerging Economic Paradigm Of Open Source_**](./03_emerging-economic-paradigm.md) di Bruce Perens +- [**_An empirical study of open-source and closed-source software products_**](./04_empirical-study.md) di James Paulson diff --git a/src/04_open-source/01_letteratura/01_cathedral-bazaar.md b/src/04_open-source/01_letteratura/01_cathedral-bazaar.md new file mode 100644 index 0000000000000000000000000000000000000000..88835ba2f08b51ff9e5f0819baaf2613cd143d10 --- /dev/null +++ b/src/04_open-source/01_letteratura/01_cathedral-bazaar.md @@ -0,0 +1,64 @@ +# _The Cathedral and the Bazaar_ + +Raymond propone nel suo [articolo](http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/) due immagini per descrivere i due mondi contrapposti closed-source e open-source: + +- la __cattedrale__ (closed source): si tratta di un ambiente molto gerarchizzato, fortemente legato al progetto iniziale di un unico "architetto" responsabile dei lavori; +- il __bazaar__ (open source): è l'ambiente più anarchico possibile, in cui ognuno lavora per sé e costruisce espandendo ciò che gli altri hanno già fatto. + +Entrambe le costruzioni risultano splendide e attraenti, ma sono chiaramente legate a modi di pensare la costruzione e la progettazione totalmente opposti. + +## Vita e vantaggi di un progetto open-source + +Nell'articolo Raymond prosegue a descrivere come nasce un progetto open-source, esordendo con la seguente citazione: + +> Ogni buon lavoro software inizia dalla frenesia personale di un singolo sviluppatore. + +Si delinea dunque la seguente timeline di un progetto open-source: + +1. Uno sviluppatore ha un problema e intende risolverlo sviluppando un'applicazione. +2. Lo sviluppatore 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. Coloro che intendono spendere delle risorse (di fatto il proprio tempo libero) per risolvere il problema danno il via ad un progetto informale. +5. I membri del progetto lavorano sul problema finché non raggiungono dei risultati presentabili. + + Fino a qui però il progetto non è ancora definibile open-source in quanto vi lavora solo un gruppo ristretto di amici e conoscenti: il vero progetto open nasce quando __viene messo online a disposizione di tutti il codice sorgente__. Continuando, dunque: + +6. Si rende noto il lavoro online e arrivano i primi suggerimenti esterni al gruppo: questi saranno tanto più frequenti quanto più il progetto pubblicato presenterà errori in quanto la comunità, principalmente composta da altri sviluppatori, sarà motivata a risolverli. +7. Si crea interazione tra i vecchi e i nuovi membri del gruppo di sviluppo. +8. Nuove informazioni e competenze vengono acquisite e si ritorna al punto 5. + +Raymond continua esponendo alcune delle caratteristiche e dei vantaggi dei progetti open-source, primo fra tutti il fatto che: + +> Se dai a tutti il codice sorgente, ognuno di essi diventa un tuo ingegnere. + +dove con questo si intende che la possibilità di vedere e commentare il codice sorgente permette a utenti esperti di suggerire modifiche e prendere parte attiva allo sviluppo. Talvolta si tende però a pensare che un progetto di questo tipo sia destinato unicamente ad altri informatici o sviluppatori, ma ciò non è affatto vero: tante attività utili a portare avanti un progetto open-source non richiedono necessariamente competenze informatiche, come per esempio la segnalazione di bug o la moderazione di contenuti nella comunità. + +A tal proposito, è importante il seguente concetto: + +> Se ci sono abbastanza occhi [che cercano errori], gli errori diventano di poco conto. + +Non c'è molto da spiegare: più sono le persone che controllano e leggono il codice più sarà probabile trovare gli errori in esso contenuti; inoltre, gli errori rilevati possono essere risolti più facilmente grazie al supporto della community di sviluppatori, che potrebbe già conoscere una soluzione. \ +L'accento posto sulla community viene ulteriormente rimarcato dal valore che viene attribuito ai beta-tester, che in un progetto open-source è chiunque utilizzi l'applicazione in qualunque suo stadio vista la sua estrema malleabilità: + +> Se tratti i tuoi beta-tester come se fossero la tua risorsa più importante, essi risponderanno diventando la tua risorsa più importante. + +Per mantenere attiva la community di sviluppatori è però necessario un costante monitoraggio e cura; per permettere al progetto open-source di sopravvivere anche quando l'interesse dei creatori originali si è spento è fondamentale passarne il controllo a qualcuno di fidato e competente, come ci ricorda Raymond nell'ultima citazione che riportiamo: + +> Quando hai perso interesse in un programma, l'ultimo tuo dovere è passarlo a un successore competente. + +Spesso questo passaggio di testimone non viene fatto e il progetto muore: occorre invece trovare qualcuno di interessato allo sviluppo, anche perché un programma in uso dovrà necessariamente cambiare ed evolvere in futuro. + +## Confronto tra modelli + +Per capire meglio i concetti fondanti del mondo open-source mostriamo in un modo sintetico un confronto tra lo stesso e i metodi di sviluppo tradizionale e agile nel riguardo di svariati concetti: + +| Cosa | Tradizionale | Agile | Open source | +|------|--------------|-------|-------------| +| __Documentazione__ | La documentazione è enfatizzata come strumento di controllo qualità e gestione. | La documentazione è de-enfatizzata. | Tutti i manufatti di sviluppo sono disponibili a chiunque, compresi il codice e la documentazione. | +| __Requisiti__ | Gli analisti traducono le necessità dell'utente in specifiche software. | Gli utenti fanno parte del team. | Gli sviluppatori spesso sono anche gli utenti. | +| __Assegnamento dello staff__ | Gli sviluppatori sono assegnati ad un unico progetto. | Gli sviluppatori sono assegnati ad un unico progetto. | Gli sviluppatori tipicamente lavorano su più progetti con diversi livelli di partecipazione (_impossibile pianificare lo sviluppo_). | +| __Revisione del codice paritaria__ | La revisione del codice tra pari è ampiamente accettata ma raramente effettuata. | La _pair programming_ introduce una forma di revisione del codice tra pari. | La revisione del codice è una necessità ed è praticata quasi universalmente. | +| __Tempi di rilascio__ | Tante feature in poche release massicce. | Tante piccole release incrementali. | Gerarchia dei tipi di release: _nightly_ (compilazione giornaliera dal branch master), _development_ e _stable_. | +| __Organizzazione__ | I team sono gestiti dall'alto. | I team sono auto-organizzati. | I contributori individuali decidono per sé come organizzare la propria partecipazione. | +| __Testing__ | Il testing è gestito dallo staff di _Quality Assurance_ (QA), che segue le attività di sviluppo. | Il testing è parte integrante dello sviluppo (TDD). | Il testing e la QA possono essere svolti da tutti gli sviluppatori. | +| __Distribuzione del lavoro__ | Parti differenti della codebase sono assegnate a persone differenti. | Chiunque può modificare qualsiasi parte della codebase. | Chiunque può modificare qualsiasi parte della codebase, ma solo i _committer_ possono rendere ufficiali le modifiche. | \ No newline at end of file diff --git a/src/04_open-source/01_letteratura/02_care-feeding.md b/src/04_open-source/01_letteratura/02_care-feeding.md new file mode 100644 index 0000000000000000000000000000000000000000..e2dfd1013ff77ff101f339b175711d78ac26f611 --- /dev/null +++ b/src/04_open-source/01_letteratura/02_care-feeding.md @@ -0,0 +1,13 @@ +## _Care and Feeding of FOSS_ + +Ma come si inserisce il modello di sviluppo open-source in un panorama tecnologico sempre più accentrato nelle mani di poche e potenti aziende? Il timore è infatti quello che rendendo il codice disponibile a tutti si potrebbe essere subito vittima di plagio da parte di giganti del settore in grado di realizzare in poco tempo ciò che prenderebbe a un team open-source svariati mesi, accaparrandosi così una larga fetta di mercato. Craig James smentisce tuttavia tale visione nel suo [articolo](https://web.archive.org/web/20081015010505/http://www.moonviewscientific.com/essays/software_lifecycle.htm), in cui descrive il ciclo di vita di un software FOSS (Free and Open Source Software) come la sequenza delle seguenti fasi: + +1. __Invenzione__: qualcuno ha un'idea e la implementa facendola funzionare. +Dal momento in cui l'idea viene resa pubblica si assiste una grossa esplosione di progetti in tal senso finanziati da varie aziende che cercano di diventare leader nel nuovo mercato. +2. __Espansione e innovazione__: il mondo si accorge dell'invenzione e la tecnologia inizia a espandersi in quanto le aziende si 'rincorrono' a vicenda cercando di aggiungere più funzionalità possibili. Questa fase non rappresenta un buon momento per far nascere un progetto open source: un piccolo gruppo non riuscirebbe a prevalere sulle grandi aziende; poiché inoltre le specifiche non sono ancora ben definite si rischierebbe di implementare funzioni inutili. +3. __Consolidamento__: i prodotti di alcune aziende iniziano a dominare il mercato, mentre i competitor vengono assorbiti, falliscono o diventano di nicchia. Diminuisce complessivamente il numero di player e l'innovazione rallenta. +4. __Maturità__: il problema e le specifiche sono ora ben chiare e consolidate. Per un prodotto commerciale è ormai difficile entrare nel mercato, ma per uno open source è paradossalmente il momento migliore: il piccolo team ha uno slancio innovativo che le grosse aziende non hanno più e il loro prodotto può brillare dei vantaggi del mondo open-source, tra cui sicurezza e flessibilità. +5. __FOSS Domination__: lentamente, il prodotto open-source inizia a erodere il vantaggio tecnologico dei competitor commerciali, che d'altra parte non hanno alcun interesse ad innovare ulteriormente: ciascuna loro innovazione potrebbe infatti essere facilmente copiata ed essi sono inoltre già largamente rientrati del loro investimento iniziale. Il prodotto open-source inizia ad accaparrarsi fette di mercato. +6. __The FOSS era__: alla fine il progetto open-source domina completamente il nuovo mercato, mentre le grandi aziende devono ripiegare sulla vendita di servizi più che di software. + +Il vantaggio di un progetto open-source non è dunque tanto la rapidità di espansione o l'abilità di intercettare il mercato, quanto il fatto che esso permetta una continua innovazione che _segue_ le necessità del mercato, cosa che le grandi aziende faticano a conseguire in quanto ancora legate a un paradigma di investimento in cui una volta fatto il lavoro e guadagnato un tot è più costoso fare manutenzione del software piuttosto che lasciarlo morire. \ No newline at end of file diff --git a/src/04_open-source/01_letteratura/03_emerging-economic-paradigm.md b/src/04_open-source/01_letteratura/03_emerging-economic-paradigm.md new file mode 100644 index 0000000000000000000000000000000000000000..cc85d7b33040071cbe93626184706d062cd0670a --- /dev/null +++ b/src/04_open-source/01_letteratura/03_emerging-economic-paradigm.md @@ -0,0 +1,25 @@ +## _The Emerging Economic Paradigm Of Open Source_ + +Affrontiamo ora un fenomeno interessante: perché sempre più aziende investono in software open-source? A prima vista parrebbe un controsenso, perché da sempre i produttori di software proteggono il proprio prodotto tramite segreto aziendale: avere codice liberamente consultabile distrugge tale privatezza ed espone all'ascesa di competitor. Per rispondere a questa domanda ci serviamo di un [articolo](http://web.archive.org/web/20120724095330/http://perens.com/works/articles/Economic.html) di Bruce Perens sull'argomento. + +Perens fa in primo luogo notare che spesso per diverse aziende il software da sviluppare non è il prodotto, ma una __tecnologia abilitante essenziale__: per esempio, Amazon sviluppa molto software per il sito di e-commerce ma il suo prodotto non è il sito. In tali ambiti la scrittura di codice è un _costo_, non il prodotto su cui guadagnare. + +Dal punto di vista economico è poi importante stabilire se la tecnologia dà un vantaggio competitivo, ovvero se essa è __differenziante__ o __non differenziate__. Per fare ciò è sufficiente rispondere alle seguenti domande: + +- __Il cliente si accorge degli effetti del software?__ Per esempio, le persone si accorgono dell'esistenza del sistema di raccomandazione dei libri di Amazon? +- __I competitor non hanno accesso allo stesso software?__ Se Amazon usasse il sistema di raccomandazione venduto anche a Feltrinelli allora non avrebbe senso mantenerlo privato. + +Se la risposta a una delle due domande è no, avere un software proprietario non apporta alcun vantaggio: un modello di sviluppo open-source sparpaglia invece i costi e genera valore, motivo per cui sempre più aziende lo scelgono. + +Perens conclude il suo articolo riportando una matrice in cui confronta 4 diversi modelli di sviluppo, ognuno con le sue caratteristiche che ne determinano l'applicabilità in diverse situazioni: + +- __Retail__: il software è sviluppato per poter essere venduto a chiunque lo desideri; +- __In-House & Contract__: il software è sviluppato per un singolo committente; +- __Consortium & Non-Open-Source Collaboration__: un modello secondo cui diverse aziende concorrenti si mettono insieme per sviluppare un software comune (molto poco diffuso); +- __Open Source__: il software è disponibile gratuitamente e il suo codice è pubblico. + +Tali modelli vengono valutati in base all'efficienza (_quanti soldi vanno agli sviluppatori_), al tasso di fallimento del progetto, ai costi di distribuzione, al rischio di plagio, al fatto di proteggere o meno la differenziazione a livello commerciale del cliente e/o del venditore e alla dimensione richiesta del mercato perché il progetto sia un successo. + + + +Come si può notare dalla tabella, non tutti i paradigmi proteggono il vantaggio competitivo, con differenze dal punto di vista del cliente e del produttore: è dunque importante scegliere il modello di sviluppo che più si confà alle proprie esigenze. diff --git a/src/04_open-source/01_letteratura/04_empirical-study.md b/src/04_open-source/01_letteratura/04_empirical-study.md new file mode 100644 index 0000000000000000000000000000000000000000..50c734c80c134b3de365e84fe5b9dd008e5d117c --- /dev/null +++ b/src/04_open-source/01_letteratura/04_empirical-study.md @@ -0,0 +1,7 @@ +## _An empirical study of open-source and closed-source software products_ + +Concludiamo il discorso sul mondo open-source riportando uno [studio](https://www.researchgate.net/publication/3188403_An_empirical_study_of_open-source_and_closed-source_software_products) portato avanti da J.W. Paulson e altri con lo scopo di verificare alcune affermazioni ritenute vere nei riguardi del software open-source. + + + +Per ognuna di tali affermazioni l'articolo definisce una metrica e la calcola nei riguardi di progetti open-source e closed-source, concludendo così che solo alcune delle dicerie sull'open-source risultano vere mentre molte altre (es. _è più sicuro_, _è più veloce_) si rivelano essere al più circostanziali. diff --git a/src/04_open-source/02_sfide.md b/src/04_open-source/02_sfide.md new file mode 100644 index 0000000000000000000000000000000000000000..529040f8424a59c854bdd51e2c8f045ee0689373 --- /dev/null +++ b/src/04_open-source/02_sfide.md @@ -0,0 +1,32 @@ +# Le sfide del modello open source + +Per sua natura il sistema di sviluppo open source pone delle sfide peculiari sconosciute all'ambiente di sviluppo tradizionale; prima di affrontare dunque gli strumenti di design e organizzazione del lavoro che sono nati per risolvere queste problematiche diamone una breve panoramica. + +## Difficile integrazione del software + +Quella dell'integrazione del software è in realtà una vecchia sfida che viene enormemente amplificata nell'ambito FOSS. Per integrare le nuove feature sviluppate in un software stabile diversi modelli avevano costruito le proprie pratiche: + +- Nel modello a cascata l'integrazione era una fase circoscritta e a sé stante. +- A tale struttura molto rigida si contrappone lo schema innovativo _Stabilize & Synchronize_ nato in ambiente Microsoft: durante il giorno gli sviluppatori lavorano sul proprio pezzo di codice in cui sono responsabili, e di notte il software viene ricompilato da zero. La mattina dopo, si avevano dunque due possibilità: + - la compilazione falliva, il responsabile veniva trovato e _"punito"_; + - la compilazione aveva successo, il software integrato è quindi nella _"versione migliore possibile"_. +- In XP l'integrazione veniva eseguita più volte al giorno in modo esclusivo: un solo sviluppatore alla volta poteva integrare il proprio lavoro sull'unica macchina di integrazione disponibile; questo permetteva di individuare facilmente eventuali problemi di integrazione e risolverli con rapidità. + +Ma come organizzare l'integrazione nel mondo open-source? Per sua natura, in questo ambito l'integrazione viene eseguita continuamente e senza coordinazione a priori: è anarchia totale, con lo svantaggio che da un giorno all'altro una enorme parte della codebase potrebbe cambiare in quanto un singolo sviluppatore potrebbe integrare mesi e mesi di lavoro in un'unica botta. Vedremo più avanti che strumenti si sono costruiti per contenere tale problematica. + +## Sfaldamento del team + +Nell'open source nascono inoltre problemi riguardanti la gestione del team. Occorre decidere: + +- come comunicare +- come tenersi uniti +- come coordinarsi +- come ottenere nuove collaborazioni + +Per comunicare si utilizza di solito __internet__: si potrebbe dire che senza internet non potrebbe esistere il concetto stesso di open source. In particolare si utilizzano spesso dei __forum__ per organizzare il lavoro, in modo da tenere la community unita e rispondere dubbi ai nuovi utenti. + +Per quanto riguarda il coordinamento del lavoro approfondiremo nelle prossime lezioni vari strumenti per la sincronizzazione del lavoro e di versioning per codice e documentazione (come __git__). + +Deve poi essere facile, addirittura banale, poter compilare il codice e ricreare l'ambiente di sviluppo omogeneo per tutti; si utilizzano quindi strumenti di __automatizzazione delle build__ (come i __Makefile__) in modo che chiunque voglia partecipare possa farlo indipendentemente dalla propria configurazione software e hardware. + +È infine importante _educare_ i reporter dei bug e avere un sistema per organizzare per le __segnalazioni di errori__: il sistema dovrebbe essere accessibile a tutti in modo da evitare segnalazioni duplicate e consentire una facile organizzazione delle stesse. Vedremo più avanti come anche una segnalazione d'errore avrà il suo "ciclo di vita". diff --git a/src/SUMMARY.md b/src/SUMMARY.md index cacd7c20714b3bea48079d39aa7fb07d7584fb35..6be3b87231d894e49e1c0cb00ac0f2906cb1e1b5 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -35,6 +35,14 @@ - [Documentazione](./03_extreme-programming/05_documentazione.md) - [Criticità](./03_extreme-programming/06_criticita.md) +- [Open source](./04_open-source/00_index.md) + - [Letteratura](./04_open-source/01_letteratura/00_index.md) + - [The Cathedral and the Bazaar](./04_open-source/01_letteratura/01_cathedral-bazaar.md) + - [Care and Feeding of FOSS](./04_open-source/01_letteratura/02_care-feeding.md) + - [The Emerging Economic Paradigm Of Open Source](./04_open-source/01_letteratura/03_emerging-economic-paradigm.md) + - [An empirical study of open-source and closed-source software products](./04_open-source/01_letteratura/04_empirical-study.md) + - [Sfide](./04_open-source/02_sfide.md) + # 2. Progettazione e implementazione # 3. Verifica e convalida