|
|
<- Software libero per il trattamento di problemi scientifici - Indice Generale - Copertina - Personaggi e avvenimenti -> |
|
Agorà
di Nikolai Bezroukov, traduzione a cura di Pietro Leone
L'articolo...Il modello del bazaar di Eric Raymond propone un punto di vista troppo semplicistico del processo di sviluppo dei progetti Open Source (OSS, Open Source Software). Questo articolo cerca di esplorare i punti in comune fra questo modello di sviluppo e la ricerca accademica per analizzare possibili migliorie alla metodologia di sviluppo Open Source. Questo può essere visto come un caso speciale di ricerca scientifica: guardando il mondo Open Source sotto questo punto di vista sarà probabilmente più facile comprendere questo fenomeno. L'articolo è la traduzione del testo presente su http://www.firstmonday.dk/issues/issue4_10/bezroukov/. È un testo del 1999, quindi molti link non sono più validi. |
Introduzione
Postulati de "La Cattedrale ed il Bazaar"
Lo sviluppo Open Source come uno speciale caso di scienza
applicata
Problemi e limitazioni del modello Open Source
Conflitti fra gli sviluppatori del mondo Open Source
Pseudoproblemi
Conclusioni
"La programmazione open source è come il sesso, solamente un errore e dovrete sopportarne il peso per il resto della vostra vita."
M. Sinz, CBM Inc.
La natura dello sviluppo dei programmi open source mi affascina: questo è il motivo per il quale sono diventato, oltre che un contributore, anche un osservatore ed uno studioso di questo ambiente. Allo stesso tempo, durante la mia esperienza come capo-redattore di Softpanorama Bulletin e la mia carriera di insegnante, sono diventato spiacevolmente consapevole della visione troppo ottimistica ed irrealistica che gli studenti e persino alcuni "addetti ai lavori", come Eric Raymond, hanno del movimento open source.
Vi sono molte cause di questa visione distorta della realtà. I progetti open source vanno di moda e fanno notizia. Questi, però, troppo spesso enfatizzano gli obiettivi raggiunti ed i programmi più famosi, ma non menzionano le difficoltà, i fallimenti ed i progetti non più sviluppati. I fallimenti, normalmente, non fanno notizia. Questo lascia in molti l'impressione che l'open source sia la panacea, la soluzione per risolvere tutte, o quasi, le difficoltà. Questo articolo è un approccio scettico all'argomento, rispetto all'open source, e penso che sia ottimo per l'insegnamento, ma vedo anche molti problemi. Non sono preoccupato che la franchezza e lo scetticismo di queste pagine possa scoraggiare molti sviluppatori open source: la necessità di programmare è insita in molti, proprio come lo è il produrre latte per una mucca oppure lo scrivere per uno scrittore. Un semplice articolo critico non porterà un vero entusiasta dell'open source ad arrendersi. Queste pagine potrebbero, però, evidenziare agli sviluppatori del movimento i problemi legati al fatto di lavorare a questo tipo di progetti e diminuirne le frustrazioni.
Credo che ci siano seri problemi nel modello di sviluppo open source, che devono essere discussi e compresi, ed il miglior modo possibile per farlo è quello di usare l'analogia fra l'open source e la comunità scientifica (in effetti queste due comunità in parte si compenetrano). In aggiunta, questo articolo affronta varie e differenti problematiche dell'OSS che mi hanno intrigato durante gli ultimi due anni.
Adesso parliamo della parte "scettica" dell'articolo: a partire dal suo famoso La Cattedrale ed il Bazaar, Eric Raymond, ha pubblicato una serie di articoli (leggete, in particolare, i suoi commenti sui cosiddetti documenti di Halloween) promuovendo un'ottimistica e semplicistica visione dell'open source, quella di una variante socialista (o, per essere più esatti, marxista) dello sviluppo di software.
Questo articolo è, in una certa misura, una reazione alla politica "Usa e migliora" di Raymond nei confronti di Linux e dei programmi correlati, al suo tentativo di rappresentare questo movimento come un singolo (e semplice) fenomeno che chiama "open source". Particolarmente spiacevole è il fatto che abbia deriso la Free Software Foundation (FSF): senza questa organizzazione Linux non sarebbe semplicemente stato realizzato. Stesso trattamento ha subito la Open Source Initiative: "open source" è una bella definizione, io la preferisco, ma rimane ciò che è, un bel nome. Il recente interesse intorno al movimento è dovuto a Linux, non perché il motto "open source" sia diventato improvvisamente attraente. Date un'occhiata, per esempio, a Shut Up And Show Them The Code (Tacete e fategli vedere il codice) e, soprattutto, ai commenti di Leandro Dutra.
"Per ogni problema complesso c'è una soluzione breve, semplice ed errata."
H. L. Mecken
La serie di articoli de "La Cattedrale ed il Bazaar" (e soprattutto i commenti di ESR sui cosiddetti documenti di Halloween), ha alcuni postulati impliciti (qui usiamo il termine "postulato" per intendere un sottostante concetto dato per assunto come nella geometria euclidea) che presenta l'"open source" come una soluzione miracolosa;
"Se inizi a dimostrare cose che già hanno fatto, prendendoci confidenza, aumentando la complessità delle tue soluzioni, solo per il piacere di farlo, allora, un giorno, ti guarderai intorno scoprendo che nessuno avrà fatto una cosa del genere! Questa è la strada per diventare un ricercatore informatico."
Richard Feynmann
Per prima cosa voglio evidenziare che internet può significativamente ridurre il costo della distribuzione di molti tipi di software, come sistemi operativi, compilatori ed utilità varie. La Rete rende possibile produrre un numero virtualmente infinito di copie perfette accessibili da remoto di programmi per computer, presentazioni multimediali od interessanti discussioni effettuate via e-mail.
È generalmente accettato che, a causa del costo di duplicazione del software pari quasi a zero, si crei una grossa differenza fra i programmi per computer e tutti gli altri prodotti di consumo. Queste differenze sono in parte ignorate, volutamente o meno, nel normale modello di distribuzione del software. Credo che la creazione di software sia simile allo sviluppo di una teoria scientifica. Vorrei classificare la programmazione come un tipo, od almeno un parente stretto, di attività scientifica. La seconda importante differenza fra il software e gli altri prodotti è che le piccole modifiche sono facili da apportare, i programmi sono più adattabili. Questa è un'altra importante analogia con il mondo scientifico.
In entrambi gli ambienti, coloro che vi lavorano non lo fanno per i soldi: molti degli sviluppatori open source lo fanno inseguendo un sogno, non per ingrassare il proprio conto in banca. Possono essere spinti da una serie di motivazioni diverse, ma ve ne sono molti con grandi doti di programmazione che, semplicemente, sono sotto-utilizzati nel loro ambiente lavorativo. Alcuni hanno bisogno di un determinato programma e non lo trovano, oppure è troppo costoso, allora provano essi stessi a crearlo. Di nuovo, essi stanno inseguendo un sogno, non cercando di vincere una competizione.
Grazie ad internet è adesso possibile creare un gruppo virtuale per lo sviluppo del software: parallelamente, in campo scientifico, si creano delle comunità virtuali interessate allo studio di determinati fenomeni.
La struttura e le responsabilità del gruppo possono essere molto dinamiche, il software sarà prodotto non da un'unica persona isolata o da un gruppo, ma da un gruppo molto dinamico di persone. Vorrei evidenziare come i vari gruppi di lavoro si rifacciano alle passate comunità informali di scienziati che utilizzavano lettere scritte a mano per condividere idee, soluzioni e critiche.
Ancora oggi si sa poco di come operino i cosiddetti team virtuali che comunicano tramite internet (IVT, Internet Virtual Team) e che tipo di problemi sorgano in questo tipo di cooperazioni. Alcune difficoltà evidenti possono essere:
Vi sono altri problemi palesi con i progetti open source che sono stati messi in evidenza da altre fonti. La comprensione di queste problematiche può probabilmente aiutare adesso e nel futuro lo sviluppo open source. Credo che le difficoltà dello sviluppo open source siano in gran parte simili a quelle con le quali si deve confrontare la comunità scientifica e che si possano meglio comprendere in questo contesto. Da un punto di vista teorico, i partecipanti ad un progetto open source posso essere considerati come uno speciale esempio di collaboratori accademici. Le soluzioni per i tipici problemi che possono sorgere in questo campo possono essere facilmente applicate anche al mondo del software libero e potrebbero portare grandi benefici al modello di sviluppo open source.
Il finanziamento dei progetti del software libero è molto simile a quello delle ricerche scientifiche. Alcune volte queste sono sostenute finanziariamente in modo indiretto, soprattutto perché singoli collaboratori si interessano ad un particolare fenomeno ed effettuano delle ricerche con i fondi pre-esistenti. Un considerevole numero di sviluppatori open source lavora o in una istituzione accademica oppure in una grande azienda. Le grandi società normalmente forniscono un ottimo ambiente per lo sviluppo di progetti open source perché spesso hanno delle nicchie nelle quali gli sviluppatori sono sotto-utilizzati. Lo sviluppo iniziale di Unix nei laboratori della Bell è un ottimo esempio di questo fenomeno.
Recentemente molte grandi società usano un altro sistema per finanziare i progetti open source: quando uno di questi può promuove un sistema hardware strategicamente importante per l'azienda, allora questa può dedicare uno o più programmatori allo sviluppo del programma libero. Il recente impegno della Digital con Linux sembra appartenere a questo filone, anche quello di IBM e di Intel ricadono in questa categoria.
L'attività delle distribuzioni Linux e di IBM in favore di Apache è un esempio della terza via: in questi casi le aziende tentano di migliorare nell'uso di un prodotto che esse stesse vendono oppure di erodere delle quote di mercato in sfavore di Microsoft. Questo approccio è molto simile al mondo della scienza applicata, dove il mondo degli affari vende i risultati della ricerca scientifica.
"L'esperienza è un'ottima cosa, ti permette di riconoscere un errore quando lo ripeti."
jdstone@ingr.com
L'open source è un interessante ed importante fenomeno, ma, come la scienza, ha un insieme di problemi intrinseci che devono essere compresi. Per ognuno dei progetti open source abbiamo uno sviluppatore o un gruppo di sviluppatori che si operano per rendere il pacchetto sempre migliore. Se un prodotto ha un bug, lo sviluppatore responsabile del progetto vorrà rimuoverlo, ma la realtà non è così semplice. Di seguito c'è il mio limitato ed incompleto tentativo di classificare i problemi del mondo open source.
"L'open source funziona, ma non è assolutamente una panacea... Produrre software è difficile, il problema non è così semplice."
Jamie Zawinski
Nei documenti chiamati "Halloween I" è indicato che la creazione di sistemi e protocolli pre-esistenti potrebbe essere raggiunta più velocemente grazie ad internet; per altri tipi di progetti l'uso di questo canale potrebbe rendere il processo più lento rispetto a quello che sarebbe usando mezzi più tradizionali. Un progetto riconosciuto potrebbe essere utilizzato come banco di prova per valutare la velocità di progresso, potrebbe anche fornire un parallelismo utile per le comunità di sviluppatori che si tengono in contatto grazie ad internet.
Quando il lavoro di programmazione richiede che tutti procedano seguendo un unico percorso, allora la velocità di sviluppo del modello open source può essere lenta, se non più lenta di quella dei modelli tradizionali. In questi casi non c'è un implicito vantaggio nell'utilizzare internet. Un fattore chiave spesso è la personalità dello sviluppatore principale. TeX, per esempio, è stato creato senza l'uso di internet. Dubito che l'aiuto di una comunità che utilizzasse internet come canale di comunicazione avrebbe fatto qualche differenza.
Allo stesso tempo una grande comunità può inibire l'innovazione, rendendo il progetto stagnante. Come dice Jamie Zawinski:
"Vi sono delle eccezioni, ma, in generale, le grandi innovazioni sono sviluppate da piccoli gruppi di persone che sono guidate verso un' unico obiettivo. Maggiore è il numero delle persone coinvolte più lento e elefantiaco sarà lo sviluppo."
C'è, però ancora un problema di velocità nello sviluppo open source. Credo che, se la velocità è realmente importante, allora un sistema autoritario abbia dei decisi vantaggi rispetto a quello democratico. "La velocità uccide" e la prima vittima è la democrazia (un fatto messo in evidenza per la prima volta da Frederick Brooks nella sua analisi dello sviluppo dello OS/360). Uno stile meramente autoritario però porterebbe alla creazione di una élite ed ad una struttura fortemente gerarchica che, presto o tardi, porterebbe alla morte il progetto open source in questione. Ogni tentativo, quindi, di spingere oltre un certo limite la velocità di sviluppo degli attuali progetti di software libero potrebbe portare a conseguenze imprevedibili, inclusa il cambiamento della struttura "sociale" della comunità del progetto. La competizione con Microsoft (così come è promossa da alcuni evangelisti del mondo open source) potrebbe essere molto pericolosa per tutto il movimento. Per competere con un'organizzazione autoritaria la velocità di sviluppo è fondamentale.
Piccoli progetti non necessitano di una esplicita struttura che li coordinino, la guida è, automaticamente, il leader del progetto od il gruppo formato dai personaggi principali. Questo approccio non si adatta facilmente: per grandi progetti il sistema autoritario è quello più efficace, se la velocità è fondamentale. Se la celerità nello sviluppo è percepita come un' obiettivo importante per il progetto, allora la comunità di sviluppatori, consciamente o meno, aumenterà l'autorità attribuita al proprio leader. Alcune volte, però, questo può, portare a problemi.
Come dice Jordan Hubbard, "Nonostante ciò che, di volta in volta, possono affermare, sbagliando, i sostenitori del software libero, i modelli di sviluppo centralizzato come quello del progetto FreeBSD raramente sono in ritardo od inefficienti nel mondo open source. Una più attenta analisi del successo di modelli ritenuti anarchici, rivela un notevole grado di centralizzazione che fa parte integrante del loro processo di sviluppo.
Molto dipende anche dal fatto che il progetto abbia un singolo e preciso obbiettivo (per esempio, ricreare UNIX, implementare il protocollo HTTP) che può essere efficacemente comunicato e perseguito dal gruppo.
Generalmente per un progetto open source in rapida evoluzione il livello di centralizzazione è alto. Questa necessità può essere percepita come "culto della personalità", dove un singolo sviluppatore ha una grande autorità (come, per esempio, Linus Torvalds e Linux). Questo può portare ad un alto livello di insoddisfazione con la conseguente nascita di più filosofie di sviluppo dello stesso software in competizione fra loro. Esempi di ciò sono NetBSD/OpenBSD, Emacs/Xemacs e gcc/egcs. Se Linus Torvalds dovesse rifiutare troppe modifiche importanti a Linux si potrebbe vedere, in futuro, la nascita di due diversi rami di sviluppo per il kernel.
Il mondo open source, normalmente, enfatizza la qualità e la semplicità non la velocità di sviluppo. Una maggiore enfasi sulla qualità come obiettivo di un progetto, infatti, sul lungo periodo, aumenta le probabilità di sopravvivenza.
"Fatemi vedere il codice."
Linus Torvalds
Gli sviluppatori non creano programmi da soli, gli utenti hanno l'ultima parola e gli utenti con un indirizzo di posta elettronica possono giocare un ruolo importante nel processo. Le e-mail possono spesso avere la forma di provocazioni, oppure possono migliorare lo stato all'interno del movimento creando dei benefici; ad una particolare struttura burocratica. Alan Cox coniò entrambi i termini "effetto da consiglio comunale" e la frase "Comitato per la gestione del piano di sviluppo del kernel di Linux". Nella sua opera "Cathedrals, Bazaars and the Town Council", Alan Cox scrive (il corsivo è mio):
"Il problema che iniziava ad emergere era l'arrivo di molte persone, molte delle quali benintenzionate e pericolosamente impreparate, con suggerimenti, non codice, suggerimenti. Essi sapevano abbastanza da sapere come dovesse essere scritto, ma molti di essi non avevano le conoscenze necessarie per scrivere un "hello world" in C. Iniziarono, quindi, a discutere per settimane a riguardo e votarono per decidere quale compilatore utilizzare e come scriverne uno, tutto ciò dopo un anno che il progetto aveva già iniziato ad usare un compilatore perfettamente adeguato allo scopo. Erano occupati a dibattere su come creare dei binari adatti e non conoscevano neanche la struttura del kernel.
Linux 8086 fu rilasciato, i reali sviluppatori avevano molti degli altri membri della lista nella loro lista nera. Quindi potevano comunicare, ma c'era semplicemente troppa gente. Cessò di essere un modello a bazaar e si trasformò in un team di sviluppo, che per molti non è altro che un modo educato per indicare una "cricca". In questo caso non è stato altro che una normale reazione difensiva.
Nel caso di Linux la base di utenti/programmatori crebbe lentamente partendo da coloro i quali contribuirono con del codice e che era parte della comunità di Minix o che aveva imparato le cose nella maniera più difficile, riavvio dopo riavvio. Mano a mano che il progetto cresceva, la gente che voleva divenire parte del "Comitato per la gestione del piano di sviluppo del kernel di Linux" fu piuttosto inserita in un ambiente dove ci si aspettava che essi proponessero del codice e dove le loro mancanze non avrebbero creato problemi. Per citare Linus "fatemi vedere il codice"."
"Nel mondo, per avere successo non è sufficiente essere stupidi, devi anche essere bene educato."
Voltaire
Il contenuto dei messaggi nei gruppi di discussione può dare l'errata impressione che internet sia piena di spazzatura. È comune, per gli utenti della rete, lamentarsi per la mancanza di cooperazione, decoro e notizie realmente utili. Questo, però, non è completamente vero, ma è un campanello di allarme e la situazione sta peggiorando.
Un viaggio casuale nel ciber spazio farà trovare esempi di ostilità, egoismo e semplice non-senso (esattamente come succederebbe in una casuale passeggiata nel mondo reale). Il recente sviluppo del "marchio open source" ne mostra un esempio lampante: per molti è più facile essere ostili durante una discussione via e-mail che in un faccia-a-faccia. Questo spiega parzialmente molti dei feroci botta-e-risposta che sprecano tanta banda altrimenti dedicata a temi tecnici.
Vi faccio qualche esempio. Fred Moody scrive:
"Quando ho contattato un convinto oppositore di Microsoft, che lavora in quello che è probabilmente il più utilizzato sito commerciale basato su Linux, mi ha risposto immediatamente tramite mail che avrebbe parlato delle manchevolezze di Linux, ma solo in modo anonimo. "Io lavoro con questi fanatici di Linux che mi hanno quasi licenziato per le mie critiche a Linux."Molte dei difetti di Linux, a quanto dicono i miei esperti, sono quelli che ci si aspetterebbe da un sistema operativo libero che ha tante versioni quante sono le persone che lo usano (come UNIX anche Linux tende a cambiare perché il codice sorgente è disponibile a chiunque voglia metterci mano).
"Linux non è sicuro e non è stabile," mi scrive un altro informatore, "è un bersaglio in perenne movimento che non esce mai dalla fase sperimentale...certo, molti lo usano per siti di produzione. Conosco parecchia di questa gente, non dormono a sufficienza e sono pallidi per la mancanza di sole. Ho amministrato un grosso negozio con Linux, richiede molto lavoro di amministrazione e se vuoi che le cose veramente funzionino devi spendere una gran quantità di tempo a mettere a posto le cose a mano. Il numero dei problemi di sicurezza e di stabilità è enorme."
...Discussioni sulle debolezze di Linux possono essere trovate su diversi siti, insieme ai programmi utilizzati dagli hacker per attaccare i siti basati su Linux. Per chi non vi partecipa, molte delle discussioni fra i sostenitori di *BSD, Solaris e le altre varianti di UNIX sembrano fumose e strane, "Farà freddo all'equatore prima che L. Torvalds metta da parte il suo ego per accettare le buone idee proposte da qualcun altro".
Vi sono diatribe anche contro FreeBSD. Larry McVoy riassume la situazione così:
"Voglio evidenziare che alcuni fanatici di BSD (come me) hanno abbandonato BSD in favore di Linux per ragioni diverse da quelle tecniche. In particolare, il mondo BSD è elitario, agonistico e non cooperativo. O fai parte di quelli che "contano", oppure no, e questo fa una grande differenza. Io ho di sicuro le caratteristiche per farne parte, ma ho rifiutato l'invito perché non mi piaceva la struttura che prendeva le decisioni, il mondo di Linux è un posto molto più bello.
Infine Linux è coperto dalla GPL, BSD no, se BSD ritornerà mai in auge le persone che "contano" potranno, e lo faranno, impedire l'accesso ai sorgenti (provate a mettere le mani sul codice di BSDi, per esempio)."
Il modello open source è un parente stretto del modello di sviluppo scientifico, il codice è paragonabile ai risultati delle ricerche ed è pubblicato perché sia a disposizione di altri programmatori e per l'avanzamento del genere umano. I problemi sono molto simili in entrambe le discipline, le priorità e la correttezza sono vitali sia per i ricercatori sia per gli sviluppatori open source. Ho visto un comportamento equivalente nella comunità scientifica. Normalmente le dispute sono gestite in maniera più matura, anche se non meno accanita. Ecco un esempio portato da un anonimo:
"Cosa succede allo sviluppo di un progetto open source quando la gente che scrive il codice non si sopporta? Gli autori open source come gestiscono i conflitti con gli altri sviluppatori di software libero? Lasciatemi raccontare la mia prima esperienza come manutentore di un software open source, credo che sia un buon esempio di quello che può succedere. Utilizzavo un programma (che chiameremo P, per Programma), due anni fa mi ero offerto volontario per proseguirne lo sviluppo quando, uscita la versione 1.0, l'autore non aveva più tempo per farlo.
Al tempo in cui mi sono preso carico del mantenimento e dello sviluppo del pacchetto avevo molto tempo libero al lavoro. Il mio superiore era molto comprensivo e mi permetteva di utilizzare un certo numero di ore la settimana di lavoro retribuito al programma, cosa che credo non succeda da molte parti.
Il tempo passava, il nostro giro di affari cresceva ed io avevo sempre meno tempo da dedicare a P: sono riuscito a rilasciare una versione alpha contenente qualche miglioramento, ma alcuni utenti non erano contenti della velocità dello sviluppo. Uno di essi decise di portare avanti una sua versione del programma. Chiameremo questo signore Sig. J.
Normalmente sarei stato contento di ciò, l'open source si basa proprio su questo. Comunque, sembrava che il Sig. J volesse solamente la fama, io avevo rilasciato una versione 2.0 beta di P, basata sulla versione 1.0 dell'autore originale, il Sig. J aveva rilasciato una versione 1.2, anch'essa basata sul codice della 1.0, con alcune sue modifiche. Questo, secondo me, generò molta confusione, il suo programma aveva lo stesso nome del mio ed un numero di versione simile. Chiesi, quindi, se per favore potesse cambiare il nome del pacchetto, per non confondere gli utenti.
La sua risposta fu di dichiarare pubblicamente che, poiché io ci stavo mettendo troppo tempo, egli avrebbe dovuto essere considerato il manutentore ufficiale di P. Io sarei stato molto contento di potere affidare a qualcun altro lo sviluppo, se solo fossi stato convinto che colui che se ne sarebbe occupato avrebbe fatto un buon lavoro, ma non credo che il Sig. J ne sarebbe stato in grado (giusto per usare un eufemismo). Tralascerò la discussione che abbiamo avuto nella mailing-list di P (ospitata dal mio server di posta) poiché conteneva molti infantilismi da parte del Sig. J. È sufficiente dire che la cosa finì con il Sig. J che mi insultava e che dichiarava che avrebbe inserito P in un grande progetto che stava sviluppando.
Il Sig. J compilò una lista dei partecipanti della mia mailing list e ne creò una sua, dichiarò che la sua era la versione ufficiale di P e smise di partecipare al mio forum. Dopo tutti i litigi ero contento che avesse deciso di andarsene.
Questo è tutto, almeno sino a quando qualcuno spedì una domanda riguardante la mia versione di P alla sua lista (alla quale ero stato iscritto).
Il sig. J colse l'occasione per nuovamente insultarmi pubblicamente e fece alcuni commenti sulla mia lentezza nello sviluppo. A quel punto era troppo, gli ho scritto dicendogli che non volevo che lui menzionasse più il mio nome. Speravo che iniziasse ad ignorarmi, lasciandomi lavorare tranquillamente su P per conto mio.
Ragazzi, quanto avevo torto. Il Sig. J mi scrisse che lui avrebbe fatto quello che avrebbe voluto (per dirla in modo educato), inoltre aggiunse al suo file .sig una sua offerta, indirizzata a me, di atti osceni con lui, file che utilizzò pubblicamente, sia nelle mailing-list sia in genere.
Stupefatto, scrissi al Sig. J ed ai suoi fornitori di spazio web e di connettività minacciandoli di denuncia se non avessero rimosso il mio nome dai messaggi. Questo portò ad un'altra brutta risposta del Sig. J, ma alla fine lo obbligarono a rimuovere il mio nome dalla suo file .sig.
Questo ci porta al presente, adesso ho una tale impressione negativa di tutto ciò che non ho molta voglia di pensare a P, ci lavoro molto poco. Ho smesso di svilupparlo pubblicamente e l'unico avanzamento del programma è una versione per uso personale che non vedrà mail la luce del sole."
Il problema
"Benedetti sono coloro i quali non hanno aspettative perché essi non resteranno mai delusi."
BuddhaSembra che i progetti open source abbiano più successo nei campi nei quali sono maggiormente interessati, direttamente od indirettamente, i loro sviluppatori. La crescita di internet ha reso disponibili una gran quantità di diversi progetti. Il periodo iniziale di un progetto open source, la creazione di un prototipo più o meno completo da parte di un singolo individuo, tende ad essere molto orientata allo sviluppo, il che significa complessa, ma programmi non meno utili possono essere considerati inutili o poco interessanti. Chi sa programmare tende naturalmente a lavorare su programmi che ritiene interessanti od alla moda (editor di testo o temi per Gnome, per esempio) piuttosto che su altri considerati meno interessanti. Senza altri incentivi oltre che la gioia di "smanettare" o un posto nella "fiera della vanità" molti progetti meritevoli di miglior fortuna non sono più sviluppati perché l'autore originale perde interesse e nessuno ne raccoglie il testimone.
La tendenza è probabilmente positiva: senza che ci sia divertimento non ha nessun senso sviluppare programmi open source al di fuori del contesto commerciale. Programmare senza la gioia di farlo non è altro che un altro tipo di schiavitù. Lo sviluppo del software libero, visto come un tipo di ricerca scientifica, dovrebbe concentrarsi sugli aspetti più interessanti e lasciare lo sviluppo dei programmi più comuni alle realtà commerciali.
Non tutti i progetti sono creati nella stessa maniera. I contributi principali in un progetto riguardano direttamente le parti del codice significative per gli sviluppatori, quelle inerenti al sistema operativo, all'interfaccia grafica ed agli strumenti di sviluppo. Per un progetto non direttamente connesso a questi campi gli incentivi sono molti di meno e la qualità ed il numero dei contributi possono non essere sufficienti per mantenere lo sviluppo costante.
Lasciatemi iniziare citando una recente intervista a Dennis M. Ritchie:
"LF: non posso non fare paragoni fra lei e tutte le persone che stanno attualmente lavorando gratuitamente su progetti liberi, giusto per il piacere di farlo, anche se sono sicuro che non rifiuterebbero di essere pagati per il lavoro che compiono gratis. Se non lavorasse ai laboratori della Bell, lei si vedrebbe coinvolto in un progetto come Linux od uno simile? Dall'interno di un innovativo centro di ricerca, con molti anni di esperienza sulle spalle, come considera queste persone? Poiché il nostro giornale è rivolto principalmente agli utenti di Linux, non possiamo esimerci dal fare qualche domanda riguardante questo sistema operativo. Prima di tutto, qual è la sua opinione riguardo al successo che riscuote attualmente Linux e la decisione di molte aziende di sviluppare software per esso (la Bell, per esempio: di Inferno c'è una versione anche per Linux)?
Dennis: lasciatemi dare un'unica risposta a queste due domande. Credo che il fenomeno di Linux sia stupendo, soprattutto per il fatto di basarsi pesantemente su ciò che offriva Unix. Linux sembra essere il più sano dei molti derivati di Unix, anche se vi sono anche i vari sistemi BSD e le diverse offerte commerciali ufficiali dei produttori di mainframe. Non aiuta, però, il fatto che i derivati liberi di Unix sembrino soffrire dello stesso tipo di frammentazione e problemi che c'era, e c'è tutt'ora, nel mondo commerciale."
La frase "...i derivati liberi di Unix sembrano soffrire dello stesso tipo di frammentazione e problemi che c'era, e c'è tutt'ora, nel mondo commerciale" è il sintomo del problema fondamentale, "la tragedia delle versioni". Abbiamo già adesso una dozzina di differenti distribuzioni Linux incompatibili fra loro, con Debian e RedHat come protagonisti e con grandi sostenitori e diverse altre come attori secondari (SuSE, Caldera, Mandrake, Slackware, eccetera). Credo che, in un certo senso, Linux soffra di disordine da personalità multipla. Questo vuole dire che un'applicazione scritta per funzionare su Linux della RedHat potrebbe non farlo su quello della Caldera a causa, per esempio, delle differenti versioni delle librerie utilizzate.
Come scrive Jordan Hubbard "...è un desiderio perfettamente umano quello di volere formare dei clan e vestirne con orgoglio i colori, la diversità e la competizione sono cose positive ed incoraggiano l'innovazione e motivano le persone a raggiungere un più alto livello di produttività. Quando aggiungete al tutto un ego iper-sviluppato, però, le cose diventano confuse molto velocemente, quando uno dei gruppi decide di voler essere IL GRUPPO, l'unico in lizza quando il premio per i migliori colori sarà assegnato. Senza che passi troppo tempo i clan rivali iniziano a lanciarsi frecce infuocate l'un l'altro, attaccano la base avversaria, rendendo la vita difficile a tutti coloro che vorrebbero semplicemente vivere tranquilli."
Il problema del NIH è legato a questo fenomeno. Tutto nel mondo del software è artificiale, come in una comunità accademica: ad un certo punto del processo di maturazione l'aggiunta di una nuova caratteristica, di qualche modifica, o di una limitazione nella licenza diventa improvvisamente una questione ideologica. Le comunità del software si suddividono allora in gruppi: i "permissivi", gli "oppressi" e gli "ortodossi". Se uno di questi gruppi riesce ad avere successo è solo questione di tempo prima che diventi a sua volta "ortodosso", ed allora avverranno altre divisioni.
È ovvio che Linux voglia distinguersi da FreeBSD e che FreeBSD non desideri essere confuso con Linux. Queste due entità lottano nella stessa nicchia ecologica, per una questione di prestigio. Essendo FreeBSD meno compatibile di Linux ed a causa di problemi legali con AT&T, ad un certo punto il movimento FreeBSD ha perso inerzia e dopo ha sofferto anche della competizione di OpenBSD (dopo che questo era emerso come valido concorrente su piattaforma Intel in seguito alla nascita di OpenBSD da una costola di NetBSD). Come risultato Linux sembra il signore incontrastato, cannibalizzando le risorse disponibili.
Questo non significa però che il problema non possa ad un certo punto riproporsi. Per esempio, se ad un certo punto un numero sufficiente di sviluppatori del kernel di Linux giudicassero la gestione di Linus insoddisfacente e pericolosa per il futuro di RedHat, Linux potrebbe suddividersi nel Linux "ortodosso" e, diciamo, Redux. Sarebbe interessante vedere se questo potrebbe succedere se, supponiamo, Alan Cox considerasse non soddisfacente il lavoro di Linus Torvalds. Il cambio del nome sarebbe sicuramente obbligatorio, essendo Linux un marchio registrato di Linus.
Infatti, una grossa "guerra di religione" è in atto rispetto alle qualità di KDE e GNOME. Di per sé non è per niente una cosa positiva. Come succede nelle comunità scientifiche, nel movimento del software libero le faide hanno la precedenza sulle questioni ideologiche e tecnologiche. La maggior parte di queste dispute sembrano prive di senso agli "esterni", ma i problemi fra GNOME e KDE servono per illustrare sia la grande forza del movimento sia il suo tallone d'achille. Il punto è ideologico perché KDE è stato creato basandosi su una componente non protetta dalla GPL, non libera agli occhi dei puristi di Linux.
Anche se KDE è l'interfaccia maggiormente sviluppata, la maggiore distribuzione Linux, RedHat, ha dedicato personale e denaro al miglioramento di GNOME. Come scrive Andrew Leonard:
"Siamo dispiaciuti che sia stato fondato il progetto GNOME," dice Bernd Johannes Wuebben, uno sviluppatore di KDE. "Crediamo che ciò di cui abbia bisogno la comunità sia unità ed identità di obiettivi, non di standard in competizione e della continua ostilità che gli elementi più estremisti del progetto GNOME e del movimento del software libero hanno rivolto contro KDE... Crediamo nel software libero, ma crediamo che le visioni più radicali...siano utopiche e che alla fine danneggino seriamente la comunità. Pensiamo che ci sia posto per entrambi gli aspetti, sia per quello commerciale sia per quello libero."
Larry Augustin crede che, dal punto di vista puramente tecnico, GNOME sia sicuramente l'interfaccia più avanzata, ma rimprovera il fatto che RedHat, il leader del mercato, non fornisca l'interfaccia più evoluta nella sua distribuzione, limitando così la penetrazione di Linux. Bob Young della RedHat risponde che la loro distribuzione è la più diffusa perché la comunità si fida di loro e che questa fiducia dipende dalla capacità della RedHat di scegliere la tecnologia giusta da proporre. Suggerisce, inoltre, che la successiva versione della distribuzione conterrà KDE come opzione, in pacchetti separati da quelli principali.
I non addetti ai lavori vedono tutto ciò con una certa perplessità: il grande vantaggio di Microsoft è che offre agli sviluppatori un singolo standard da seguire e garantisce agli utenti la compatibilità dei programmi. Linux, invece, ha almeno cinque distribuzioni principali: oltre a RedHat e Caldera ci sono anche SuSE (tedesca), Slackware e Debian (completamente libera). Ognuna di esse è differente dalle altre, ha diverse procedure di configurazione e richiede approcci differenti per installare software aggiuntivo.
Le aziende statunitensi, senza parlare dei singoli utenti, sono intimidite da tanta varietà, a causa della confusione che si potrebbe creare. Allo stesso tempo, però, la diversità è la grande forza di Linux. "È la bellezza dell'anarchia, della libertà", dice Bob Young, "le distribuzioni che non fanno un buon lavoro non sopravvivono sul lungo periodo."
"È un vantaggio perché c'è più scelta e competizione," dice Augustin. "I produttori delle distribuzioni competono per rendere la propria migliore delle altre. Questo aiuta moltissimo. C'è molto poco di non libero in una distribuzione: è molto semplice per qualcuno rilasciare una versione modificata e libera della RedHat. I produttori, quindi, devono sempre migliorarsi: se non lo facessero i clienti migrerebbero verso la migliore distribuzione dal punto di vista tecnico."
In assenza di un supporto agli utenti e di un reparto commerciale, il riscontro degli utilizzatori, e quindi lo sviluppo (soprattutto le richieste per nuove caratteristiche), si ripercuote sugli utenti più esperti. Questo rende il software libero più attraente per "chi ci sa fare". Unix, tradizionalmente, è più popolare negli ambienti accademici, di ricerca, scolastici e dei programmatori professionisti, tutte categorie che possono essere considerate come composte da utenti avanzati.
"Nulla al mondo può sostituire la perseveranza: non può farlo il talento, niente è più comune di un perdente colmo di talento. La genialità non può, il genio incompreso è quasi proverbiale. La cultura non può, il mondo è pieno di acculturati derelitti. La perseveranza e la determinazione sono onnipotenti."
Calvin Coolidge.
Così succede nel mondo aziendale: i vari progetti si influenzano negativamente a vicenda (Linux e Hurd), disperdendo le risorse (vedi il documento Halloween I):
"Nel momento in cui un progetto non raggiunge una massa critica di sviluppatori, quel progetto diventa storia. In questo momento Linux sta rallentando lo sviluppo di BSD acquisendo molte delle sue idee principali. Questo limita la competizione in modo simile a quanto succede nel mondo dei componenti per computer: il possesso della maggioranza del mercato conferisce un enorme potere di controllo sull'evoluzione del mercato stesso."
Possedere una grande quota di mercato comporta dei rischi: uno di questi è che questo blocca l'innovazione. Come scrive Jamie Zawinski:
"...La compagnia cessa di rinnovarsi, l'azienda diventa sempre più grande e, semplicemente, le grandi aziende non sono creative. Esistono delle eccezioni, ma in generale le grandi innovazioni sono fatte da piccoli gruppi con una guida forte e con un'identità di obbiettivi. Più persone sono coinvolte e più lenta e miope sarà la loro unione.
C'è anche un altro fattore da considerare: possiamo dire che il mondo dell'industria è composto da due tipi di persone: coloro i quali vogliono lavorare in un'azienda per renderla di successo e quelli che desiderano lavorare per una società di successo. La rapida crescita ed il veloce successo di Netscape ci portò dall'essere appartenenti al primo gruppo ad entare a fare parte del secondo."
"Mai nella storia degli umani conflitti, così tanti dovettero così tanto a così pochi."
Winston Churchill
Il mondo open source può sembrare una democrazia, ma non lo è. Molte persone a capo dei più famosi progetti liberi descrivono esplicitamente la loro funzione come quella di dittatori. Se a Linus Torvalds non piace la tua patch, non importa quanto sia buona dal punto di vista tecnico. È lui ha decidere cosa deve essere inserito nel kernel. Malcom Maclachlan scrive:
"L'esempio migliore è lo stesso Linux. Il suo creatore, Linus Torvalds, ha l'ultima parola su tutti i cambiamenti da apportare al popolare clone libero di Unix. Poiché la comunità che si occupa dello sviluppo di Linux è diventata così vasta, molte delle patch che sono proposte sono visionate da molte persone prima che passino a lui.
Linus ammette che quando rifiuta una patch può significare che molte persone hanno buttato al vento molto lavoro, ma questo gli permette di gestire Linux senza dovergli dedicare la totalità del suo tempo.
"Il lavoro che ricade su di me è diminuito dal fatto che non devo controllare le idee più pazze: io sono l'ultima tappa di un processo di revisione che può durare mesi o addirittura un anno."
Se la velocità di sviluppo è un aspetto fondamentale (come nel caso di Linux), il capo deve esercitare un controllo pressoché assoluto sul codice di altri (e sulla direzione che deve seguire il progetto). Questa situazione tende ad essere un problema mano a mano che il progetto diventa famoso.
Un leader determinato e dedito al progetto è essenziale per la sopravvivenza del software nei primi stadi di vita. Spesso le qualità di un capo ed i problemi di gioventù dei primi tempi possono portare ad un notevole livello di centralizzazione il quale, ad un certo punto, può oggettivamente portare ad un culto della personalità nel più puro stile socialista.
Le stesse qualità del leader che possono assicurare il successo nei primi stadi di vita, però, possono - e accade spesso - essere un problema nel periodo successivo, quando le qualità che contano vanno oltre la dedizione e le dimensioni del progetto e rendono impossibile la gestione da parte di una singola persona. Le stesse qualità che creano il successo nei primi tempi possono compromettere tutto successivamente: l'esempio di Linux e quelli precedenti di Emacs e del GCC sono tipici di questo fenomeno.
Vorrei evidenziare che se il progetto guadagna fama, questo stesso successo porta un'enorme mole di lavoro sulle spalle del leader, cosa che può portare allo sfinimento dello stesso. Questo è il prezzo da pagare per il successo.
Il ritmo di lavoro dovrebbe essere stabilito dal capo del progetto ed è in questo caso che l'analogia con il mondo accademico è più evidente. Innanzitutto voglio ribadire che "la velocità uccide." Fare pressioni sul leader porta spesso all'effetto opposto. Linux non è un lavoro come un altro. C'è un forte legame fra Linux e le comunità del software libero: in esso è presente la cultura della "GNU generation". Questa è molto simile a quella Unix della metà degli anni '80. Fino al recente arruolamento di massa da parte di RedHat e delle altre distribuzioni, gli sviluppatori lavoravano su Linux per diverse ragioni, ma la maggior parte lo faceva per divertimento e per sfida (molti di essi provenivano dai tempi di Minix). Questi programmatori ricevettero riconoscimenti e svilupparono un senso di appartenenza ad un gruppo e il potere di controllo della situazione. Togliete loro quel piacere con tabelle di marcia ferree e, a meno di convertirli in dipendenti legati dallo stipendio o dalla possibilità di acquistare azioni a prezzi vantaggiosi, molti di essi rinunceranno. Il fatto, quindi, che molti sviluppatori Linux siano stati assunti è uno sviluppo molto positivo che impedisce l'abbandono da parte di questa "vecchia guardia".
Se usassimo la metafora di Eric S. Raymond in un contesto diverso, Linux potrebbe essere visto come una cattedrale costruita amorevolmente da un gruppo di persone per esprimere la propria passione verso Unix. La capacità di attrarre una comunità geograficamente distribuita è caratteristica dei movimenti politici e religiosi. Anche se le persone sono fisicamente separate, tutte stanno lavorando per un importante obbiettivo comune. Questo è il carburante del movimento che gravita attorno a Linux.
Oltre ad un percorso per la propria crescita, ogni grande movimento sociale necessita di un nemico, un avversario che può essere utilizzato come potente forza aggregatrice. Non è quindi una sorpresa che la maggior parte della comunità Linux ed open source odi "l'impero del male". La storia dei movimenti politici e religiosi ci suggerisce che il mondo open source non è solamente un'accozzaglia di sviluppatori e di utenti che si tiene in contatto tramite internet, e che è motivata solamente dal mutuo riconoscimento. Questo si muove ad un livello diverso, più come un movimento politico e per questo ha un suo percorso politico.
Probabilmente la voce più importante del suddetto percorso è quella che ne indica l'avversario, che è incarnato da Microsoft. Io lo chiamo ABM/BTM ("Anything But Microsoft/Better Than Microsoft", tutto tranne Microsoft/meglio di Microsoft): entrambi i concetti sono delle semplificazioni e tutti e due presuppongono che i prodotti di Microsoft non siano abbastanza validi per alcun ambito e vedono Microsoft solo come bianco e nero nella tipica mentalità della lotta "noi contro loro". Questo spiega perché il movimento open source ha come potenti alleati le comunità OS/2 e Macintosh: entrambe sono basate su modelli chiusi e proprietari, non molto differenti da quello di Windows, ma con alle spalle forti gruppi i quali hanno anch'essi come base la mentalità ABM/BTM.
Come ogni percorso politico, anche quello che si basa sul concetto ABM/BTM, seppur semplice, attrae molte persone, ma ancora più importante, è accettato da certi elementi della dirigenza di grosse aziende, come Intel, IBM e praticamente tutti i produttori di computer. Considerando le licenze pagate da Compaq, Gateway ed altri a Microsoft, potete iniziare a capire come mai vi siano in queste aziente programmatori che collaborano (a volte in segreto) allo sviluppo di Linux con il pieno supporto dei "piani alti". Dal punto di vista politico, alcuni paragonano Microsoft alla IBM degli anni '70: questo dà un certo incentivo ad opporsi ad essa.
Fra i fornitori di connettività c'è la paura che Microsoft ottenga il controllo della rete sfruttando la propria influenza presso la dirigenza delle grandi aziende. I grandi provider sono preoccupati da una politica basata su licenze costose e restrittive. Essi percepiscono Microsoft come una minaccia ("il lato oscuro della forza") che cerca di imbrigliarli. Il documento cWare White Paper è stato il primo a descrivere Microsoft come una forza aggregante per il movimento open source:
"Nei primi tempi di internet c'era l'egemonia di IBM e dei mainframe, oggi c'è quella di Microsoft. Come la Riforma rese alleati specifici gruppi prima avversari (come Lutero e i principi tedeschi), la rete diede voce ai singoli ed ai gruppi in precedenza esclusi dalla ricca tecnocrazia sostenitrice di IBM ed a sua volta sostenuta da essa. Linux è spinto dalla medesima forza. Attualmente, la maggior parte del software commerciale si concentra intorno ai prodotti di Microsoft, come una zona di bassa pressione, ma questa grande forza ed influenza disaffeziona molti per i quali gli alti costi e le licenze restrittive (una vera mancanza di libertà) impediscono un pieno e semplice accesso alle risorse informatiche. Si cercano, quindi, delle soluzioni diverse. Come per il clima, le alternative possono apparire all'improvviso ed altrettanto improvvisamente scomparire. Tipicamente è richiesta una forza sostentatrice, un'altra zona di bassa pressione. Per Lutero questo supporto fu fornito dai principi tedeschi, per i primi tempi di internet fu l'ARPA e per Linux fu la stessa comunità della rete. Nel caso di Linux, la comunità di internet necessitava disperatamente di un valido sistema operativo. AT&T aveva allontanato molti potenziali clienti con alti costi e licenze restrittive. L'università di Berkley aveva compromesso BSD rimuovendo tutto il codice proprietario che permetteva la compatibilità con il sottostante hardware: potevate studiarlo, ma non utilizzarlo! Molti vedevano come alternativa agli Unix, i quali diventavano sempre meno liberi, Minix di Andy Tanebaum, ma questo sistema operativo era incompleto, non aveva alle spalle la necessaria massa critica di sviluppatori e l'obbligo di distribuirlo solo tramite sorgenti iniziava a diventare restrittivo. Queste condizioni spinsero la comunità, inizialmente ispirata da Minix, a produrre Linux. Questo divenne presto disponibile e sempre più utilizzabile: quando si allineò con la licenza del software libero fu inserito il supporto ai potenti strumenti GNU e ad una gran quantità di hardware economico. Allora nacque un nuovo sistema operativo realmente utilizzabile. La comunità internet finalmente aveva la possibilità di avere uno Unix con grandi capacità di connettività, economico, potente e senza alcun vincolo a limitarne l'uso.
Linux apparve quasi casualmente sulla scena, ma velocemente si trasformò in una macchina bene organizzata perché aveva un avversario con il quale confrontarsi. Inoltre aveva anche dei sostenitori nella lotta.
Il "Bazaar" di Linux, quindi, non è un semplice aggregato di aziende e devoti sostenitori, motivati solamente dal mutuo riconoscimento: agisce su livelli più elevati. Quando le forze si organizzano intorno ad un gruppo dominante con politiche restrittive, una forza di reazione si genera nel resto della comunità. Nel corso del tempo questa propone diverse alternative: se una o più di esse riescono a trovare dei sostenitori (la comunità della rete, nel caso di Linux), allora un nasce nuovo "movimento", sostenuto ed addirittura arricchito dalle forze che gravitano intorno al gruppo dominante. Ironicamente, più forte diventa Microsoft, più forti diventano i suoi oppositori e più risorse ricevono movimenti come quello di Linux. Se BSD fosse stato disponibile su hardware economico in tempi precedenti, allora avrebbe potuto essere il cuore di questa tempesta.
Più tardi queste idee furono sviluppate negli Halloween papers. Sotto un certo punto di vista la IBM del passato avrebbe potuto essere considerata un'azienda basata sul modello del bazaar: non fu un grande vantaggio perché questo stile non favorisce una grande velocità di sviluppo (vedere i commenti di Jonathan Eunice).
In questo senso, con Linux, Torvalds cambiò mestiere e iniziò a vestire i panni del leader politico nello stile ABM/BTM piuttosto che di uno tecnologico, nel tentativo di promuovere la sua idea di "dominazione del mondo". Questo significa che Linux iniziò a perdere di vista l'obiettivo e acquisì una mentalità ABM/BTM tatticamente vantaggiosa, ma potenzialmente pericolosa sul lungo periodo, tutto ciò per competere con Microsoft sia in ambito desktop sia server, abbandonando il modello della comunità accademica il cui motto era "insegui il sogno, non la competizione".
L'aggiunta dell'aspetto politico aumenta lo stress ed il carico di lavoro (aumentando la tendenza allo sfinimento) sugli sviluppatori principali richiedendo tabelle di marcia ed obbiettivi irrealizzabili. Questo processo impone una mentalità militare (autocratica per definizione) che dovrebbe essere evitata il più possibile.
Appartenere alla comunità open source non garantisce nulla, non è la bacchetta magica che assicura il successo del progetto. La mortalità dei progetti open source è elevata, un gran numero di essi non raggiunge mai la magica versione 1.0. Quando vedete una pagina web che non è stata aggiornata per un anno, è indice che qualche cosa non è andata per il verso giusto. Ci sono varie motivazioni per queste estinzioni:
Voglio anche fare notare che il successo non è collegato alla superiorità di una determinata scelta tecnica. Come in campo scientifico, cambiare la visione dominante è difficile e non indolore. Variazioni più leggere e meno drammatiche sono più attraenti che grossi stravolgimenti. Questo vuole dire che gli individui, anche se dotati di molto talento, devono affrontare non solo degli ostacoli tecnici ma devono anche superare la resistenza offerta dalla comunità ad accettare delle nuove idee. Come in ambito accademico, il contatto con membri influenti della comunità e l'accesso ai centri di sviluppo principali sono molto importanti e possono ridurre notevolmente l'opposizione da affrontare per fare accettare una determinata idea. Questo fenomeno, "la tragedia del talento periferico", fu per primo affrontato dal premio nobel Pyotr Leonidovich Kapitsa: la sua analisi del lavoro di diversi fisici russi mai divulgato od accettato dalla comunità scientifica occidentale è direttamente applicabile al movimento open source.
Kapitsa capì che la vicinanza con i principali centri di ricerca e con le persone che vi lavoravano aiuta notevolmente l'accettazione di una scoperta. Una volta che una scoperta è integrata all'interno del sapere scientifico, un cambiamento dei paradigmi può avvenire.
Anche se è vero che la maggior parte degli utenti Linux non hanno le conoscenze o le motivazioni per dare il proprio contributo al sistema operativo, l'adattabilità di un programma ad un particolare utente è maggiore se il codice sorgente è disponibile, perché il codice è la migliore documentazione. La possibilità di effettuare delle modifiche è meno importante, soprattutto per un programma di una certa complessità. È semplicistico presumere che tutti gli utenti di programmi liberi siano programmatori C, che siano capaci ed abbiano voglia di correggere errori o fare modifiche al sistema operativo o ai programmi. Molti utenti usano Linux nella stessa maniera nella quale utilizzerebbero Windows, installano un distribuzione "pronta all'uso" ed poi applicano gli aggiornamenti fino a quando non è rilasciata una nuova versione più accattivante, e poi il ciclo si ripete.
Il valore della disponibilità del codice sorgente va molto oltre alla semplice possibilità di un utente di operare delle modifiche. La possibilità di avere il sorgente è una forma di protezione per il consumatore: l'utente ne beneficia anche se non sa programmare in C perché questo garantisce una maggiore possibilità di sorveglianza di un prodotto in un sistema operativo in continua evoluzione.
Bob Metcalfe, che ha espresso il suo pensiero più chiaramente, ha torto. Bryan Pfaffenberger spiega gli errori di Bob con il seguente ragionamento: per Bob il movimento open source è pari al comunismo ed egli vede per esso lo stesso fallimento per mano del capitalismo. In effetti, se ascoltate abbastanza a lungo Richard Stallman, inizierete a sentire la canzone di John Lennon "Imagine", ma io non vedo nessuna somiglianza fra il comunismo e l'open source. Questo mi ricorda l'università o, più precisamente, la lunga tradizione di creazione e condivisione del sapere che è stata la molla del grande successo della scienza occidentale.
Quando diventi ricercatore ti impegni a migliorare il mondo, ricevi una buona paga, è vero, ma non guadagni nulla dalle tue scoperte, le cedi. Pubblichi e riveli tutti i dettagli, non prendi un soldo dai giornali, anzi, alcuni di essi pretendono che l'autore paghi le spese di pubblicazione!
Cosa si ottiene in cambio? Ci sono tante motivazioni diverse quanti sono gli scienziati. Alcuni sono curiosi, non riescono a smettere di pensare a come mai i bracci della Via Lattea formano quelle grandi ed eleganti spirali. Altri sono dei bambinoni che non vedono l'ora di entrare in laboratorio per un'altra appassionante giornata di divertimento. Altri ancora sono molto attenti al valore ed al significato della scienza. In una recente serie di convegni il fisico Freeman Dyson ha rivelato la sua motivazione, una missione per capire come la scienza e la tecnologia potrebbero contribuire alla giustizia sociale, l'eliminazione della povertà e la conservazione dell'ecosistema terrestre.
Non ho mai sentito nessuno definire la scienza "comunismo", non ha niente a che fare con il comunismo: infatti ai comunisti non piacciono molto gli scienziati, sono troppo difficili da controllare e tengono troppo alla verità.
Gli scienziati universitari non sono le uniche persone a compiere ricerche: molte aziende investono in ricerca e sviluppo ma i risultati spiegano bene la differenza. La conoscenza delle aziende non è diffusa a meno che non porti qualche beneficio alla ditta. Questo è comprensibile, ma abbiamo bisogno di un'alternativa. Nella più capitalista fra tutte le nazioni, gli Stati Uniti d'America, il Congresso stanzia investimenti pubblici nelle ricerche universitarie, nella creazione di conoscenza aperta a tutti, incluse le compagnie a scopo di lucro. Questo non è comunismo, è buon senso.
Questo cosa c'entra con il software? Molto: la tecnologia informatica è parzialmente responsabile del più lungo periodo di sviluppo sostenuto nella storia degli Stati Uniti. Ha aiutato ad imporre la superiorità economica, tecnologica e politica in questo mondo pericoloso e frammentato. Ci promette di aiutarci nel risolvere il problema attualmente più urgente: la creazione di una fonte di abbondante energia pulita, di sconfiggere la fame nel mondo, di svelare il mistero del cancro. È vitale che la conoscenza informatica rimanga di pubblico dominio, ma non è ciò che sta accadendo. Attualmente le aziende del settore stanno facendo a gara per brevettare anche la più piccola stringa di codice ed il miope ufficio dei brevetti statunitense sta accettando tutto. Sistemi informatici che sono vitali per la sicurezza ed il benessere della popolazione sono gestiti da programmi commerciali e chiusi, carichi di errori sconosciuti. Ricordate lo USS Norfolk, rimasto fermo per due ore in immersione a causa di un blocco dei suoi sistemi di bordo gestiti da Windows NT, ed avrete un'idea della situazione.
Il movimento Open Source non riuscirà a scalzare il software commerciale, almeno fino a quando non riuscirà a proporsi come una valida alternativa. Il software è troppo importante per lasciarlo in mano ad aziende a scopo di lucro, deve esserci un bilanciamento fra il sapere pubblicamente disponibile e quello in mano alle aziende, e il software open source sta mostrando la strada giusta.
Se state ancora pensando che questa sia una visione utopica, andate a parlare con gli alunni di una scuola messicana: senza conoscenze informatiche non avrebbero nessuna possibilità nel mondo della globalizzazione. Grazie a GNOME, un'interfaccia grafica libera per Linux, il governo messicano risparmia 124 milioni di dollari americani, che altrimenti sarebbero andati ad ingrassare le casse di Microsoft, e li sta investendo in computer. Chiamatelo comunismo se vi fa piacere: io lo chiamo progresso.
L'open source, essenzialmente, fornisce un'alternativa che uno può accettare o rifiutare.
Anche se assumessimo, sbagliando, che ci sia una forte connessione fra l'open source ed il marxismo, le cose non sarebbero così negative perché il marxismo comprende un ampio spettro di movimenti politici che include anche i partiti social-democratici occidentali. Supponiamo che il percorso scelto per l'open source non sia altro che un tipo di marxismo applicato al software: questo non è vero, Metcalfe sbaglia completamente equiparando le due filosofie. Comunque ci sono molti punti di contatto fra la visione marxista e quella open source. Supponiamo, quindi, che Metcalfe abbia ragione: cosa significherebbe? Prima di tutto c'è una grande differenza fra la teoria del comunismo (chiamata marxismo) e la pratica del comunismo. I social-democratici occidentali, il bolscevismo russo (leninismo) ed il maoismo cinese sono tutti diversi. Il marxismo era una visione utopica creata da Karl Marx ed i suoi seguaci. La componente principale di questa visione era che le aziende dovessero appartenere alle persone che vi lavoravano: il sistema più semplice per eliminare l'inutile zavorra rappresentata dai padroni e dai dirigenti era l'eguale distribuzione della ricchezza fra i lavoratori. Questo obbiettivo potrebbe essere raggiunto tramite una rivoluzione che retrocedesse i proprietari al ruolo di lavoratori. Versioni modificate e moderate di questa teoria sono ora parte di molti degli stati più avanzati: le versioni più radicali sono rappresentate dal bolscevismo russo e dal maoismo cinese. Ognuno di essi è diverso dal modello teorico proposto da Marx e tutti lo sono leggermente da ognuno degli altri. Alcuni hanno avuto successo, altri no . Le stesse differenze si stanno presentando nel mondo open source, come il movimento social-democratico: la parte moderata, rappresentata dal creatore del Perl Larry Wall e supportata dalla O'Reilly, RedHat e molte altre aziende, ha l'inerzia maggiore. Come i partiti social-democratici occidentali, probabilmente la parte moderata vincerà, ma il futuro è imperscrutabile per definizione.
Il primo problema con questa affermazione è quello di considerare generalmente buona la qualità dei prodotti commerciali. Niente di più lontano dalla verità. Ecco alcuni commenti abbastanza tipici a proposito della qualità del supporto tecnico commerciale:
"Avete provato a richiedere supporto tecnico recentemente? Io sì. Posso riassumere la qualità del servizio in due parole: fa schifo. Non importa se lo paghi oppure se è parte del contratto di garanzia del prodotto, fa schifo."
Jesse Berst descrive la situazione così:
"Molte aziende molto importanti stanno tagliando le spese per il supporto ai clienti, come ha fatto recentemente la Gateway (anche se dice che dei tagli ne beneficeranno i clienti. Sì, come no!). Per saperne di più.
La situazione potrà solamente peggiorare, mi spiace dirlo. Nella veloce economia di internet di oggi, i produttori immettono sul mercato prodotti con pochissimo controllo della qualità, aumentando le probabilità che sia necessario del supporto tecnico. Poiché, inoltre, spesso sono obbligati a regalare i propri prodotti, non hanno le risorse per mantenere un buon supporto al cliente. La situazione è così brutta che molte aziende offrono aiuto a pagamento. Anche Wal-Mart fornisce supporto tecnico in alcuni dei suoi negozi."
Essenzialmente abbiamo la stessa situazione del modello di supporto open source. Probabilmente la cosa potrebbe essere ancora più importante, perché se vediamo la chiusura dei servizi di supporto interni alle ditte come una scelta cosciente, allora la posizione del modello open source è ancora migliore.
L'esistenza di uno standard può essere un importante vantaggio per i progetti distribuiti basati sulla rete. Sembra che Vinod Valloppillil abbia notato questo fattore nel famoso documento Halloween I:
"...i protocolli stanno diventando il collante dei progetti open source. C'è una gran quantità di lavoro nei gruppi della IETF che permette di creare dei modelli da integrare nei progetti open source."
I progetti open source non sono completamente dipendenti dagli standard. Le aziende hanno il vantaggio di potere concentrare gli sviluppatori in un unico posto e potergli fornire fondi e strumenti, ma hanno anche un grande svantaggio: i software liberi possono permettersi di essere più semplici dei tradizionali progetti commerciali perché la complessità è un vantaggio delle aziende. Una società cercherà di produrre una soluzione complessa per potere mantenere il suo margine di vantaggio. Questo idea fu probabilmente introdotta per la prima volta nella desemplificazione dei protocolli:
"Perché il software proprietario sia redditizio deve creare dei vantaggi. Un programma semplice che faccia semplicemente ciò che deve, quindi, ha un grande difetto: un concorrente può imitarlo. Considerando l'estremamente basso costo marginale del software, si arriva ad un prezzo molto vicino allo zero. Tutti i programmi realmente redditizi, quindi, hanno delle complessità intrinseche volute per scoraggiare i concorrenti."
Il movimento open source sta giocando un ruolo importante e vitale nello sviluppo software alla fine del ventesimo secolo e continuerà ad essere un importante polo di creatività nel secolo successivo. Nonostante le capacità tecniche e la fantasia dei suoi membri, però, vi sono delle limitazioni nel modello open source che devono essere attentamente studiate e corrette. Queste limitazioni riguardano gli aspetti umani che rendono la scienza in generale e quella applicata in particolare delle attività complesse. Questo articolo evidenzia gli importanti vantaggi che l'open source ha sul software commerciale e la possibilità di creare prodotti semplici che sono superiori a quelli commerciali in termini di funzionalità ed interfaccia utente. Il famoso principio KISS (Keep It Simple Stupid, ovvero "mantienilo semplice, stupido") è più facilmente applicabile ai progetti open source che non a quelli commerciali. La seconda idea è che la velocità di sviluppo non è necessariamente un vantaggio nel modello open source ed alcune volte rallentare è una possibile strategia che dovrebbe essere presa in considerazione insieme alle altre. Una corsa contro i prodotti commerciali potrebbe essere auto-distruttiva: è pericoloso credere che il movimento open source sia esente da difetti, ignorando la storia della scienza applicata e di cinquant'anni di sviluppo software. Aspettarsi l'impossibile ed ignorare l'importante lezione della storia e le limitazioni del modello open source potrebbe rendere interessanti progetti una semplice e curiosa nota a piè di pagina nella storia dell'informatica.
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 traduttorePietro 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 e Perl. Altri hobby: storia militare, strategia, Giochi di Ruolo e lettura. |
|
|
<- Software libero per il trattamento di problemi scientifici - Indice Generale - Copertina - Personaggi e avvenimenti -> |
|
