<- Introduzione alla programmazione di un chess engine - Copertina - Indice ->

Agorà

Una seconda occhiata a The Cathedral and the Bazaar

L'articolo...

Questo articolo è un'analisi delle debolezze dell'opera di Eric Raymond (ESR) The Cathedral and the Bazaar (CatB) ed una dimostrazione delle intrinseche contraddizioni della metafora del Bazaar. In un certo senso è anche una reazione alla pubblicazione del nuovo libro di Raymond The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary (O'Reilly&Associates, 1999). In questo articolo fornirò una visione più obiettiva dello stato del mondo dell'Open source. Essendo l'articolo datato, è possibile che molti link risultino essere non validi.

Contenuti

Introduzione
Alcune debolezze del The Cathedral and the Bazaar
La competizione nelle comunità di sviluppo basate su Internet
Conclusione

Introduzione

"I fatti sono cose pertinaci; quali che siano i nostri desideri, le nostre inclinazioni o le imposizioni delle nostre passioni, questi non possono modificare la realtà."
- John Quincy Adams

L'open source è un fenomeno importante ed interessante. Mi intriga perché credo che possa giocare un ruolo positivo nei Paesi in via di sviluppo. Per assicurare la sua esistenza nel lungo periodo dobbiamo vederlo per ciò che è ed identificarne chiaramente i possibili trabocchetti così come i suoi punti di forza e di debolezza. Fondamentalmente abbiamo bisogno di una chiara visione del mondo dell'open source.

La pubblicazione del nuovo libro di Eric Raymond (ESR), The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary (O'Reilly & Associates, 1999), rende ancor più necessaria una nuova revisione critica del suo lavoro più importante. Oltre a The Cathedral and the Bazaar in questo libro sono inclusi molti altri scritti di ESR ma nessuno di questi è scritto altrettanto bene o ha avuto la stessa importanza od influenza. Non stupisce, quindi, che CatB sia talvolta considerato come un Manifesto del Movimento Open Source. In questo articolo analizzerò proprio CatB.

Nel mio precedente articolo sostenevo che la metafora del bazaar fosse intrinsecamente contraddittoria. In questo articolo voglio concentrarmi sull'opera CatB completa e tentare un'analisi delle idee principali.

In precedenza avevo evidenziato come in CatB il movimento open source sia descritto come un fenomeno senza precedenti. Per me è solamente un'altra forma di comunità scientifica. Analogamente, lo sviluppo di Linux per me non è un modello nuovo e rivoluzionario ma solamente una logica continuazione del progetto GNU della Free Software Foundation (FSF). Questo progetto ha forti legami con il MIT. Io sono convinto che questo legame accademico sia stato cruciale per il successo del progetto GNU così come il legame con l'Università di Helsinki è stato immensamente utile nelle prime e più difficili fasi dello sviluppo di Linux.

Questo articolo è diviso in due parti: nella prima analizzo le idee chiave di CatB; nella seconda parte esaminerò le incongruenze dei fenomeni competitivi presentati nell'opera e cercherò di fornire una visione più oggettiva della competizione nell'ambiente OSS.

Alcune debolezze di The Cathedral and the Bazaar

"Se la libertà ha un qualche significato, questo consiste nel diritto di dire alle persone ciò che non vogliono sentire."
- George Orwell

In questa parte dell'articolo voglio concentrarmi sulle idee espresse in CatB. Queste idee sono diventate acriticamente parte della tradizione open source e sono citate spesso in articoli ed interviste. Molti autori basano le loro teorie sull'implicita correttezza di queste. Alcune delle idee più importanti di CatB sono:

la Legge di Brooks non si applica ai progetti di sviluppo basato sulla rete;
dato un numero sufficiente di occhi, tutti gli errori vengono a galla;
lo sviluppo di Linux si basa sul modello del bazaar;
il modello di sviluppo open source porta automaticamente ai risultati migliori;
lo sviluppo a bazaar è un sistema di sviluppo software nuovo e rivoluzionario.

Cercherò di dimostrare che queste idee hanno basi molto fragili. Iniziamo con le osservazioni sulla Legge di Brooks dal momento che costituivano una delle affermazioni più importanti di CatB.

La Legge di Brooks non si applica ai progetti di sviluppo basato sulla rete.

"La bugia più comune è quella in cui si mente a se stessi; è mentire agli altri che è un po' un'eccezione."
- Friedrich Nietzsche

Una delle idee più difficilmente difendibili di CatB è che la Legge di Brooks non sia applicabile agli ambienti di sviluppo distribuito basati su Internet com'è ad esempio il caso di Linux. Da CatB (il carattere italico è mio, un eventuale italico originale è indicato come grassetto italico):

"In The Mythical Man-Month, Fred Brooks osservava che il tempo-programmatore non è facilmente gestibile: aggiungere sviluppatori ad un progetto già in ritardo lo rallenterà di più. Sosteneva che la complessità ed i costi della comunicazione all'interno di un progetto aumentano con il quadrato del numero degli sviluppatori coinvolti mentre il lavoro svolto aumenta solamente in modo lineare. Questa affermazione è conosciuta come "Legge di Brooks" ed è riconosciuta generalmente vera. Ma se la Legge di Brooks fosse l'unica variabile in gioco, Linux non esisterebbe ."

Questa convinzione che il tempo-programmatore scali in maniera differente nel momento in cui i programmatori sono connessi ad Internet e lavorano ad un progetto open source è ripetuta in forma diversa in altre parti:

"Probabilmente, alla fine, la cultura open source trionferà non perché la cooperazione sia moralmente giusta o perché la "proprietarizzazione" del software sia moralmente sbagliata (sempre che tu creda a ciò, cosa che né Linus, né io crediamo) ma semplicemente perché il software a sorgente chiuso non può vincere una corsa agli armamenti con le comunità open-source che possono investire in un progetto un numero di ore-programmatore di diversi ordini di grandezza maggiore."

Per prima cosa voglio sottolineare che il famoso The Mythical Man-Month è diventato un classico nel campo dell'ingegneria del software. Quest'opera è decisamente più importante di CatB; le critiche di ESR non ne intaccano assolutamente il valore. Molti altri concetti, frasi, persino titoli di capitoli del libro di Brooks sono entrati a far parte del vocabolario comune dell'ingegneria del software. Posso citare la "sindrome del secondo sistema", "dieci libbre in un sacchetto da cinque", "piano di cestinazione" e "Come fa un progetto ad essere in ritardo di un anno...? Un giorno alla volta". Nei primi anni '60, mentre lavorava come coordinatore di progetto del Sistema Operativo/360 (OS/360), Frederick Brooks osservò la diminuzione del rendimento con l'aumentare del numero dei programmatori e che il mitico mese-uomo non era nient'altro che un mito. Il concetto è valido nel 1999 come lo era nel 1975, quando fu pubblicato il libro.

Il vero problema che sorge dalle affermazioni di CatB è che, a causa della popolarità di quest'opera, queste affermazioni potrebbero scoraggiare la comunità OSS dal leggere e studiare The Mythical Man-Month , uno dei pochi testi d'informatica ancora attuali anche decenni dopo la prima pubblicazione. Di fatto, la "Legge di Brooks" è solitamente enunciata come "Aggiungere forza lavoro ad un progetto già in ritardo lo farà ritardare ancora di più". L'espressione "mitico mese-uomo" (o "concetto del mitico mese-uomo") è normalmente utilizzata per identificare il concetto della diminuzione della produttività di un insieme di sviluppatori anche se lavorano tutti allo stesso progetto sin dall'inizio. Una delle migliori spiegazioni di questo concetto è stata data da Ray Duncan nella sua recensione per la rivista Dr. Dobbs di The Mythical Man-Month:

"Che cosa è il mitico mese-uomo, dopotutto? Considerate un'applicazione abbastanza complessa dell'inizio dell'era dei personal computer, come le prime versioni di Lotus 1-2-3, Ashton-Tate dBASE o Wordstar. Supponiamo che per progettare, scrivere il codice, effettuare il debugging e produrre la documentazione di un'applicazione del genere sia necessario il lavoro di un anno di un programmatore capace, esperto e molto ben motivato. In altre parole, 12 mesi-uomo. Immaginate che per esigenze di mercato sia necessario finire il programma entro un mese invece che entro un anno. Qual è la soluzione? Voi potreste dire: "Prendi 12 sviluppatori esperti, dividi il progetto fra di essi, lasciali lavorare per un mese ed il problema è risolto. In fondo sono sempre 12 mesi-uomo, giusto?"

Purtroppo il tempo non può essere manipolato così facilmente. Il Dr. Brooks osservò che i mesi-uomo non sono, per così dire, fattorizzabili, non sottostanno alla regole associative o commutative. 1 programmatore x 12 mesi non equivale a 12 programmatori x 1 mese. Le prestazioni dei gruppi di sviluppo, in altre parole, non "scalano" in modo lineare più di quanto "scalino" le prestazioni di un computer con più processori. Egli ha scoperto, infatti, che quando si aggiungono sviluppatori ad un progetto in ritardo il risultato più probabile è quello di rendere il ritardo ancora più grave. La soluzione per riportare il progetto in linea con i tempi previsti non è sta nell'incrementare il numero di api operaie bensì nell'eliminare le caratteristiche promesse ma non ancora completate.

Quando vi fermate a pensarci è un fenomeno abbastanza facile da capire. Fare lavorare più programmatori in parallelo comporta costi non evitabili: i membri del gruppo devono "sprecare tempo" partecipando a riunioni, correggendo i piani di sviluppo, scambiandosi posta elettronica, concordando le interfacce, consolidando le verifiche delle prestazioni e così via. In qualsiasi gruppo composto da più di qualche individuo almeno un membro sarà preposto alla "supervisione" degli altri mentre un altro sarà responsabile delle funzioni di routine come la gestione delle compilazioni, l'aggiornamento dei diagrammi di Gantt e del calendario comune. Alla Microsoft c'è almeno un membro in ogni gruppo che ha solo il compito di disegnare le magliette indossate da tutto il team. Mano a mano che il gruppo cresce, quindi, si viene a creare una esplosione di combinazioni tale che la percentuale dello sforzo dedicato alla comunicazione ed all'amministrazione del progetto aumenta sempre."

Molti dei migliori professionisti del software somigliano più a degli artisti, a dispetto della natura tecnica della loro specializzazione. Non è una coincidenza, infatti, che un altro classico della programmazione si intitoli The Art of Computer Programming. Come qualsiasi responsabile di progetti di una certa entità può testimoniare, problemi di comunicazione, personalismi e problemi politici finiscono per insinuarsi in qualsiasi progetto. Tutti questi problemi diminuiscono la produttività.

E' semplicemente ingenuo pensare che per lo stesso gruppo di sviluppatori il tenersi in contatto tramite Internet possa incrementare le prestazioni rispetto a farlo su una LAN o a lavorare su uno stesso server. Inoltre, se consideriamo di coinvolgere programmatori dello stesso livello, i gruppi geograficamente compatti sarnno sempre avvantaggiati rispetto ai gruppi che si tengono in contatto tramite Internet. I progetti open source usano Internet per mantenere i contatti tra un insieme di talenti geograficamente distribuiti. Ciò aumenta potenzialmente la qualità di questi talenti in assenza di barriere geografiche. La riduzione degli effetti della distanza non elimina gli altri limiti entro i quali questi progetti si sviluppano ma può incrementare notevolmente la qualità del gruppo di programmatori. Questo è l'unico vantaggio che riesco a vedere.

Io sono convinto che che l'illusione che il postulato del "mitico mese-uomo" e la legge di Brooks non possano essere applicati vada ristretta a quei progetti per i quali esiste già un prototipo funzionante e per i quali tutti o almeno la maggior parte dei problemi di architettura siano stati risolti. Questo può essere stato il caso di Linux, che è essenzialmente un'implementazione open source di Unix. Con alcune riserve la stessa cosa probabilmente vale per tutti i sistemi per i quali sia le specifiche (POSIX, nel caso di Linux) che le implementazioni di riferimento (come FreeBSD e Solaris) esistono già e sono disponibili a tutti gli sviluppatori, come è stato evidenziato nel documento Halloween-I:

"La via più semplice per ottenere un comportamento organizzato da una folla estesa e semi organizzata è quella di richiamarla ad un obiettivo conosciuto. Averne uno dà concretezza ad una visione confusa. In queste situazioni, avere un fine da perseguire è una via per ottenere una forte leadership centralizzata. Ovviamente una volta che questo principio organizzativo implicito non fosse più disponibile (quando il progetto avesse raggiunto la maturità) lo sforzo organizzativo richiesto per raggiungere nuove frontiere può essere ingente. Questo è probabilmente il più impegnativo ostacolo che dovrà affrontare la comunità Linux adesso che sotto tutti i punti di vista è stata raggiunta la parità con UNIX."

"Dato un numero sufficiente di occhi, tutti gli errori vengono a galla"

"Solamente due cose sono infinite, l'universo e la stupidità umana, e non sono sicuro della prima."
- Albert Einstein

Una delle idee principali diffuse da CatB è il motto attribuito a Linus Torvalds: "Dato un numero sufficiente di occhi, tutti gli errori vengono a galla":

"Nell'ottica dal bazaar, d'altra parte, si presuppone che i bachi siano un fenomeno che tende ad emergere, od almeno che questo succeda abbastanza velocemente quando hai a disposizione un migliaio di sviluppatori attenti e concentrati su ogni singolo rilascio. Di conseguenza si effettuano rilasci frequenti per ottenere molte correzioni successive e come benefico effetto secondario si ha meno da perdere se occasionalmente qualche cosa sfugge al controllo."

La ricerca degli errori di programmazione in un sistema complesso è molto più difficile da intraprendere rispetto al semplice controllo del codice da parte di un certo numero di sviluppatori attenti. Per i progetti più complessi, per ogni due o tre errori trovati e corretti è probabile l'introduzione di un altro errore. Le distribuzioni Linux possono essere un buon esempio di ciò in quanto, tenendo conto del numero di errori e di correzioni che subiscono prima di diventare obsolete, la maggior parte delle versioni "di produzione" potrebbero essere nuovamente classificate come versioni beta.

In CatB si presuppone che un certo numero di sviluppatori di talento possano lavorare in parallelo sullo stesso pezzo di codice senza alcun coordinamento che non sia la posta elettronica e che uno di essi alla fine correggerà il codice più velocemente che in un'azienda dotata di specialisti impiegati esclusivamente in questo compito. In effetti se un numero sufficiente di programmatori cercherà lo stesso bug, prima o poi questo verrà molto probabilmente corretto ma sorgono parecchi dubbi riguardo a questa idea di debugging parallelo:

Questo è il modo migliore di utilizzare dei bravi sviluppatori?
Perché sprecare il loro talento alla ricerca di errori di programmazione? In alcune società c'è del personale specializzato che assolve a questo compito. Una collaborazione fra sviluppatori volontari e commerciali e beta-tester potrebbe essere di grande beneficio. I programmatori in gamba, a meno che non sia assolutamente necessario, non amano effettuare la correzione del codice non prodotto da loro, preferiscono produrne di proprio. Inoltre, se utilizziamo una decina di bravi programmatori solamente per cercare e correggere un errore di programmazione abbiamo un enorme spreco di risorse. Una migliore gestione del progetto potrebbe avere maggiori benefici rispetto a sprecare il tempo di dieci programmatori per scovare un bug. Programmatori in gamba che comprendano completamente un determinato sistema sono molto pochi e questo approccio sarebbe un vero spreco.
Tutti i bachi sono uguali?
No, ci sono almeno tre tipi diversi di bachi: errori nel codice, errori logici ed errori di architettura. Una sotto-classe molto estesa sono i semplici errori di programmazione (per esempio if (i = 1) {...} in C) che non sono così difficili da trovare. Il secondo tipo sono errori logici che sono circa un ordine di grandezza più difficili da scoprire e correggere. I buchi più complessi sono conseguenza di scelte architetturali sbagliate (es. collegati alla sicurezza di Unix) o di limitazioni degli strumenti utilizzati (in C i problemi legati alla memoria od ai buffer-overflow). Molti difetti architetturali di Linux sono universalmente riconosciuti e sono corretti poco per volta. Dal punto di vista dell'ingegneria del software essi sono simili ai problemi di architettura presenti in ogni prototipo che venga convertito in un sistema di produzione; inizialmente Linux era stato immaginato come un sistema operativo di passaggio che avrebbe finito per essere rimpiazzato da Hurd. Di conseguenza L'eliminazione di tutti i bug presenti in Linux è legata alla possibilità di renderlo un'architettura superiore a tutte le possibili alternative. Il problema della stagnazione, della perdita di tempo e risorse per eliminare bachi piuttosto che risolvere i problemi di architettura sottostanti è comune nei progetti open-source. Le caratteristiche del mondo open-source fanno sì che si dia una maggiore priorità a questi sforzi "titanici" di correzione dei bachi piuttosto che al miglioramento della progettazione.
E' semplice forzare programmatori di talento a cercare lo stesso baco?
Dipende, normalmente obbligare dei bravi programmatori a controllare la stessa porzione di codice è molto difficile. Non è un lavoro semplice né gratificante a meno che l'errore non sia realmente critico (dal punto di vista tecnico o politico). Gli sviluppatori di talento si occupano principalmente di programmazione, non di effettuare i test; normalmente preferiscono creare i propri bachi piuttosto che correggere quelli altrui. Ogni situazione nella quale diversi programmatori di talento lavorano sulla stessa parte di codice è un'eccezione più che una regola. Con il crescere della complessità di un dato progetto questa concentrazione di talenti si verifica sempre più raramente e solamente per i bachi che sono più importanti dal punto di vista tecnico o politico. Per un qualsiasi progetto sufficientemente complesso non ci saranno mai abbastanza occhi per scovare e sradicare tutti i bachi.
Ha senso correggere gli errori in quell'ammasso confuso di codice?
Normalmente no. Se il codice è molto confuso (e, come Ken Thompson ha fatto notare, alcune parti di Linux lo sono) nuovi errori possono essere facilmente introdotti cercando di correggere quelli vecchi. Scrivere nuovamente da zero, in questo caso, può essere una soluzione. Il modello open-source, con la sua iper fiducia nella correzione dei bachi, può essere uno svantaggio. Nel mondo commerciale un bravo dirigente può parzialmente evitare questo problema esercitando la propria autorità. Nei progetti open source, moduli incorporati nelle prime fasi del progetto, possono diventare velocemente poco utili ma a causa dell'inerzia e dell'eccessivo lavoro che grava sugli sviluppatori chiave, può non essere possibile riscrivere questi moduli sino a quando non ci siano seri problemi che giustifichino lo sforzo. A volte solamente quando un problema diventa palese è possibile coinvolgere uno sviluppatore di un certo livello nella riscrittura del codice -- un lavoro poco gratificante, come ogni programmatore vi può confermare. In questo caso la pubblicità creatasi intorno al baco rende vantaggioso lo sforzo necessario alla sua correzione (è il caso di molti bachi legati alla sicurezza).

L'apparentemente infinito numero di bachi (strettamente legato agli errori di progettazione) preclude il beneficio della loro correzione al progetto nella sua totalità. Per Linux non vedo nessuna miglioria degna di nota rispetto a Solaris o FreeBSD. In questa intervista per la rivista Computer della IEEE Computer Society Ken Thompson dice:

"Computer: In un certo senso Linux sta seguendo questa tradizione, nessun commento a riguardo?

Thompson: Vedo Linux come una cosa che non è Microsoft -- una contrapposizione verso Microsoft, né più né meno. Non credo che potrà uscirne vittorioso sulla lunga distanza. Ho dato un'occhiata al codice sorgente e alcune parti sono buone, altre meno. Le più disparate persone hanno contribuito a quel codice e la qualità varia drasticamente.

La mia esperienza e quella di alcuni miei amici mi porta a dire che Linux è abbastanza inaffidabile. Microsoft è veramente inaffidabile ma Linux è peggio. Per un ambiente di produzione, semplicemente non è pronto. Se lo utilizzi su una singola macchina è una cosa, ma se vuoi usarlo su firewall, gateway, sistemi embedded e così via, c'è ancora molta strada da fare."

Nella sua risposta al commento di ESR alla sua intervista, Ken Thompson scrive:

"Credo che sia ingenuo pensare che, partendo molto indietro, con una frazione delle risorse a disposizione e basandosi su contributi volontari, Linux abbia qualche possibilità di essere un reale concorrente di Microsoft. (Credo la stessa cosa riguardo a Unix.)"

Anche un superficiale controllo dell'archivio di Bugtrack conferma che molti sviluppatori preferiscono creare i propri bachi piuttosto che correggere quelli degli altri. Per i contributi sporadici al kernel la situazione può essere anche peggiore. In un commento molto interessante sulla sua iniziale esperienza con Linux Lars Wirzenius scrive:

"Per esempio, un mio contributo al kernel conteneva un baco che richiese tre anni per essere trovato e corretto e fu fatto da qualcuno che stava facendo dello hacking su OS/2. Mi riferisco alla funzione sprintf all'interno del kernel."

Queste affermazioni suggeriscono che limitare i contributi diretti al kernel a pochi validi programmatori (il gruppo principale) sia una buona idea. Il modello del Bazaar dovrebbe essere evitato il più possibile per lo sviluppo del kernel.

Linux segue il modello del Bazaar o della Cattedrale?

"La nostra fede ci spinge a credere che ci sia una sola Chiesa Cattolica Apostolica e questo noi fermamente crediamo e professiamo. Al di fuori di essa non c'è salvezza o remissione dei peccati."
- Papa Bonifacio VIII (1294-1303) [C. d. T.]

Molti hanno obiettato che il livello di decentralizzazione del mondo Linux è aperto a modifiche. Lo scenario in bianco e nero prospettato da CatB (il modello monolitico ed autoritario della Cattedrale in contrapposizione al modello distribuito e democratico del Bazaar) è troppo semplicistico. Queste metafore dell'elevata centralizzazione (Cattedrale) e della mancanza della stessa (Bazaar) non tengono conto delle dimensioni che può raggiungere un progetto, della sua complessità, delle scadenze e delle pressioni che può subire, dell'accesso a risorse e strumenti e delle differenze che possono esserci se parliamo di funzioni fondamentali (come il kernel di Linux) o parti periferiche del sistema. Per progetti molto grandi come sono i sistemi operativi è molto importante che il cuore sia sviluppato da un piccolo gruppo di sviluppatori gestito in modo centralizzato. Le parti periferiche possono trarre benefici da un approccio più rilassato e decentralizzato. Penso che CatB fallisca nel distinguere fra questi due tipi di attività come la seguente citazione dimostra:

"In retrospettiva, un precedente dei metodi impiegati e del successo di Linux possono essere lo sviluppo della libreria Lisp di GNU/Emacs e la grande quantità di codice Lisp creato. In contrasto con il sistema della cattedrale sul quale si basavano lo sviluppo del cuore in C di Emacs e di molte altre utilità della FSF, la massa di codice Lisp ha avuto un'evoluzione molto fluida, nella quale gli utenti hanno avuto un grande peso. Le idee ed i prototipi dei metodi sono stati riscritti spesso, anche tre o quattro volte prima di raggiungere la loro forma finale. La collaborazione tramite Internet, come per Linux, era molto frequente."

Non si dovrebbero accostare queste due attività, il core C di Emacs ed il codice Lisp sono differenti e dovrebbero essere analizzati in modo diverso. Vi sono diversi vantaggi nell'usare modelli misti piuttosto che quello puramente centralizzato (Cattedrale) o quello decentralizzato (Bazaar). Non sorprende che nella realtà sia un modello misto a dominare o che nel mondo Linux ci sia ampio spazio per il modello di sviluppo altamente centralizzato. Secondo l'opinione di Linux Torvalds:

"Il mondo open source potrebbe sembrare una democrazia, ma non lo è. Al LinuxWorld Expo di mercoledì, i coordinatori di alcuni dei progetti open source più conosciuti si sono definiti dei dittatori .

L'esempio più lampante è lo stesso Linux: il suo creatore, Linus Torvalds, ha l'ultima parola su tutte le modifiche da effettuare al kernel del popolare clone open source di Unix. Poiché la comunità che sviluppa Linux è diventata così numerosa, molte modifiche proposte sono valutate da molte persone prima di raggiungere Linus, spiega lo stesso Torvalds.

Se rifiuta la modifica può volere dire che molto lavoro di diverse persone è stato inutile. Questo metodo, però, gli permette di mantenere lo sviluppo di Linux organizzato senza dovergli dedicare la totalità del suo tempo .

"Il mio lavoro è ridotto dal fatto che non devo valutare le idee più assurde", dice Torvalds. "Vedo solamente il risultato del lavoro di mesi, o addirittura di un anno, di più persone."

Nell'attuale stato di sviluppo del kernel di Linux si possono immediatamente vedere elementi estranei al modello del Bazaar, stando alle affermazioni del principale autore del kernel stesso. Sembra di essere in presenza del modello altamente centralizzato della Cattedrale. Per esempio non si può inviare le modifiche direttamente a Torvalds, devono essere spedite ai suoi collaboratori. Se una patch è rifiutata non c'è possibilità di appello, cosa che suona molto poco democratica. Jordan Hubbard scrive:

"Nonostante ciò che possono affermare alcuni sostenitori del software libero, i modelli centralizzati come quello del FreeBSD Project non sono assolutamente stati resi obsoleti od inefficaci nel mondo open source. Una più attenta analisi del successo attribuito al modello anarchico spesso rivela che c'è un significativo livello di centralizzazione in buona parte del processo di sviluppo."

Ovviamente queste affermazioni non escludono che alcune parti di Linux siano effettivamente sviluppate seguendo il modello decentralizzato (Bazaar), specialmente i driver, le utilità e le piccole applicazioni. La stessa cosa è persino più vera nel mondo DOS/Windows/WindowsNT. Sicuramente c'è molto più software shareware e freeware disponibile per DOS/Windows rispetto a Linux. DOS fu il primo sistema operativo democratico che sfruttò Internet e molto prima che Linux "fondasse" degli archivi di programmi che accettavano contributi da chiunque. Symtel e cdrom.com sono solo alcuni esempi. Jonathan Eunice scrive:

"Il problema non è che si raggiungano conclusioni sbagliate, ma che si assuma una visione libero-buono/commerciale-cattivo che non credo sia condivisa dai dirigenti dell'IT. A parte fare proselitismo, riduce lo sviluppo del software a solo due realtà. La Cattedrale rappresenta un modello top-down di sviluppo monolitico, altamente pianificato. Il Bazaar, che egli raccomanda, rappresenta uno sviluppo caotico, evoluzionistico, "mercato-centrico". Raramente queste semplificazioni rappresentano la realtà. Infine, il passaggio strategico di Netscape ed il tono anti Microsoft della comunità open source portano a pensare che Netscape esemplifichi il Bazaar, lasciando a Microsoft il ruolo conservatore di portabandiera della Cattedrale. Questa visione, però, è veramente troppo semplicistica.

[...] Il testo di Raymond sfiora ma non mette mai in piena luce la sintesi dei due contrari: "Quando iniziate un progetto collaborativo dovete essere in grado di fornire una promessa plausibile. il vostro programma non deve per forza funzionare particolarmente bene; può essere grezzo, bacato, incompleto e poco documentato. La cosa in cui non deve fallire è convincere i potenziali collaboratori che potrà evolversi in qualcosa di realmente valido in un futuro prossimo.

Che magnifica spiegazione del comportamento di Microsoft! Come Redmond ha perfettamente capito, il prodotto al suo primo rilascio non deve essere perfetto fintanto che ha la "promessa plausibile" di un futuro prodotto valido, della definizione di uno standard, o di soddisfare una necessità impellente. Questo processo funziona sino a quando le prime versioni garantiscono comunque guadagni, una base di utenti, degli introiti da investire per migliorare il prodotto e guadagnare la guida del mercato. Le unità di misura possono essere differenti fra le comunità open source e quelle commerciali ma i concetti economici alla base sono identici.

Che Microsoft, l'antitesi della comunità Linux/freeware/open-source, possa utilizzare efficacemente gli stessi principi del Bazaar ci suggerisce due conclusioni: la prima, che La Cattedrale ed il Bazaar forniscono basi troppo esigue per descrivere il processo di sviluppo ; la seconda, che vi sono delle linee guida universali che coinvolgono flessibilità, modularità ed un forte scambio di impressioni con gli utenti che tutti gli sviluppatori di software dovrebbero seriamente pensare di adottare come linee guida per i loro progetti."

Molte strategie di Microsoft hanno degli analoghi nel mondo open source, come scrive l'autore del documento Halloween-I:

"Molti che hanno letto questo documento affermano che internamente potremmo vedere Microsoft come una comunità open source idealizzata ma per varie ragioni così non è."

Secondo il libro di James Wallace e Jim Erickson, Hard Drive: Bill Gates and the Making of the Microsoft empire (New York: Harper Business, 1992) Microsoft in un primo tempo sembrava seguire uno stile simile a quello del Bazaar:

Rilascia presto, rilascia spesso.
La chiave di volta è l'iniziativa, trasformare gli utenti in beta-tester o collaboratori, attrarre sviluppatori è molto importante perché serve ad attirare utenti. Microsoft può essere considerata un pioniere nell'applicare questa massima di CatB:
"Con un minimo di incoraggiamento i vostri utenti troveranno i problemi, suggeriranno soluzioni ed aiuteranno a migliorare il codice molto più velocemente di quanto potreste fare senza il loro aiuto."
L'importanza di avere utenti
Coltiva la tua base di utenti. Evita la perfezione come la peste, considera l'imperfezione non un problema ma l'opportunità per introdurre futuri miglioramenti. Come scrive Linux Torvalds:
"...il futuro dei sistemi operativi sarà ritagliato sulle necessità degli utenti piuttosto che dalla curiosità dei programmatori ... La tecnologia non guida più il mercato, lo fanno le necessità della gente... ."
Questo è anche lo stile Microsoft; la frase di Linus potrebbe facilmente essere stata detta da un dirigente Microsoft. Quando i competitori attaccano un prodotto dal punto di vista tecnico il contrattacco può essere portato sul fronte della base di utenti. Alla fine, si possono vincere i concorrenti indipendentemente dalla qualità del prodotto vincendo la guerra grazie ad un maggior numero di utenti. Avere una grande base di sistemi installati è importante, anche più importante dei meriti tecnici di un prodotto. Se necessario, la quota di mercato può essere aumentata regalando il software, fornendo il codice sorgente, od entrambe le cose.

Microsoft, ma anche altri, hanno capito e dimostrato che in molte occasioni le quote di mercato possono essere convertite in denaro sonante. Un esempio è il passaparola degli utenti che dicono ad altri "IE è il migliore browser" o "RedHat è un'ottima distribuzione Linux". L'"approccio McDonald's", un veloce servizio di pasti standard che bene si adattano alle limitate necessità del cliente medio, può essere considerato una parte vitale della strategia di Microsoft e di altre aziende. Hanno semplicemente scoperto prima di altri che un prodotto mediocre, dalle ridotte richieste hardware e semplice da usare ha maggiori possibilità di essere accettato dal mercato rispetto a uno realmente innovativo.
Per entrare nel mercato si devono trovare ed attaccare i punti deboli
Cercate di trovare un'area non sfruttata da nessuno, un concorrente debole oppure una grande comunità di utenti insoddisfatti. Studiate i pregi e le difficoltà del concorrente e sfruttateli.
I buoni programmatori sanno cosa scrivere, gli ottimi programmatori sanno cosa riscrivere (e riutilizzare)
Non perdete troppo tempo lavorando su caratteristiche innovative od architetture migliori se potete fornire una promessa plausibile. Riciclate i componenti delle versioni esistenti. Il prodotto raggiungerà la maturità in una futura versione (per Microsoft la mitica versione 6.0). Immettete sul mercato un prodotto di media qualità in anticipo rispetto alla concorrenza, imponete il prodotto come standard in modo da sfruttare l'aiuto degli utenti per migliorare l'architettura di base. La seguente citazione di CatB può probabilmente essere utilizzata, senza modifiche, in uno qualsiasi dei seminari per sviluppatori di Microsoft:
"Considerate Linux, pensate che se durante lo sviluppo Linus Torvalds avesse cercato di introdurre migliorie fondamentali nella struttura del sistema operativo il kernel sarebbe stato così stabile ed avrebbe avuto altrettanto successo?"

Queste opinioni sono condivise da altri critici di CatB. Per esempio Jonathan Eunice scrive:

"... La realtà è che Microsoft sforna programmi con molte caratteristiche, che migliora velocemente. Anche se hanno un'eccessiva abbondanza di funzioni sono anche molto modulari. Il modello di sviluppo dell'azienda di Redmond ben rappresenta molte delle caratteristiche che Raymond identifica con il Bazaar: sviluppo veloce, architettura modulare, una base di utenti ampia ed attiva, molti agenti che lavorano contemporaneamente per migliorare il prodotto in parallelo su parecchi aspetti diversi ed un forte ritorno di informazioni da parte degli utenti."

C'è un'ulteriore forma di centralizzazione nel mondo OSS che agisce implicitamente contro il modello del Bazaar, Linux (e la maggior parte degli altri progetti OSS più importanti) adottano la licenza GNU; questa è stata probabilmente la decisione migliore che Linus Torvalds abbia mai fatto. L'inerzia iniziale per i prodotti commerciali basati su prodotti GNU garantisce un grande vantaggio al primo che immette un prodotto sul mercato, scoraggiando il fork.

Gli autori del documento Halloween-I evidenziano questo fenomeno nella parte dedicata alle licenze:

"Come per i prodotti commerciali, il migliore prodotto open source, sul lungo periodo, eliminerà i progetti concorrenti e ne acquisirà le migliori caratteristiche. Linux, per esempio, sta uccidendo gli Unix BSD e sta assorbendomolte delle loro peculiarità (e di quelle degli Unix commerciali). Questa caratteristica conferisce un grande vantaggio al progetto che parte per primo.

... Avere la parte del leone nel mercato dà un grande controllo sull'evoluzione del mercato stesso."

Il punto focale è l'evoluzione del software, non la sua rivoluzione. L'estensione della base di utenti scoraggia i cambiamenti rivoluzionari. Per chi sta in prima linea, Linux, gcc, Perl, Apache e gli altri prodotti open source sono solamente strumenti e dal punto di vista degli utenti, uno strumento standard è molto meglio di uno strumento non standard. E' molto difficile mettere in discussione la posizione di predominio di un'applicazione che implementa uno standard; ciò nonostante il successo crea condizioni che possono portare alla stagnazione. Come per qualsiasi sistema operativo POSIX compatibile le possibilità di innovazione per Linux sono limitate dalla necessitÃ di aderire allo standard POSIX. Sono portato a riconoscere parte del valore e dell'attrattiva di Linux nella misura in cui esso funge da nuovo grande SuperBIOS standard non appartenente ad alcuna azienda. In un certo senso il gioco finisce quando la stabilità del sistema diventa essenziale per lo sviluppo delle applicazioni. Alle fine vedremo un grande lavoro di pulizia nei sotto-sistemi di base per ottenere migliore schedulazione, migliore SMP, TCP/IP, file-system e così via ma non cambiamenti radicali nell'architettura o nelle API. In poche parole l'innovazione in Linux sarà per la gran parte limitata alle applicazioni. Come scrive Jamie Zawinski:

"Esistono esempi in controtendenza rispetto a questo ma in generale i grandi cambiamenti sono portati avanti da piccoli gruppi che hanno identità di obiettivi. Quante più persone sono coinvolte, tanto più lenta ed ottusa diventa la loro collaborazione."

Linux ha decisamente superato la fase del piccolo gruppo qualche tempo fa. Linux potrebbe diventare un sistema operativo innovativo se si spostasse su un segmento differente, come ad esempio il mercato dei palmari che è probabilmente la parte più dinamica del mercato dei sistemi operativi. Questo però è difficile a causa della grande base di installazioni già presenti nei personal computer e delle scelte architetturali che sono state fatte finora proprio in funzione di queste piattaforme invece che di altre.

Il modello di sviluppo open source porta automaticamente ai risultati migliori?

"La gente pensa che il solo fatto che sia open source porti automaticamente ad un risultato migliore. Non è così. Devi fare le scelte giuste per avere successo, l'open source non è la soluzione per la fame nel mondo."
- Linus Torvalds

Parliamo di qualità del software open source. Non voglio trasformare questo articolo in uno scontro sui valori della famiglia, voglio parlare di un fatto ben preciso di cui sono a conoscenza. Per diversi anni ho studiato il fenomeno dei cosiddetti filemanager ortodossi. Per quanto ho potuto vedere non ci sono differenze di qualità significative fra le migliori versioni open source (Midnight Commander e Northern Captain) e le migliori versioni commerciali (FAR e Windows Commander). Nei progetti di piccole dimensioni anche il numero di sviluppatori è meno importante di quanto suggerito in CatB. Mentre Midnight Commander era sviluppato da un gruppo di persone, Northern Captain e due versioni commerciali (shareware, per essere precisi) erano sviluppati da un singolo programmatore. Di fatto, l'autore di FAR è più l'autore di un gestore di archivi molto famoso, RAR, che compete in qualità con gzip. Per lui lo sviluppo di FAR era un lavoro part-time. Concordo, quindi, con la prima parte della seguente citazione da CatB:

Probabilmente dovrebbe essere ovvio (è proverbiale che "La necessità è la madre dell'invenzione") ma troppo spesso gli sviluppatori software sprecano giornate intere lamentandosi di dover lavorare controvoglia su programmi che a loro non servono e che non amano. Nel mondo Linux però non è così -- e questo potrebbe spiegare come mai la qualità media dei programmi prodotti dalla comunità Linux sia così alta."

Per essere onesti, anche "la qualità media dei programmi" prodotti per la comunità Windows (prodotti commerciali a basso costo, shareware e freeware) è eccezionalmente alta, a dispetto dei difetti del sistema operativo sottostante. Pensate ai giochi per Windows: certi archivi di programmi per Windows sono "un bazaar di differenti approcci e filosofie" proprio come gli archivi dei programmi per Linux.

Cosa c'è di realmente innovativo nel modello di sviluppo di Linux?

"Parigi val bene una messa."
- Enrico IV

In un articolo precedente ho considerato Linux come la logica continuazione del progetto GNU della Free Software Foundation, un progetto ha forti legami con il MIT. Io sono convinto che questi legami siano stati cruciali per il successo del progetto GNU così come il legame con l'Università di Helsinki è stato immensamente utile nelle prime e più difficili fasi dello sviluppo di Linux. Lo sviluppo di gcc e di Emacs quindi mi sono sembrati una grande ripetizione di ciò che è successo con Linux. Mentre non sono d'accordo con le affermazioni contenute in CatB che riconoscono in Linux un nuovo modello di sviluppo io ora vedo un'innovazione importante che ha già dato il via ad una nuova tendenza: per i sistemi operativi la complessità organizzativa e di sviluppo fanno sì che le conseguenze di rendere il codice aperto e disponibile siano differenti rispetto ad aprire i sorgenti di progetti di piccole o medie dimensioni.

Un'importante affermazione implicita di CatB è che il codice aperto sia la cosa migliore dopo l'invenzione della ruota. Non importa se stiamo parlando di un programma formato da un centinaio di linee di codice o da centomila. CatB parte dal presupposto che Fetchmail e Linux appartengano alla stessa categoria. In realtà sono progetti piuttosto diversi, con molto poco in comune. Dal punto di vista dell'ingegneria del software c'è una differenza enorme fra un progetto relativamente semplice come Fetchmail ed uno complesso come il kernel di Linux.

Il problema vero è la comprensione del programma. E' sempre molto utile avere a disposizione il codice sorgente ma spesso non è sufficiente. E' necessaria della documentazione aggiuntiva per capire un certo programma. Questa necessità cresce in ordine esponenziale con la quantità di codice. Il reverse engineering , cioè l'esame del sorgente per ricostruire le scelte effettuate dagli sviluppatori originali, e la comprensione del programma sono due importanti aspetti dell'ingegneria del software che devono fare i conti con la qualità del codice. Provate ad analizzare un compilatore non banale senza avere una descrizione del linguaggio di programmazione. Ogni programma di una certa dimensione ha spesso una sorta di linguaggio di programmazione od un insieme di funzioni che emulano in astratto un computer. Il codice sorgente, quindi, è solamente una parte importante di una infrastruttura complessa e delle conoscenze di base utilizzate per creare programmi di grande complessità.

Chiunque abbia partecipato alla riorganizzazione di un progetto ricorderà per sempre il senso di frustrazione provato davanti ad una montagna di codice poco commentato (anche se non sempre scritto male). La disponibilità non aiuta molto se gli sviluppatori originali non sono più disponibili. Se un programma è scritto in un linguaggio di basso livello, come C, Cobol o Fortran, ed è poco commentato, allora tutte le decisioni di design sono perse nei dettagli del codice e devono essere riconsiderate. In queste occasioni il valore di una buona documentazione, come la descrizione delle interfacce e la descrizione dell'architettura del programma, può essere maggiore del codice stesso.

L'ammissione dell'inadeguatezza del codice ha portato a diversi tentativi di unire il sorgente e la documentazione. Uno dei migliori risultati è di Donald Knuth, nel suo libro Literate Programming (Stanford, Calif.: Center for the Study of Language and Information (CSLI), 1992). Probabilmente uno dei più famosi libri che hanno avuto uno sfortunato destino è stato Lion's Commentary on Unix , che conteneva ottime descrizioni del codice sorgente di Unix ed i relativi algoritmi, è stato copiato illegalmente per più di venti anni, dalla sua pubblicazione nel 1977.

La complessità e le dimensioni rendono il sorgente impenetrabile ai gestori del progetto come lo sono, diciamo, centomila linee di codice poco documentato di un compilatore. L'intrinseca incomprensibilità del codice in progetti molto complessi rende meno indispensabile la protezione del codice stesso una volta che il programma abbia raggiunto una certa maturità. Sono gli sviluppatori che ricevono danno dalla mancanza di informazioni.

Questo approccio è probabilmente la strada migliore per prodotti come, per esempio, i sistemi operativi, dove i programmatori possono trarre benefici dal facile accesso ad informazioni vitali per semplificare i controlli. Da questo punto di vista può essere considerata come una variante del principio "l'importanza di avere utenti" discusso prima. Le applicazioni sono la chiave per ottenere utenti, come ha fatto notare Enrico IV "Parigi vale bene una messa".

La complessità di prodotto software di una certa maturità può essere una protezione altrettanto efficace di un accordo di non divulgazione (notate che un contratto di questo tipo non preclude l'accesso al codice sorgente, crea solamente una barriera in più). La velocità di sviluppo di un certo prodotto commerciale può rendere l'appropriazione di una parte dei suoi componenti non così attraente come si potrebbe immaginare, specialmente se i concorrenti sono anche loro ad un alto stadio di maturità del loro prodotto ed hanno preso decisioni di sviluppo diverse.

Per creare un vantaggio è sufficiente creare una infrastruttura proprietaria necessaria per la comprensione del codice.

Tenendo in considerazione questi fattori sono portato a non essere d'accordo con CatB, che considera Netscape un banco di prova per il successo del modello open source:

"Netscape ci fornirà un esempio su larga scala di applicazione del modello del Bazaar in un contesto commerciale. La cultura open source adesso affronta un esame, se l'iniziativa di Netscape non funziona il concetto di open source può averne un tale danno che le entità commerciali potrebbero non prenderlo in considerazione per un'altra decina di anni."

E' utilizzare Netscape come test che è sbagliato, non credo che un eventuale fallimento porterebbe un reale danno al movimento open source, il livello di complessità dovuto all'apertura di un progetto oramai ad un notevole grado di maturità è probabilmente la principale causa di difficoltà nell'attrarre nuovi sviluppatori. Sarà necessario del tempo per capire se questo esperimento ha avuto successo o meno. A causa dell'importanza di Netscape nei confronti di IE sono stati fatti molti sforzi e ne saranno fatti di più in futuro per garantire il successo dell'iniziativa, ma è chiaro che la complessità del codice di Netscape rappresenta una formidabile barriera non facilmente aggirabile neanche da programmatori molto motivati e qualificati.

L'esperimento di Netscape suggerisce un'interessante ipotesi, il gruppo di sviluppatori principale si forma, normalmente, nelle prime fasi di vita di un progetto, quando è ancora comprensibile e le difficoltà intellettuali e tecniche sono ancora gestibili. Quando il progetto raggiunge un certo livello di maturità, si chiude su se stesso, questo rende molto difficile l'immissione di nuovi sviluppatori in un progetto in fase avanzata. Sarebbe interessante confrontare questa ipotesi con progetti come Perl, Apache e Linux, il gruppo di sviluppatori di grandi progetti rimane più o meno costante quando si raggiunge un certo grado di maturità? Se non si fa parte del progetto sin dall'inizio dovete spendere parte del tempo e delle risorse per recuperare il tempo perso?

Un esempio della difficoltà di gestire grandi quantità di codice è il cosiddetto "millennium bug" (Y2K), lasciando perdere tutta la pubblicità, l'essenza del problema 7egrave; che, nonostante la disponibilità del codice sorgente, molte aziende hanno speso e stanno spendendo tuttora una grande quantità di denaro e tempo per rimediare ad un banale errore di valutazione, fatto quando i programmatori hanno deciso di rappresentare l'anno con solamente due cifre. La lezione più importante è che per programmi molto anziani e complessi anche un piccolo problema può trasformarsi in uno enorme. Comprendere il codice senza la necessaria documentazione è una delle maggiori difficoltà che un programmatore deve affrontare, spesso è più difficile che scrivere del codice completamente nuovo. Nel caso manchino gli sviluppatori originali o la documentazione, riscrivere da zero tutto piuttosto che cercare di capire e modificare il vecchio codice può essere una soluzione più economica e pratica.

In ogni caso rendere di difficile reperibilità o comprensione i dettagli di un programma può essere un sistema per mantenere il controllo di un progetto open source, esamineremo questo caso in seguito.

La competizione nelle comunità di sviluppo basate su Internet

"Possiamo affermare che il primo principio della sociologia sia questo, nulla è ciò che appare."
- Peter Berger

La competizione, come molti fenomeni sociologici, è molto complessa e non deve essere idealizzata. In CatB molte delle affermazioni riguardanti questo argomento e le prestazioni dei gruppi di lavoro sono sia idealizzate sia primitive. Esiste una grande massa di letteratura riguardante l'economia, l'antropologia evoluzionistica e la sociologia, e sembra che sia stata ignorata da ESR. Poiché non c'è nessun riferimento a queste informazioni in CatB, il lettore può avere una errata impressione.

Come succede nelle gerarchie accademiche, la competizione coinvolge gruppi di individui che valutano loro stessi in relazione con in propri colleghi basandosi su una scala di valori comune. E' ingenuo pensare che la competizione migliori sempre le prestazioni di un gruppo spingendone i membri gruppo a lavorare più duramente. Alcune volte la competizione può influenzare negativamente il lavoro.

Poiché l'open source è un fenomeno sociale, la posizione di un individuo è influenzata sia dalla sua collaborazione (dal punto di vista puramente tecnico) ad uno o più progetti e dalle sue attività sociali all'interno del movimento. Un comportamento frequente sono le manovre politiche all'interno del gruppo di sviluppo del progetto open source. I detentori di questo potere politico normalmente negheranno la cosa, chi non ce l'ha, ma la vorrebbe si dichiara disinteressato ad ottenerla.

Le manovre politiche possono essere molto utili per migliorare la propria posizione all'interno della comunità, ma il successo di queste azioni può minare il morale del gruppo, le prestazioni, quindi, possono cambiare ed essere variabili, soprattutto se il gruppo non ha delle chiare indicazioni sul processo di "promozione" dei componenti. Credo che CatB non affronti molti aspetti della competizione sociale, fra questi voglio sottolineare:

la struttura gerarchica e la distribuzione del potere all'interno dell'ambiente open source;
la possibilità che si occupi posizioni non guadagnate sul campo (favoritismi);
problemi di confronto fra pari;
pericolo di sovra lavoro e conseguente esaurimento;
la paura di essere esclusi come metodo per motivare i componenti;
un'errata visione della promozione all'interno del gruppo;
il ruolo della stampa

La struttura gerarchica e la distribuzione del potere all'interno dell'ambiente open source

"Ogni problema è un problema politico, e la politica stessa è una massa di menzogne, inganni, fughe, odi e schizofrenia."
- George Orwell

CatB tende a descrivere il mondo open source come collaborativo, cooperativo ed armonioso, questa visione scevra da considerazioni politiche può portarci a credere che i membri abbiano sempre un comportamento positivo per il movimento. Iniziamo la nostra analisi di questo concetto dalla seguente citazione tratta da CatB:

"Mentre l'accesso economico ad Internet era una condizione necessaria per l'evoluzione del modello di Linux, non credo che da sola sarebbe stata una condizione sufficiente. Un altro fattore fondamentale era il cambiamento dello stile di gestione e dei comportamenti che permettono di attirare sviluppatori e di sfruttare appieno il mezzo di comunicazione.

Ma che caratteristiche ha questa nuova gestione e questi comportamenti? Non possono essere basati su relazioni di forza ed anche se avessero potuto non avrebbero potuto ottenere i risultati che vediamo.

... Lo "sforzo congiunto di molte persone" è proprio ciò che serve ad un progetto come Linux, il "principio del comando" è effettivamente impossibile da applicare a chi presta lavoro volontario nel paradiso anarchico che chiamiamo Internet . Per lavorare e competere efficacemente, gli hacker che vogliono dirigere un progetto collaborativo devono imparare come reclutare e suscitare interesse nel modo suggerito dal "principio di comprensione" di Kropotkin. Devono imparare ad esercitare la legge di Linus."

Ignorare l'esistenza di comportamenti politici e di strutture gerarchiche nella comunità open source significa ignorare la realtà dei fatti. Nella comunità in generale ed in ciascun progetto in particolare vi sono dei sistemi politici e le, a volte strane, corrispondenti strutture gerarchiche. Questo fatto può spiegare molti dei comportamenti irrazionali presenti all'interno del movimento open source. Altrimenti perché alcuni distorcerebbero o non rilascerebbero informazioni, limiterebbero il rilascio del proprio lavoro, esalterebbero i propri successi, minimizzerebbero i propri fallimenti, gonfierebbero le statistiche o parteciperebbero ad attività che appaiono estranee agli obiettivi del movimento open source?

Il potere nelle relazioni sociali è definito come l'abilità di obbligare le altre persone a fare cose che non farebbero altrimenti. E' rappresentato dalla posizione all'interno della comunità, il potere è una funzione di dipendenza, permette di manipolare il comportamento degli altri, Linus Torvalds, per esempio ha una considerevole autorità perché può accettare o rifiutare le modifiche proposte da altri sviluppatori. Il potere è un fenomeno complesso che ha molte sfaccettature, delle quali vorrei affrontare il potere di persuasione , gestito grazie alla possibilità di elargire riconoscimenti simbolici ritenuti importanti dalla comunità (la stampa open source ha questo potere e, da questo punto di vista, può essere considerata una macro-struttura politica) ed il potere della conoscenza, l'accesso ad informazioni non disponibili alla massa. Se un individuo controlla informazioni importanti e queste sono necessarie per delle scelte importanti, allora questo individuo ha un potere basato sulla conoscenza e lo può utilizzare. Quando la gente si riunisce in attività open source si stabiliscono legami ed equilibri di potere, è solamente questione di tempo prima che questo potere sia utilizzato.

Qualche volta il processo naturale della creazione delle strutture gerarchiche è considerato dagli sviluppatori come una reazione di difesa all'eccessiva abbondanza di e-mail e comunicazioni. Alan Cox descrive in questo modo il fenomeno:

"Quando Linux per 8086 fu rilasciato gli sviluppatori principali avevano gli altri membri della lista nella kill-list in modo da potere comunicare tramite la lista, semplicemente vi erano troppe persone che partecipavano, cessò di seguire il modello del bazaar per diventare un team ristretto di sviluppatori, che per molti è un modo educato per dire cricca . In quelle circostanze era un mossa difensiva inevitabile."

Definiremo i comportamenti politici di queste attività che non sono indispensabili come parte del ruolo ricoperto all'interno di un progetto o movimento open-source, ma che influenzano, o tentano di farlo, il comportamento degli altri componenti del gruppo. Alcune di queste azioni sono palesi, come il fomentare liti, ignorare la catena di comando, formare coalizioni, osteggiare le decisioni del "capo" o creare alleanze all'esterno del gruppo per rinforzare la propria posizione al suo interno. Altre sono meno appariscenti, come il sabotaggio e le proteste pubbliche che possono minare l'immagine di tutto il gruppo od il movimento. Molti comportamenti politici all'interno della comunità open source sono banali anche se alcuni cercano di "giocare duro". E' una questione di pragmatismo, certi tipi di comportamento sono passibili di pesanti sanzioni da parte del gruppo incluse sia la perdita della posizione sia l'appartenenza al progetto.

Mano a mano che la posizione raggiunta permette sempre più di gestire l'elargizione di "ricompense", allora iniziano le manovre politiche, questo è un problema tipico per ogni leader di qualsiasi tipo di progetto. CatB descrive le guide dei gruppi open source come individui democratici, ma in pratica gli sviluppatori principali tendono a vedere la loro posizione come un implicito permesso a prendere decisioni unilaterali. Questi personaggi hanno dovuto combattere duramente e pagare un pesante prezzo per la loro posizione, dividere il proprio potere con altri va contro i loro stessi interessi ed ambizioni, una presa troppo stretta sul potere, però può portare a conseguenze indesiderate. Le idee che i "principi del comando" siano aboliti e di un "paradiso anarchico" proposte da CatB sono delle semplificazioni. La storia dei progetti open source fornisce molti esempi del contrario:

"Una delle persone che hanno maggiormente contribuito al supporto per la rete fu Fred van Kempen. Dopo un periodo di incertezza seguente alle dimissioni di Ross dalla guida del progetto Fred offrì si offrì ed ottenne l'incarico praticamente senza opposizioni. Fred aveva piani ambiziosi riguardo alla direzione che doveva prendere il supporto per la rete di Linux e si mise al lavoro per raggiungere questi obiettivi. Sviluppò del codice chiamato 'NET-2' ('NET' era quello di Ross) che molte persone usarono con profitto. Fred aveva pianificato diverse innovazioni, come un'interfaccia dinamica, il supporto al protocollo AX.25 ed un'implementazione più modulare. NET-2 era utilizzato da un gran numero di utenti, il loro numero aumentava sempre più mano a mano che si spargeva la voce che funzionava bene. Il software di rete a quel tempo non era altro che un gran numero di modifiche alla versione standard del codice del kernel e non era inserito nei rilasci ufficiali. I documenti NET-FAQ ed il successivo NET-2-HOWTO descrivevano l'allora complessa procedura per fare funzionare le modifiche. L'interesse principale di Fred era quello di innovare il precedente supporto per la rete e questo richiedeva tempo. La comunità di utenti stava diventando impaziente per ottenere qualche cosa di realmente funzionante e che soddisfacesse la maggioranza degli utenti, come successe a Ross, la pressione su Fred, in quanto dirigente del progetto, aumentò.

Alan Cox propose una soluzione per risolvere il problema, si propose di analizzare il codice di NET-2, di eliminarne gli errori e di renderlo stabile, soddisfacendo in questo modo gli utenti e diminuendo la pressione su Fred permettendogli di continuare il proprio lavoro. Alan si mise al lavoro, la prima versione del codice fu chiamata 'Net-2D (debugged)', funzionava bene per molte configurazioni tipiche e gli utenti furono contenti. Alan aveva sia le idee sia le capacità per contribuire al progetto e vi furono molte discussioni relative alla direzione che dovesse prendere il progetto. Si manifestarono due distinte scuole di pensiero, la prima aveva come filosofia "per prima cosa deve funzionare, poi deve essere bello" l'altra "deve essere bello fin dall'inizio", fu chiamato in causa Linus che sostenne gli sforzi di Alan ed incluse il suo codice all'interno della distribuzione ufficiale del kernel. Questo mise Fred in difficoltà , lo sviluppo del suo lavoro avrebbe risentito della mancanza di utenti che lo provassero e questo avrebbe rallentato lo sviluppo. Fred continuò a lavorare al suo progetto per un certo tempo, poi rinunciò ed Alan diventò il nuovo gestore dello sviluppo della parte riguardante la rete del kernel.

Tutti i maggiori progetti open source sono strutturati gerarchicamente, questo permette al responsabile di imporre la propria volontà la quale, se necessario, può essere difesa dal punto di vista politico, con l'uso diretto della propria autorità, come nell'esempio precedente. L'affermazione "Non possono essere basati su relazioni di forza" ha una scarsa aderenza con la realtà.

Per lo stesso motivo la condivisione delle conoscenze ha i suoi limiti nel mondo open source, affronteremo meglio la questione più avanti quando affronteremo il concetto di "programmazione distribuita". Il potere basato sulla conoscenza è la migliore leva per influenzare il comportamento degli altri. La competenza è la miglior fonte di potere all'interno della comunità open source, nessun responsabile divulgherà tutte le informazioni in suo possesso perché potrebbe minare la sua posizione. E' inoltre fisicamente difficile divulgare tutte le informazioni, è troppo occupato dalla sua posizione. Il mondo open source non è immune dall'uso politico della diffusione conoscenza, il fatto che il codice sia disponibile non rende automatico l'accesso alle informazioni cruciali.

I membri con poco potere sono sempre alla sua ricerca, formando coalizioni per aumentare la propria importanza e migliorare la propria posizione. Le alleanze sono un fenomeno naturale, non è possibile evitarle, è la forza del numero. La via più naturale per acquisire importanza è quella di partecipare ad una coalizione, una volta che questa ha raggiunto un numero sufficiente di sostenitori può fare pressioni sul singolo responsabile e promuovere i cambiamenti che desidera. In un certo senso questo tipo di alleanza diventa una sorta di dittatore collettivo.

La possibilità di acquisire posizioni non meritate (favoritismi)

"Tutti gli animali sono uguali, ma alcuni sono più uguali degli altri."
- George Orwell

Il favoritismo è il conferimento di un qualsiasi beneficio, ricompensa o privilegio da parte del "capo" ad un membro del gruppo (assegnazioni preferenziali a determinati lavori o, in negativo, ignorare coscientemente il contributo di qualcuno) basandosi su preferenze personali, non sul lavoro effettivamente fatto od ai meriti tecnici. I favoritismi tipici sono stati ampiamente descritti nelle aziende tradizionali (vedere, per esempio, Prendergast & Topel, "Favoritism in Organizations," Journal of Political Economy, numero 104 (ottobre 1996): pp. 958-978), progetti distribuiti tramite la rete non sono immuni da questo fenomeno. Favoritismi, anche se solamente supposti, portano una diminuzione del rispetto, favoriscono dissapori e malcontento, portando tanti altri problemi che minano il morale del gruppo.

Se i responsabili compromettono la propria autorità ed il rispetto ricevuto permettendo trattamenti di favore, reali o meno che siano, sorgeranno diversi problemi all'interno del progetto. Se il leader si comporta come un capo carismatico, allora può delegare i compiti basandosi sul proprio giudizio personale, per potere effettivamente tenere sotto controllo i propri collaboratori la sua presenza deve essere percepita come indispensabile, normalmente in un progetto open source i primi collaboratori sono molto leali verso il loro leader. E' naturale che il responsabile di un gruppo si fidi, rispetti e dipenda dai collaboratori e sviluppatori iniziali, la vecchia guardia. Questo comportamento è il risultato di esperienze, interessi, obiettivi comuni, o semplicemente di una più lunga conoscenza. L'evoluzione sul lungo periodo di un progetto, però dipende da un ambiente dove i partecipanti sono valutati come individui e trattati in modo equo e corretto.

I favoritismi possono avere una connotazione negativa, considerate il disagio di un collaboratore di un progetto che pensa che il responsabile lo detesti, può sentirsi senza via d'uscita, ma che cosa può fare oltre che andarsene? In queste situazioni aiuta avere un po' di senso dell'umorismo. La formazione di un gruppo d'élite e l'esclusione di alcuni sviluppatori rispetto ad altri può problemi, le persone escluse possono andare via e collaborare con progetti concorrenti.

Problemi di confronti fra pari e della programmazione distribuita

"Il radicale inventa nuovi punti di vista, dopo che sono stati sfruttati conservatore li fa suoi."
- Mark Twain

Chi è al di fuori del mondo accademico immagina che il processo di revisione sia un meccanismo semplice, oggettivo ed efficace. In realtà una revisione semplice, oggettiva ed efficace può essere solamente un'approssimazione statistica, con ampie varianti nei casi individuali:

"Il processo di revisione ha attirato la sua parte di critiche dal mondo accademico (ma anche da altri) per anni. Molti (per esempio Agger, 1990; Readings, 1994) hanno obiettato che il giudizio del mondo accademico è intrinsecamente conservativo. Le persone scelte per effettuare il controllo, almeno per i periodici internazionali più importanti, sono normalmente rappresentanti di spicco nel loro campo di studio che hanno già superato i vari scogli della pubblicazione. Lavori originali che mettono in discussione le teorie ortodosse, anche se ampiamente incoraggiati, sono, in pratica, frequentemente ostacolati dagli studiosi che hanno tutti i vantaggi a non introdurre ricerche innovative nei periodici più famosi. Inoltre, se un contributore di un giornale famoso attacca le teorie tradizionali di una determinata disciplina è probabile che il suo manoscritto subisca il giudizio di uno o più studiosi, primi rappresentanti dell'opinione prevalente.

... Nel caso dei giornali molto dipende dalla buona volontà degli editori, aneddoti sul comportamento degli editori abbondano nei corridoi Queste esperienze, riferite da persone che possono essere particolarmente acide con le loro critiche o che hanno forti pregiudizi nei riguardi di una particolare ricerca, possono essere devastanti per il buon inizio di una carriera accademica. ... Secondo Agger (1990) a causa della mancanza di spazio sui giornali e l'abbondanza di manoscritti in molti campi di ricerca, le leve del potere rimangono nelle mani di chi corregge, controlla e pubblica i giornali. La sua analisi suggerisce che non ci sia semplicemente abbastanza spazio per tutti, almeno non nelle più autorevoli pubblicazioni internazionali. Agger sostiene che molti dei lavori non sono pubblicati o lo sono su giornali locali. Come risultato tutto questo lavoro rimane invisibile. Con così tanti studiosi in competizione per pubblicare qualche cosa su famose riviste internazionali, i tradizionali canoni di rispetto e supporto alla ricerca qualche volta possono venire meno."

Ammettiamolo, il vostro lavoro può essere rifiutato per semplice sovrabbondanza, gelosia, incompetenza o motivazioni politiche. Ogni aspirante partecipante al mondo open source deve essere consapevole di queste eventualità. La visione idealizzata dell'open source come una comunità ideale di individui che cooperano è un'illusione. Allo stesso tempo i benefici di un attento controllo superano largamente i problemi legati a situazioni del genere.

Per motivi simili il concetto di programmazione condivisa non funziona realmente nel mondo open source. Una cosa è condividere il codice, un'altra rendere disponibili le idee sottostanti. Il fulcro della programmazione efficace non è il "codice sorgente", ma la "comprensione". I gestori di progetti open source di successo sono spesso in posizioni scomode a causa di fattori politici che limitano il loro desiderio di condividere le proprie conoscenze.

La programmazione distribuita è definita (IEEE Std 610.12-1990) come:

"Una tecnica per lo sviluppo del software basata sul concetto della responsabilità del gruppo nello sviluppo del software piuttosto che su quella individuale. L'obiettivo è quello di prevenire una forte identificazione dei singoli programmatori con il progetto in corso in modo tale da non comprometterne l'obiettività delle decisioni."

In un contesto commerciale "prevenire una forte identificazione dei singoli programmatori con il progetto in corso" è uno scopo difficile da raggiungere, in CatB, invece, è considerata come una delle maggiori spinte motrici del movimento. Questo indica che, ammesso che esista realmente, la base della programmazione distribuita è alquanto traballante. L'identificazione con il progetto è imperante. Proteggere la propria posizione fa parte del gioco che lo si voglia o no, lo status è diretta conseguenza del proprio livello di conoscenza di alcune parti del sistema (nel caso di un programmatore di rilievo, delle sue parti fondamentali). Gerard Weinberg evidenzia i difetti di questo tipo di approccio quando scrisse (IEEE Software, volume 16, numero1 (1999, pp. 118-120)):

Il concetto di programmazione distribuita, descritto per la prima volta nel 1971 in The Psychology of Computer Programming, è probabilmente il più citato, il più incompreso ed il più negato dei concetti espresso nell'edizione originale di quest'opera. Mi sono sempre domandato se sarei riuscito a scrivere questo capitolo con maggiore incisività. Vi sarebbero state meno controversie se avessi utilizzato parole diverse. Probabilmente sarebbero serviti più esempi, o migliori, forse più prove scientifiche a supportare le mie affermazioni.

... Ho imparato qualche cosa in questi 25 anni: Se le ragioni per le quali non si vuole che il codice sia controllato non hanno basi logiche, non si potrà mai cambiare idea tramite un ragionamento logico... "

Anche se ha tenuto un centinaio di interventi e di interviste Linus Torvalds non ha mai pubblicato un solo articolo tecnico riguardante la struttura di Linux (se si esclude il suo tentativo di giustificare la struttura monolitica del kernel Linux in The Linux Edge ). Dobbiamo capire che gli sviluppatori a capo di un progetto sono in una posizione conflittuale per quanto riguarda la condivisione di informazioni essenziali. Ci sono varie spiegazioni razionali per il loro comportamento. In ultima istanza l'ingegneria inversa è un problema, un programmatore capace con il duro lavoro ed un po' di fortuna può scoprire la struttura di un programma o di un progetto, basta un po' di tempo e di indizi. L'abilità di risalire ad informazioni cruciali dell'architettura di un software è una fine dimostrazione delle capacità del programmatore, ed è un prova il cui successo permette di entrare nell'élite di un determinato progetto. Questo elemento è effettivamente preso in considerazione in CatB, sfortunatamente il sottostante conflitto è ignorato, la spinta a preservare il potere e di garantire la collaborazione degli sviluppatori:

"Il modo Linux si comporta sotto molti punti di vista come il mercato libero o come un ecosistema, un insieme di individui egoisti che cerca di ottenere il massimo del vantaggio, in questo processo si produce un ordine spontaneo dotato di auto-regolazione più elaborato ed efficiente di quanto avrebbe potuto produrre un sistema centralizzato di comando...

... La funzione di utilità che gli hacker Linux stanno cercando di massimizzare non è economica in senso classico, ma è l'intangibile soddisfazione del loro ego e l'aumento della propria reputazione fra i propri pari...

... Linus, ponendosi con successo come il gestore di un progetto il cui sviluppo è per lo più portato avanti da altri ed aumentando l'interesse nel progetto fino al suo auto-sostentamento, ha mostrato un'acuta comprensione del principio di Kropotkin della "conoscenza condivisa"."

Troviamo la stessa situazione in campo scientifico, gli scienziati sono ansiosi di condividere le proprie scoperte, ma normalmente sono molto attenti a non divulgare i metodi che li hanno portati a quei risultati. "Rivela la ricetta, nascondi la cucina" è probabilmente un principio applicabile al movimento open source tanto quanto quello della "conoscenza condivisa" proposto in CatB.

Il pericolo del sovraccarico e del burnout.

Lo sviluppo open source basato sul lavoro volontario è pericoloso anche per un altro motivo, per sviluppare un'applicazione complessa non è sufficiente dedicarci due ore durante i fine-settimana, è molto più simile ad un lavoro a tempo pieno ed sempre possibile un sovraccarico di lavoro se, oltre al suo "hobby" dedicato all'open source, il volontario ha un'intensa attività lavorativa o di studio. Parte del codice migliore proviene da chi è impiegato in aziende od università.

Paradossalmente il successo nasconde un pericolo reale per lo sviluppatore volontario che ha anche un regolare lavoro, se il programma ha successo e gli utenti rispondono in maniera entusiastica si rischia di entrare in un circolo vizioso che richiede sempre più del proprio tempo. Telefonate e posta elettronica si accumulano. Come insegnante professionista di scienze informatiche mi preoccupa la tendenza ad idealizzare il mondo open source. Il burnout è stato definito come una sindrome di esaurimento fisico ed emotivo, portando allo sviluppo di un pessima auto-stima, attitudine negativa verso il lavoro e perdita di interesse per il cliente e per le sue necessità. Esaminiamo un estratto della storia di Linux del 1998:

"Marzo

E' stato annunciato Linus 3.0. La nascita della seconda figlia di Linus ha provocato grande gioia ed un certo subbuglio nello sviluppo del kernel poiché il lavoro si è fermato e molte modifiche sono andate perse. Si sono levate alcune proteste quando è diventato evidente quanto l'intero processo sia dipendente dalla continua supervisione di Linus.

Ottobre

Esplode la tensione nella lista di discussione del kernel Linux (linux-kernel) dopo che troppe modifiche sono state rifiutate da Linus che sbuffa e si prende una breve vacanza. Ovviamente le cose tornano alla normalità, ma diverse persone continuano a parlarne, è diventato chiaro che il kernel di Linux sta diventando troppo complesso per essere gestito da una sola persona. Sono state discusse alcune misure per ridurre il carico di lavoro che grava su Linus, ma nulla è ancora stato fatto."

Il burnout è uno dei maggiori problemi nei lavori in cui ci si dedica molto agli altri, ma nel frattempo non si riesce a trovare del tempo per sé stessi. Non succede solamente ai programmatori, ma anche chi lavora come insegnante, giornalista, medico è od avvocato è vulnerabile al burnout. Può iniziare quando un programmatore ha difficoltà a stabilire delle priorità e, nonostante le pressioni degli utenti per miglioramenti o correzioni, capisce che il suo contributo volontario deve avere una priorità più bassa rispetto al lavoro ed alla famiglia. Alcuni fattori che contribuiscono a questa scelta possono essere:

stress continuo a causa di ritmi di lavoro eccessivi;
differenze fra le aspettative del lavoro e la realtà;
eccessivo carico di posta elettronica;
pessima gestione del tempo;
inutile competizione con programmi o sviluppatori commerciali;
conflitti di ruolo e di priorità fra il lavoro, la famiglia ed il proprio impegno come sviluppatore volontario;
problemi di progettazione del software scoperti in uno stadio avanzato dello sviluppo, associato all'errato uso degli strumenti od alla scelta dei metodi sbagliati;
tendenza al perfezionismo, difficoltà di adattarsi ai cambiamenti e nel rigettare le richieste di supporto o di miglioramenti fatte dagli utenti;
aspettative esagerate e l'impossibilità di raggiungere obiettivi multipli, e
mancanza di aiuto da parte degli altri sviluppatori del progetto.

Sono stati riscontrati effetti variabili dall'apatia all'attacco di cuore, la percentuale di responsabili di progetti open source che hanno subito almeno una volta gli effetti della depressione indotta dal burnout è sconosciuto. La maggior parte dei programmatori ha imparato come gestire questo tipo di stress, quelli che non ce la fanno cadono preda della depressione. Spesso quelli ai quale accade sono coloro i quali hanno mostrato le maggiori potenzialità all'inizio della loro carriera, questi sono perfezionisti, idealisti e stakanovisti. Essi iniziano la loro carriera nel mondo open source in modo entusiastico, pronti a fare il miglior lavoro possibile. Normalmente sono persone energiche, hanno un'attitudine positiva, sono ambiziosi e spesso cercano di fare il passo più lungo della gamba.

La gestione di un progetto complesso può aumentare pericolosamente le probabilità di burnout del responsabile. Normalmente lo sviluppatore principale si assume il tutta la responsabilità della gestione, a meno che sia la base di utenti sia di programmatori non siano ridotte solamente il numero di messaggi di posta elettronica ricevuto può essere soverchiante. Per progetti di successo questo vuole dire che le mail degli utenti possono interferire con lo sviluppo e con la manutenzione e tutti e tre insieme interferiscono con la normale vita lavorativa e famigliare. Il problema dello stress da tecnologia a causa dell'eccesso di informazioni (una combinazione di ansietà, troppe informazioni e conflitti di ruolo) ed il possibile burnout dei responsabili dei progetti non è neanche menzionato in CatB. Craig Brod definisce lo stress da tecnologia come:

"... un moderno problema di adattamento causato dall'incapacità di venire a patti con le nuove tecnologie informatiche in maniera positiva. Si manifesta in due modi distinti, nella difficoltà di accettare l'informatica ed uno più specifico di identificazione con la tecnologia informatica."

Di nuovo voglio sottolineare che i responsabili dei progetti open source di successo ricevono una tale quantità di posta elettronica che solamente leggerla può essere un lavoro di per sé. In questa intervista del 1995 Linus Torvalds afferma:

"D: Cosa fa durante la giornata (normalmente cosa occupa il suo tempo, scuola, Linux, tempo libero)?

R: Linux occupa la maggior parte delle mie ore lavorative, solamente leggere le e-mail che ricevo richiede un minimo di due ore al giorno e lo sviluppo riempie il resto della giornata. Riesco comunque ad avere tempo per i miei passatempi, posso occuparmi di Linux come lavoro all'università, sanno che sviluppo Linux e ad loro va bene così."

C'è anche un altro aspetto che un'analisi attendibile del modello open source dovrebbe predire, la scalata al successo. Come nello sport ognuno vuole essere un campione ed almeno all'inizio il fondatore di un progetto open source deve dimostrare di essere migliore dei suoi concorrenti, il problema in ciò è che rischia di diventare una gara al massacro contro prodotti migliori o commerciali ed ad ogni nuovo rilascio ci si aspetta che il progetto raggiunga almeno la parità con i concorrenti, non importa a quale costo. Utenti fedeli chiedono nuove funzioni presenti negli altri programmi e si aspettano di ottenerli, non si rendono conto che il progetto si basa sul lavoro di volontari e di conseguenza possono avere priorità e ritmi di lavoro diversi. Per esempio, in passato molti utenti hanno protestato per la lentezza nello sviluppo dimostrata da Debian in confronto a quella di RedHat.

A causa della sua posizione lo sviluppatore principale deve anche prendersi carico della gestione del progetto, la maggior parte dei messaggi degli utenti saranno diretti a lui. Questo vuole dire che a meno che non ci sia una gerarchia di aiutanti per filtrare le informazioni (sia nell'acquisizione sia nella condivisione), il responsabile di un progetto open source sarà fortemente limitato dall'abbondanza di dati. E' possibile che le sue capacità ne soffrano creando malcontento.

Facciamo il punto della situazione, iniziare un progetto open source può essere semplice e divertente, ma portarlo al successo può essere molto difficile. Il costante sviluppo di un programma complesso può essere un sfida eccessiva per degli sviluppatori volontari e può trasformare un progetto inizialmente interessante in estenuante lavoro di manutenzione. Gli sviluppatori open source dovrebbero vedersi di più come scienziati, dopo avere creato le basi di un progetto ed averlo portato ad un certo livello di maturità dovrebbero farsi da parte oppure trasformarsi in uno sviluppatore professionista e vedere se il mondo lo accetta o meno. In queste scelte ovviamente vi sono anche implicazioni personali e problemi ideologici, ma dividere il progetto in due rami, uno libero e l'altro commerciale (come TCL e Sendmail), o creare un'azienda commerciale per beneficiare dello sforzo dei volontari può essere una scelta razionale che dovrebbe essere seriamente presa in considerazione. Per un progetto open source complesso e di successo lo sviluppo basato sul lavoro di volontari dovrebbe essere solamente una fase transitoria.

La paura dell'esclusione come fattore motivazionale.

"Ottieni da una parola gentile e da una pistola molto di più di quello che otterresti da una parola gentile solamente."
- Al Capone

Teoricamente non c'è di che avere paura, non c'è nessun obbligo di partecipare ad un progetto open source, se non volete potete semplicemente smettere di contribuire allo sviluppo. La realtà, però, è più complessa. Maggiore è il successo ottenuto dal progetto più siete legati ad esso, anche se frustrati ed insoddisfatti da come vanno le cose potreste preferire di continuare lo sviluppo ed il supporto a causa della paura di esserne esclusi. Per creare un prodotto di successo dovrete sacrificare tempo ed energie, uno sviluppatore può investire nel programma anni, facendo innumerevoli sacrifici solamente per trovare il tempo da dedicare allo sviluppo. In alcuni casi un membro del progetto può alienarsi la famiglia e gli amici, non tutti possono apprezzare tale zelo nel seguire la filosofia open source. In questi casi ci si può trovare in trappola, non c'è una via per uscire indenne dalla situazione ed in entrambi i casi se ne esce sconfitti. Nel caso si decidesse di continuare si può trovare qualche forma di conforto e comprensione in posti come Slashdot, Linuxtoday ed altri gruppi di discussione che enfatizzano lo sforzo che c'è dietro i programmi open source. Nel caso si decidesse di smettere si dovrà cercare un nuovo sistema di valori e questo potrebbe presentare dei problemi. CatB prende in considerazione questa eventualità:

"Ma in che cosa consiste lo stile di un capo e quali sono questi comportamenti? Non possono essere basati sulla forza delle relazioni interpersonali ed anche se fosse possibile comandare tramite la coercizione non porta ai risultati che vediamo."

L'uso della coercizione come leva nel mondo open source è non solo presente, ma la paura di essere esclusi la rende uno strumento molto potente. Il reale valore di un gruppo informale di sviluppatori ed utenti si scopre spesso solamente dopo che uno programmatore ha abbandonato il progetto e la sua perdita può essere molto dannosa in quanto le capacità professionali e sociali da esso acquisite non possono sopravvivere alla sua partenza.

Eventuali errori nella scelta di condotta.

"Solamente le persone superficiali non giudicano basandosi sulle apparenze."
- Oscar Wilde

In base alla mia esperienza come docente di informatica sospetto che la maggior parte delle persone che partecipano ad un progetto open source, in particolare coloro i quali vi dedicano una parte consistente del proprio tempo, sono giovani (16-25 anni). Le scuole superiori e gli anni del college sono un periodo di transizione dall'adolescenza all'età adulta. Per essere considerato un adulto, un ragazzo deve fare delle scelte sul lungo periodo, in alcuni casi ha troppe poche informazioni per valutare le conseguenze delle proprie azioni. Per esempio, si deve scegliere una carriera per il futuro, una compagna ed adottare un certo sistema di valori. La programmazione in generale ed in particolare quella open source fornisce una scappatoia dalla necessità di decidere. Non è accidentale che le attività della comunità hacker al di fuori del tradizionale ciclo programmazione/compilazione/correzione siano generalmente guardate con sospetto e comunemente considerate attività meno "nobili". "Prima programma, poi correggi, infine pensa" sembra essere l'essenza del comportamento dell'hacker, questo, in certe cerchie di persone, serve per distinguere gli hacker dai normali programmatori. Se l'indifferenza per alimentazione e vestiario si estende alle scelte per l'architettura di un programma, allora il tempo dedicato alla correzione degli errori di programmazione sarà dominante. Ogni errore non riscontrato in fase di progettazione costerà dieci volte più tempo per trovarlo durante la fase di programmazione e altrettanto per porvi rimedio. La scelta di strumenti sbagliati o troppo vecchi contribuirà al tempo perso.

Alcuni identificano l'abilità di lavorare ininterrottamente per quarantotto ore di seguito come "una cosa positiva" ed una prova della reale appartenenza al mondo degli hacker, sfortunatamente una maratona di programmazione/compilazione/correzione lunga tutta la notte può essere deleteria. Come risultato solamente solo i migliori, che trasgrediscono questa regola, fanno un buon lavoro, altri rinunciano perché non seguendo procedure collaudate i loro sforzi non sono premiati dal gruppo. Certamente uno dei peggiori aspetti della cultura hacker è la sua tendenza a mettere in secondo piano la progettazione del programma e le pratiche suggerite dall'ingegneria del software. E' come suonare il pianoforte, solamente i migliori talenti possono improvvisare, lavorare senza avere in mente un preciso progetto, elaborato dopo un attento studio e la pianificazione delle varie fasi,il tutto dopo avere studiato i migliori testi sull'argomento.

L'hacking, inizialmente una via di fuga, può diventare la via più importante per la propria affermazione sociale. CatB non spiega realmente cosa rende la competizione nel mondo open source così intensa ed importante, sospetto che non sia solamente questione di altruismo o motivazioni legate all'ego, può diventare un carriera parallela, come per le piccole aziende neonate è un ambiente rischioso, solamente pochi raggiungono la fama ed una certa remunerazione economica. Qui l'analogia con il mondo scientifico si fa più stretta, alcuni ottengono notevoli benefici finanziari dall'avere un certo status, anche se informale, all'interno della comunità open source, come nei circoli accademici, la reputazione può essere convertita in "moneta sonante" per i membri più importanti della comunità, ma può anche renderli schiavi di questo miraggio.

Il ruolo della stampa.

"Io posso sempre attenermi rigidamente alla verità, con l'eccezione del momento in si ammanta di inadeguatezza; io posso rigettare qualsiasi forma di crimine o di comportamento ignobile, eccetto quando è commesso da colui che indossa i miei vestiti... ."
- Mark Twain riguardo alla sua investitura al ruolo di direttore del Buffalo Express

Linus Torvalds (come successe a Microsoft con Internet) era l'"ultimo arrivato" nel mondo di Unix, ma il suo primo e maggiore successo è stato quello di portare dalla sua parte una preesistente comunità di sviluppatori (quella che si dedicava allo sviluppo di Minix) ed il relativo canale di comunicazione (il gruppo su Usenet) e successivamente di crearne uno proprio. In quel momento la comunità legata a Minix, un'élite di entusiasti di Unix, aveva approssimativamente quarantamila membri e includeva un grosso gruppo di sviluppatori di talento (alcuni dei quali avevano già tentato, con successo, di riscrivere parti di Minix per renderlo maggiormente compatibile con lo standard POSIX). Questo cambiamento di rotta di una comunità preesistente verso nuovi obiettivi è stato uno dei più importanti eventi della storia di Linux, dimostrando, inoltre, la forza di Internet come nuovo canale di comunicazione. Nessuno dei sistemi operativi precedenti era stato sviluppato usando questo approccio. Ovviamente la comunità era vulnerabile, c'erano state dei diverbi fra il leader della comunità (Andy Tannenbaum) e il gruppo trainante degli sviluppatori. I programmatori principali di Minix divennero il nocciolo della nuova comunità di sviluppatori di Linux, la gerarchia dei membri era già ampiamente stabilita, questo probabilmente ha aiutato ad evitare dannosi conflitti.

Riviste specializzate in Linux nacquero nel 1994 quando Robert Young (uno dei fondatori e CEO di RedHat) e ACC Corporation pubblicarono i primi due numeri di Linux Journal. Più tardi Phil Hughes ne divenne il direttore. Nel marzo 1994, SSC, l'editore di Unix Pocket References, rilevò la pubblicazione di Linux Journal da Robert Young ed ACC Corporation. E' poco chiaro quanto questo aiutò RedHat, ma è abbastanza chiaro che all'inizio la stampa specializzata fosse una potente leva sul piano politico e fortemente a favore di Linux.

La forza della stampa aiutò immensamente Linux, la lotta fra le possibili alternative non si fermò al piano tecnico, come lascia intendere CatB, senza questo supporto politico è possibile che FreeBSD (tradizionalmente il sistema operativo scelto dagli fornitori di connettività Internet) sarebbe stato più popolare. Le ragioni della diffusione di Linux sono più complesse di quelle prese in esame da CatB. Vorrei solamente sottolineare che la stampa specializzata diede a Linux un notevole vantaggio rispetto ai suoi concorrenti, come FreeBSD, ed il suo ruolo è completamente ignorato in CatB.

Fra la "stampa" dedicata a Linux, i servizi di notizie come Slashdot e Linuxtoday probabilmente sono tanto se non più importanti delle pubblicazioni tradizionali come Linux Journal, Linux Gazette e Linux Focus. Anche se Linuxtoday è emerso come servizio di notizie privilegiato Slashdot è un fenomeno più interessante, è un insieme unico di notizie, discussioni tecniche e gruppi di discussione che ha creato una comunità in stile BBS detta degli "slashdotters". Il numero di partecipanti è talmente ampio che è stato osservato un "effetto slashdot", quando un articolo od un programma di particolare interesse è riportato su Slashdot ci sono spesso problemi al server ospite a causa dell'eccessivo numero di accessi.

Slashdot.org illustra bene sia l'idealismo sia l'intolleranza che permea il movimento open source, essendo una delle comunità più grandi e popolari Slashdot funge da nodo di diffusione per l'apologia di Linux. Il ruolo dei fondatori di Slashdot come evangelizzatori di Linux è molto più importante di quello di ESR ed è generalmente sottostimato dalla stessa comunità Linux.

Slashdot serve anche come strumento politico per combattere l'opposizione, ma l'analisi di questo fenomeno esula dallo scopo di questo articolo, ma voglio parlare brevemente del cosiddetto "slashnoise", sotto questo nome possono essere accomunati i messaggi tramite i quali i lettori esprimono le proprie opinioni riguardo a programmi od articoli che però non sono mai stati effettivamente analizzati da chi commenta. Queste lettere possono essere considerate come una sorta di lysenkismo, molto vicine alle "lettere dei lavoratori e dei contadini" pubblicate dal giornale Pravda durante il periodo di Lysenko che possono essere così riassunte "non ho letto il libro, ma lo condanno". Alcuni studiosi, come il Dottor Shaffer di Harvard (The Addiction Letter, (Agosto 1995)), ritiene che i gruppi di discussione come quelli di Slashdot diano una sorta di dipendenza. In questo senso, gli estremisti di Slashdot sono prigionieri della gabbia creata da loro stessi:

"I servizi on-line non sono sono dannosi come la cocaina o l'alcool, ma nel mondo contemporaneo è un modo pericoloso per estraniarsi dalla realtà... Giocatori d'azzardo compulsivi sono sempre in bilico fra l'abilità e la fortuna, quando questa attrazione diviene un'ossessione l'appassionato di computer può essere paragonato al giocatore incallito... Al contrario di altri tipi di passatempi, il computer è uno stimolante psichico, ed una certa fascia della popolazione può sviluppare una certa dipendenza in risposta a questo stimolante."

Sospetto che la distribuzione degli interventi in Slashdot sia probabilmente vicina a quella rappresentata dal principio di Pareto , conosciuta anche come legge 80/20 o, in altre parole, approssimativamente il 20% degli utenti partecipano all'80% delle discussioni. Confermare questa distribuzione potrebbe essere difficile, molti messaggi sono inseriti sotto lo pseudonimo generico di "Anonimo vigliacco" ed ogni persona può avere più pseudonimi.

Il Linux Project ha creato un interessante progetto chiamato Linux Documentation Project, nel corso degli anni questa iniziativa è riuscita con notevole successo a produrre piccoli documenti chiamati How-To, manuali più corposi, a livello di libro non sono mai stati molto numerosi, la scarsità di documentazione dei dettagli tecnici di Linux è strana, come mai? Credo che il problema siano i conflitti interni, secondo CatB, però non c'è nessun problema riguardante la documentazione:

"Molta gente (specialmente chi cerca di attaccare politicamente il mercato libero) si aspetta che una cultura gestita da singoli individui sia frammentata, territoriale, sprecona, ostile e avara di informazioni, ma queste supposizioni sono chiaramente smentite dalla impressionante varietà e qualità della documentazione di Linux. Spesso si dice che i programmatori odino i manuali, ma allora, come mai gli hacker di Linux producono così tanta documentazione? Evidentemente il "libero mercato" legato a Linux riesce a indirizzare meglio le energie di quando riescano a fare le compagnie commerciali produttrici di software con i loro ben sovvenzionati reparti per la creazione di documentazione."

In realtà il progetto dedicato alla documentazione di Linux soffre per l'eccessiva burocrazia (per esempio accettano testi solamente in SGML e testo semplice, lo HTML non è accettato) e pessima gestione (alcuni contributori si sono lamentati che ha richiesto loro più di un mese per sottomettere la nuova versione di un HowTo).

Sospetto che gli autori della documentazione abbiano lo stesso senso di insicurezza dei responsabili dei progetti open source di successo, ma essi hanno ancora minori possibilità di limitare gli abusi, la licenza GPL per la documentazione è molto meno attraente della licenza GPL per il codice. Se la grande quantità di codice garantisce una limitata sicurezza a causa delle sue stesse dimensioni non è così per la documentazione, non è un incidente che i migliori libri su Linux siano stati prodotti da aziende commerciali e che diversi autori di documentazione abbiano in seguito pubblicato nuovi manuali con case editrici.

Conclusione

Molti dei problemi del mondo open source e la loro interpretazione in CatB sono molto complessi, spero che questa breve analisi in questo articolo stimolerà una discussione costruttiva e che possa essere utilizzata per il futuro da ricercatori e sviluppatori del mondo open source.

Il problema maggiore con il modello del Bazaar è che non può predire i punti di forza e le debolezze del modello opensource, per questo motivo non è una valida metafora, una specie di unità di misura per i programmatori, come il mitico mese-uomo. Sono profondamente convinto che un modello accademico dell'open source spieghi molto meglio il fenomeno. La ragione della popolarità di Linux è molto più complessa del "modello di sviluppo del Bazaar" descritto in CatB.

Allo stesso tempo CatB è un'importante opera che stimola la discussione sull'open source come organismo sociale ed il valore di utilizzare Internet per lo sviluppo del software. Anche se il valore di CatB è in qualche maniera limitato da alcune lacune nei fatti e dal suo tono moralistico, non si può negare che descriva molto bene importanti caratteristiche che possono essere fondamentali per garantire il successo del modello di sviluppo sia open source sia commerciale.

CatB incoraggia un completo ripensamento riguardo alle migliori pratiche di sviluppo del software, specialmente per quanto riguarda la sua apertura ai contributi, l'ultima caratteristica può essere presente in entrambi i mondi per ottimizzare la spinta allo sviluppo ed incrementare le probabilità di successo del software.

In conclusione voglio sottolineare che, nonostante i suoi difetti, CatB ha il pregio di aprire alla discussione il fenomeno open source. Lavori successivi su questo argomento hanno beneficiato di potersi riferire ad una messe di materiale, compreso lo stesso CatB. Anche se alcune delle idee espresse in CatB sono lontane dal centrare l'obiettivo e diversi importanti argomenti sono stati semplicemente omessi, quest'opera ha reso un importante contributo fornendo un'infrastruttura per iniziare una discussione sul fenomeno dell'open source, il valore di CatB in questo ruolo non deve essere sottovalutato. Nikolai Bezroukov è un Analista di Rete Senior alla BASF Corporation, docente di Informatica alla Fairleigh Dickinson University (NJ) e webmaster di www.softpanorama.org , Open Source Software University, un sito gestito da volontari e del programma SDNP delle Nazioni Unite, che ha come scopo di favorire la connettività ad internet e la diffusione di Linux nei paesi in via di sviluppo. Ha lavorato ad uno dei primi programmi di classificazione dei virus e nel 1991 ha scritto un famoso libro in lingua russa sul tema, Computer Virology (leggete anche l'attuale posizione dell'autore sull'argomento ). Attualmente è più interessato alla sicurezza nel commercio elettronico, nel Perl e nei cosiddetti File Manager Ortodossi (Midnight Commander, eccetera).

E-mail: postmaster@softpanorama.org

Il traduttore

Pietro Leone lavora come amministratore di sistema presso il Gruppo Abele di Torino e come consulente free-lance. Appassionato di informatica, utente Amiga, GNU/Linux e programmatore, molto dilettante, in ARexx, C, Perl e PHP. Altri hobby: storia militare, strategia, Giochi di Ruolo e lettura.

<- Introduzione alla programmazione di un chess engine - Copertina - Indice ->