Indice
La maggioranza dei progetti di software libero fallisce.
Noi tendiamo a non dare molto ascolto alla notizia di questi fallimenti. Solo i progetti che hanno successo attraggono l'attenzione e ci sono tanti progetti di software libero in totale[2] che, anche se solo una piccola percentuale di essi ha successo il risultato è che a noi appare essere tuttavia una gran quantità. Inoltre noi non abbiamo notizia dei fallimenti perchè i fallimenti non fanno notizia. Non c'è un particolare momento in cui il progetto cessa di essere praticabile. La gente semplicemente sceglie di allontanarsene. Ci può essere un momento in cui un cambiamento finale viene fatto nel progetto, ma quelli che lo hanno fatto generalmente non sanno che quel cambiamento è l'ultimo. Non è facile stabilire quando il progetto si è esaurito. Quando non è stato lavorato per sei mesi? Quando la base di utilizzatori ha smesso di crescere senza aver superato la base di sviluppatori? E se gli sviluppatori di un progetto lo abbandonano perchè si rendono conto che stanno duplicando il lavoro di un altro?—e se essi si uniscono a quell'altro progetto dunque lo espandono per immettervi molto del loro sforzo primitivo? Il progetto precedente è finito o ha semplicemente cambiato casa?
A causa di una tale complessità è impossibile stabilire il numero dei fallimenti. Ma una evidenza annedotica da più di un decennio di open source, qualche ricerca su SourceForge.net e un piccolo googling tutti puntano alla stessa conclusione: il numero è estremamente alto, probabilmente dell'ordine del 90–95%. Il numero sale se includete i progetti che sopravvivono ma son disfunzionali: quelli che stanno producendo codice che gira ma che non hanno motivo di esistere, o che non stanno progredendo così velocemente o così affidabilmente come dovrebbero.
Questo libro parla di come evitare i fallimenti. Esso esamina non solo come fare le cose bene ma come farle sbagliate in modo che voi possiate riconoscere e correggere gli errori piuttosto in anticipo. La mia speranza è che dopo averlo letto voi abbiate un repertorio di tecniche non tanto per evitare i trabocchetti dello sviluppo open source quanto per operare per la crescita e la manutenzione di un progetto di successo. Successo non è un gioco senza perdite e questo libro non parla di come vincere o farsi strada nella competizione. Indubbiamente una importante parte dei progetti open source che girano sta funzionando regolarmente con altri progetti simili. Nel lungo periodo ogni progetto che ha successo contribuisce allo stato di benessere dell'insieme complessivo del software libero nel web.
Si sarebbe tentati di dire che i progetti di software libero falliscono per lo stesso tipo di motivi del software proprietario. Certamente il software libero non non è il solo a trovarsi di fronte a presupposti non realistici, specifiche vage, non buona amministrazione di risorse, non adeguata fase di progetto o alcuni degli altri spauracchi ben noti all'industria del software. C'è una enorme quantità di cose scritte su questi argomenti, e non tenterò di ripeterle in questo libro. Invece tenterò di descrivere i problemi peculiari del software libero. Quando i progetti di software libero vanno in secca ciò avviene perchè gli sviluppatori (o gli organizzatori) non si sono resi conto dei problemi peculiari dello sviluppo open source anche se essi possono essere ben consci delle meglio note difficoltà dello sviluppo closed source.
Uno dei più comuni errori è l'aspettativa circa i benefici dell'open source stesso. Una licenza open source non garantisce il fatto che orde di sviluppatori mettano subito a disposizione i loro tempo per il vostro progetto, nè l'open sourcing cura automaticamente i mali di un progetto che dà problemi. Di fatto è proprio l'opposto: l'aprire un progetto può aggiungere una serie di complessità, e costa nel breve periodo più che non mantenendolo chiuso. Aprirlo significa adattare il codice per renderlo comprensibile a persone completamente nuove, metter su un sito di sviluppo e liste email e spesso scrivere documentazione per la prima volta. Tutto ciò costa molto lavoro E certamente se alcuni sviluppatori interessati lo aprono c'è il carico aggiuntivo di rispondere alle domande dei nuovi arrivati per un certo tempo prima di vedere i benefici della loro presenza. Come sviluppatore Jamie Zawinski sui primi giorni del progetto Mozilla disse:
L'open source funziona ma non è del tutto certo che sia una panacea. Se c'è una diceria che mette in guardia qui è che tu non puoi prendere un progetto che sta morendo, cospargerlo con la magica polvere dell'open source e ottenere che ogni cosa funzioni. Il software è difficile. I problemi non sono così semplici
Un errore correlato è quello di essere avari nella presentazione e nel confezionamento della relativa applicazione. La presentazione e il confezionamento dell'applicazione relativa richiedono una larga serie di compiti che girano tutti intorno al tema di ridurre la difficoltà di chi entra nel progetto. Rendere il progetto invitante per i non iniziati significa scrivere un documentazione per l'utente e per lo sviluppatore, metter su un sito che sia di informazione per i nuovi arrivati, automatizzare la compilazione e l'installazione quanto più sia possibile, ecc. Molti programmatori purtroppo trattano questo compito come se fosse secondario rispetto alla scrittura del codice. C'è una duplice ragione perchè questo avviene: in primo luogo questo può essere percepito come un lavoro di poco conto perchè i suoi benefici sono più visibili a coloro che hanno meno familiarità col progetto e viceversa. Dopotutto, coloro che sviluppano il progetto non hanno bisogno dell'applicazione relativa. Essi sanno già come installare, gestire e usare il software perchè lo hanno scritto. In secondo luogo le abilità richieste per fare una presentazione e confezionare la relativa applicazione sono spesso completamente differenti da quelle richieste per scrivere codice. Le persone tendono a focalizzarsi su ciò in cui essi sono brave anche se potrebbe servire di più al progetto spendere tempo su ciò a cui esse sono meno adatte. Capitolo 2, Partenza discute in dettaglio sulla presentazione e sul confezionamento dell'applicazione e spiega perchè è cruciale che essi abbiano la priorità in una una corretta partenza del progetto.
Poi viene la credenza errata che in un progetto open source occorra un una piccola o nessuna organizzazione o al contrario che funzionerà la stessa organizzazione di un progetto non aperto. L'organizzazione in un progetto open source non è sempre visibile, eccetto che nei progetti di successo, usualmente avviene dietro le quinte in una forma o nell'altra. Un esperimento in apparenza insignificante è sufficiente a mostrare come. Un progetto open source è fatto di un numero casuale di programmatori—una già nota categoria di liberi pensatori—che molto verosimilmente non si sono mai incontrati e che possono avere differenti obbiettivi nel lavorare al progetto. L'esperimento pensato consiste nell'immaginare cosa succederebbe ad un simile gruppo senza una organizzazione. A meno di un miracolo fallirebbe o scomparirebbe dalla vista molto rapidamente. Le cose semplicemente non girerebbero da se, per quanto noi vorremmo altrimenti. Ma l'organizzazione malgrado possa essere alquanto attiva è spesso irregolare, scarsa, riservata. La sola cosa che tiene unito un gruppo di sviluppatori è il pensiero condiviso che si possa fare di più in concerto che non individualmente. Così l'obiettivo dell'organizzazione è sopratutto assicurarsi che essi continuino a pensare questo, stabilendo standards di comunicazione, rendendo sicuramente utile che gli sviluppatori non siano emarginati a causa di peculiarità di comportamento, e in generale facendo in modo che per gli sviluppatori il progetto sia un luogo dove ritornare. Tecniche specifiche per far ciò sono discusse per il resto di questo libro.
Infine c'è una categoria generica di problemi che può essere chiamata "fallimenti della navigazione culturale" Dieci anni fa, anche cinque, sarebbe stato prematuro parlare di cultura globale del software libero, ma ora non più. Una cultura riconoscibile è lentamente emersa e mentre essa è certamente non monolitica è per lo meno soggetta al dissenso alla faziosità come una cultura geograficamente chiusa—essa ha un consistente nocciolo di base. Molti progetti di successo mostrano alcune o tutte le caratteristiche di questo nocciolo. Essi premiano certi tipi di comportamento e ne puniscono altri; essi creano un'atmosfera che incoraggia una partecipazione non pianificata, a volte a spese di un coordinamento centrale; essi hanno concetti di rudezza e garbo che possono differire sostanzialmente da quelli che prevalgono altrove. Ciò che è molto importante è il fatto che partecipanti veterani hanno fatto propri questi comportamenti, dimodochè hanno in comune un forte consenso sul comportamento previsto. I progetti che falliscono deviano in modo significativo da questo nocciolo, sebbene senza intenzione, e spesso non hanno l'unanimità su ciò che costituisce un comportamento ragionevole non predefinito. Ciò significa che quando insorgono problemi la situazione può rapidamente deteriorarsi, giacchè i partecipanti non hanno quell'insieme di riflessi culturali per aiutarsi a risolvere i dissensi.
Questo libro è una guida pratica, non uno studio antropologico o una storia. In tutti i casi una valida conoscenza dell'odierna cultura del software libero è un fondamento essenziale per ogni consiglio pratico. Una persona che comprende la cultura può viaggiare in lungo e in largo per il mondo dell'open source, incontrando molte varianti in abitudini e linguaggi, sarà sempre capace di partecipare effettivamente e con agio ovunque. Invece una persona che non comprende la cultura troverà il processo dell'organizzazione e della partecipazione difficile e pieno di sorprese. Siccome il numero di persone che sviluppano software libero è sempre in crescita a balzi e rimbalzi c'è sempre gente in questa seconda categoria— questa è in maniera preponderante la cultura dei nuovi arrivati e le cose continueranno ad essere tali per qualche tempo. Se voi pensate di poter essere fra questi la prossima sezione dà le basi per discutere cose che incontrerete più tardi sia in questo libro sia in Internet. (Se invece avete lavorato con l'open source per un certo tempo forse conoscete molto della sua storia e di conseguenza vi sentirete liberi di saltare questa sezione).
La condivisione del software è esistita da quando è esistito il software . Nei primi giorni dei computers i costruttori vedevano che risultati positivi nella competizione si erano avuti principalmente nell'innovazione dell'hardware e quindi non dedicarono attenzione al software come risorsa commerciale. Molti dei primi clienti che usavano queste macchine erano scienziati o tecnici che avevano l'abilità di modificare e ampliare il software inviato con la macchina. I clienti a volte distribuirono le modifiche non solo ai costruttori ma anche agli altri possessori di macchine simili. I costruttori spesso tollerarono e incoraggiarono ciò: ai loro occhi miglioramenti al software di qualunque origine rendevano la macchina più allettante per gli altri potenziali acquirenti.
Anche se questo periodo iniziale somigliava all'attuale cultura del software libero per diverse ragioni, differiva per due principali aspetti. Uno, c'era già una certa standardizzazione dell'hardware; era il tempo di una fiorente innovazione nel progetto dei computers, ma la diversità nelle architetture di calcolo voleva dire che ogni cosa era diversa da ogni altra. Cosicchè il software scritto per una macchina non avrebbe funzionato con un'altra. I programmatori si orientarono ad acquisire abilità con una certa architettura o famiglia di architettura (laddove oggi essi sarebbero più propensi ad acquistare esperienza in un linguaggio di programmazione o famiglia di linguaggio confidando nel fatto che la propria esperienza sarebbe trasferibile a qualsiasi hardware di calcolo a cui a loro capiti di lavorare). Poiché l'esperienza di una persona tendeva a essere specifica di un tipo di computer la loro accumulazione di esperienza fece sì che fosse preferibile a sè e ai suoi colleghi quel computer. Ci fu quindi da parte dei costruttori l'interesse a che si estendesse quanto più possibile il codice e la conoscenza della macchina.
Due, non c'era Internet. Sebbene ci fossero minori restrizioni legali sulla condivisione rispetto ad oggi i limiti erano più di carattere tecnico. I mezzi per spostare dati da un posto all'altro erano sconvenienti e scomodi, relativamente parlando. C'era qualche piccolo network buono per scambiare informazione fra coloro che erano impiegati in una stessa ricerca o compagnia. Ma rimanevano barriere da superare si si voleva scambiare con chiunque, ovunque fosse. Queste barriere furono superate in molti casi. A volte differenti gruppi stabilirono reciproci contatti autonomamente inviando dischi o nastri tramite posta terrestre e a volte i costruttori stessi servirono come centrali di scambio per le modifiche. Fu di aiuto anche il fatto che molti dei primi sviluppatori lavoravano alle università dove era previsto che uno pubblicasse le sue conoscenze. Ma la realtà fisica della trasmissione dati diceva che c'era sempre un impedimento alla condivisione, un impedimento proporzionale al tratto (fisico o organizzativo) che il software doveva percorrere. Una condivisione larga e priva di attriti, come la conosciamo oggi era impossibile.
Come conseguenza del fatto che l'industria maturava avvennero molti cambiamenti. La grande varietà del software prodotto diede strada ai pochi chiari vincitori—vincitori per la tecnologia superiore, per una organizzazione commerciale superiore, o una combinazione delle due cose. Allo stesso tempo, e non completamente in simultaneità, lo sviluppo dei cosiddetti linguaggi di “alto livello” volle dire che uno avrebbe potuto scrivere un programma una volta sola in un unico linguaggio e ottenere che esso fosse tradotto (“compilato”) in modo da poter girare su differenti tipi di computer. Le implicazioni di ciò non furono perse dai costruttori di hardware. Il cliente così poteva dedicarsi a un impegno maggiore nello sviluppo del software senza necessariamente limitarsi a farlo in relazione a una specifica architettura. Quando ciò si combinò con una graduale diminuzione delle differenze di prestazione dei vari computers man mano che i progetti meno efficienti furono fatti fuori un costruttore che considerasse il suo hardware come sua unica risorsa poteva prevedere un futuro di margini di guadagno in diminuzione. Da sola la potenza di calcolo stava diventando un bene commerciale e il software faceva la differenza. Vendere software o almeno trattarlo come parte della vendita di hardware cominciò a sembrare una buona strategia.
Ciò significò che i costruttori dovettero incominciare a rafforzare i diritti d'autore sul loro codice in maniera più rigorosa. Se gli utilizzatori avessero continuato a scambiarsi il codice e a condividene i cambiamenti liberamente, essi avrebbero potuto reimplementare alcuni dei miglioramenti ora venduti come “valore aggiunto” dal fornitore. Peggio, il codice condiviso avrebbe potuto finire nella mani dei concorrenti. L'ironia è che questo stava succedendo nel tempo che Internet stava emergendo. Proprio quando il software veramente non impedito stava finalmente diventando tecnicamente possibile, i cambiamenti nell'affare dei computers lo rendeva indesiderabile almeno dal punto di vista di ogni singola compagnia. I fornitori misero un freno sia negando l'accesso agli utilizzatori al codice che girava sulle proprie macchine sia insistendo su un accordo di non apertura che rende il codice condivisibile.
Mentre il mondo del codice libero perdeva colore lentamente una reazione prendeva forma nella mente di almeno un programmatore. Richard Stallman aveva lavorato nell' Artificial Intelligence Lab al Massachusetts Institute of Technology negli anni 70 e nei primi anni 80 periodo che si rivelò essere un periodo d'oro e il luogo un luogo d'oro per la condivisione del codice. L'Artificial Intelligence Lab aveva una forte “etica hacker”,[3] e la gente non solo era incoraggiata ma voleva fortemente condividere ogni miglioramento avesse apportato al sistema. Come Stallman scrisse poi:
Noi non chiamavamo il nostro software software libero perchè quel termine non esisteva ancora; ma quello era. Quando persone di un'altra università o compagnia volevano trasferire su un'altra piattaforma e usare un programma noi eravamo contenti di permetterglielo. Se voi aveste visto uno usare un programma non familiare ed interessante avreste potuto sempre chiedere di vedere il codice sorgente in modo da poterlo leggere, cambiarlo o usare parti di esso per costruire un altro programma.
Questa comunità da paradiso terrestre si esaurì intorno a Stallmann bruscamente dopo il 1980 quando i cambiamenti che erano avvenuti nel resto dell'industria raggiunsero alla fine anche l'Artificial Intelligence Lab. Una nuova compagnia impiegò molti programmatori del Lab per farli lavorare a un sistema operativo simile a quello su cui avevano lavorato nel Lab, ora solamente sotto una licenza esclusiva. Contemporaneamente l' l'Artificial Intelligence Lab acquistò una nuova apparecchiatura che mise a disposizione di un nuovo sistema operativo proprietario.
Stallmann tracciò un chiaro saggio di quello che stava accadendo:
I moderni computers dell'epoca come il VAX o il 68020 avevano i loro sistemi operativi ma nessuno dei due era software libero: tu dovevi firmare un accordo di non rivelazione persino per prendere una copia dell'eseguibile.
Ciò significava che la prima cosa nell'usare un computer era quella di non aiutare il tuo vicino. Una comunità operativa era proibita. La regola stabilita dai proprietari del software era “Se tu condividi col vicino sei un pirata. Se tu vuoi un cambiamento chiedi umilmente a noi.”
Per qualche bizzarria nel carattere lui decise di resistere alla tendenza. Invece di continuare a lavorare presso l'ora decimato Lab o di prendere lavoro come scrittore di codice presso una delle nuove compagnie dove i risultati di questo lavoro sarebbero stati tenuti chiusi in una scatola si licenziò dal Lab e iniziò il progetto GNU dando il via alla Free Software Foundation (FSF). Lo scopo del GNU [4] era quello di sviluppare un sistema operativo completamente libero e parte principale di software applicativo al quale a coloro che lo usavano non sarebbe stato impedito di accedere e di condividerne le modifiche. Egli stava in sostanza rimettendo in piedi ciò che era stato distrutto dall'Artificial Intelligence Lab ma in una scala mondiale e senza quella vulnerabilità che aveva reso la cultura dell'Artificial Intelligence Lab suscettibile di disintegrazione.
Oltre a lavorare al nuovo sistema operativo Stallman lasciò in eredità una licenza di copyright i cui termini garantivano che il suo codice sarebbe stato libero per sempre. La The GNU General Public License (GPL) è un pezzo geniale di judo legale: essa dice che il codice può essere copiato e modificato senza restrizioni e che le copie e i lavori derivati (cioè le versioni modificate) devono essere distribuite sotto la stessa licenza originale senza nessuna restrizione aggiuntiva. Nei fatti essa usa la legge sul copyright per raggiungere l'effetto opposto di quello del copyright tradizionale: invece di limitare la distribuzione del software faceva in modo che nessuno, compreso l'autore, potesse limitarla. Per Stallman questo era meglio che porre semplicemente il suo codice sotto pubblico dominio. Se esso fosse stato di pubblico dominio una copia particolare avrebbe potuto essere incorporata in un software proprietario come si era anche appreso avvenire sotto licenze di copyright permissive. Mentre tale incorporazione non avrebbe potuto compromettere in nessun modo la continua disponibilità del codice, avrebbe potuto avere il significato che gli sforzi di Stallman avrebbero potuto beneficiare il nemico software proprietario. La GPL può essere pensata come una forma di protezionismo per il software libero perchè impedisce al software proprietario di trarre pieno vantaggio dal codice GPL. La GPL e le sue relazioni con le altre licenze libere è discussa in dettaglio in Capitolo 9, Licenze, Diritti d'Autore e Brevetti.
Con l'aiuto di molti programmatori, molti dei quali condividevano le idee di Stallman e alcuni dei quali volevano semplicemente vedere una gran quantità di software libero, il progetto GNU incominciò a rilasciare molti ricambi dei componenti più critici di un sistema operativo. A causa della ora assai diffusa standardizzazione nell'hardware e nel software dei computers fu possibile usare i ricambi GNU su sistemi per il resto non liberi. E molti lo fecero. L'editor di testi GNU (Emacs) e il compilatore C (GCC) ebbero particolare successo guadagnando seguaci numerosi e fedeli, non per le loro origini ideologiche ma semplicemente per il loro meriti tecnici. Dal 1990 circa GNU ha prodotto molti sistemi operativi, eccetto il kernel—la parte che attualmente avvia la macchina e che è responsabile della memoria operativa, dei dischi e di altre risorse di sistema.
Sfortunatamente il progetto GNU aveva scelto un progetto di kernel che si dimostrò essere più difficile da implementare di quanto ci si fosse aspettato. Il ritardo che ne risultò impedì alla Free Software Foundation di creare la prima release di un intero sistema operativo libero. Il pezzo finale fu invece messo a punto da uno studente finlandese della scienza dei computers che con l'aiuto di volontari per il mondo aveva completato un kernel libero usando un progetto più tradizionale. Lo chiamò Linux e quando questo fu combinato con i programmi GNU esistenti il risultato fu un sistema operativo completamente libero. Per la prima volta si sarebbe potuto avviare un computer e lavorare senza alcuno dei software proprietari. [5]
Molto software su questo sistema operativo non fu prodotto dal progetto GNU. Infatti GNU non era nemmeno l'unico gruppo che lavorava ad un sistema operativo libero (per esempio il codice che alla fine diventò NetBSD e FreeBSD era già in sviluppo in questo periodo). L'importanza della Free Software Foundation stava non solo nel codice che essi scrivevano ma nella loro retorica politica. Col parlare del software libero come un ideale anzichè come una convenienza essi resero difficile per i programmatori non avere una consapevolezza di ciò. Persino quelli che si dissociarono dalla Free Software Foundation ebbero da affrontare il problema, se prendere esclusivamente una posizione differente. L'efficacia della propaganda della Free Software Foundation poggiò sull'associare il suo codice a un messaggio per mezzo della GPL e di altri testi. Il suo messaggio si diffuse alla stessa maniera in cui si diffuse il suo codice.
C'erano molte altre cose che stavano succedendo sulla scena del software libero e poche erano tanto esplicitamente ideologiche quanto il progetto GNU di Stallman. Una delle più importanti era la la Berkeley Software Distribution (BSD), una reimplementazione graduale del sistema operativo Unix—che fino agli ultimi anni '70 era stato un vago progetto di ricerca all' AT&T—da programmatori dell'Università della California a Berkley. Il gruppo del BSD non fece nessuna dichiarazione per unirsi e condividere ma praticò l'idea con predisposizione ed entusiasmo col coordinamento di un massiccio impegno di sviluppo distribuito in cui le utility command line di Unix e le librerie di codice e lo stesso kernel del sistema operativo furono riscritti da un abbozzo per lo più da volontari. Il progetto BSD divenne un primo esempio di sviluppo di software libero non ideologico e servì anche come base di addestramento per molti sviluppatori che avrebbero voluto andare avanti per rimanere attivi nel mondo dell'open source.
Un'altra dura prova per lo sviluppo cooperativo fu il X Window System, un ambiente grafico di calcolo condiviso in rete sviluppato al MIT nella metà degli anni '80 in partnership coi venditori di hardware che avevano il comune interesse di poter offrire ai loro clienti un sistema a finestre. Lontano dal contrastare il software proprietario, la licenza X permetteva aggiunte proprietarie in cima a un corpo libero—ogni membro del consorzio voleva la chance di aumentare la distribuzione X di default e quindi di trarre un vantaggio nella competizione con gli altri membri. X Windows[6] di per sé era software libero ma principalmente per spianare il campo di gioco a interessi commerciali in concorrenza, non senza un qualche desiderio di porre fine al dominio del software proprietario. Ancora un altro esempio che anticipò il GNU project di alcuni anni fu TeX, sistema libero di tipocomposizione della qualità di pubblicazione di Donald Knuth. Egli la rilasciò sotto una licenza che permetteva a chiunque di modificare e distribuire il codice, ma non sotto il nome di “TeX” a meno che non avesse superato una molto rigorosa serie di tests di compatibilità (questo è un esempio della classe di licenze "a protezione del marchio" di cui si parla ancora in Capitolo 9, Licenze, Diritti d'Autore e Brevetti). Knut non stava prendendo una posizione o l'altra sul problema software libero o software proprietario, egli voleva solo un sistema di tipocomposizione per completare il suo reale compito—un libro sulla programmazione—e non vide nessuna ragione per non rilasciare il suo sistema a cose finite.
Senza enumerare ogni progetto e ogni licenza si può dire di sicuro che dagli ultimi '80 ci fu molto software libero disponibile sotto una grande varietà di licenze. La diversità delle licenze rifletteva la diversità delle motivazioni. Anche alcuni dei programmatori che avevano scelto la GNU GPL erano molto meno spinti da motivi ideologici di quanto lo fosse il GNU project. Anche se erano contenti di lavorare al software libero molti sviluppatori non consideravano il software proprietario un male sociale. Ci fu gente che sentì l'impulso morale di liberare il mondo del "software hoarding" (termine di Stallman per software non libero) ma altri erano motivati più da sollecitazioni tecniche o dal piacere di lavorare con collaboratori della stessa opinione o persino da un un semplice umano desiderio di gloria. Eppure tutto sommato queste disparate motivazioni non interagirono in modo distruttivo. Ciò è dovuto in parte al fatto che il software, a differenza della altre forme creative come la prosa o le arti visive, deve superare dei tests per metà oggettivi per essere considerato di successo. Ciò dà a tutti i partecipanti a un progetto una specie di automatica base comune, una ragione e una struttura per lavorare insieme senza tanta preoccupazione di qualificazioni oltre quella tecnica.
Gli sviluppatori ebbero un'altra ragione per unirsi. Risultò che il mondo del software libero stava producendo qualche codice di alta qualità. In alcuni casi esso era in modo dimostrabile tecnicamente superiore all'alternativa non libera. In altri esso era almeno comparabile e certamente costava meno. Mentre solo alcuni erano motivati a far girare sul computer il software libero per motivi strettamente filosofici, una grande quantità di persone era contenta di farlo perchè svolgeva meglio un compito. E quelli che lo usavano erano spesso intenzionati a spendere tempo e mettere a disposizione capacità per rendersi utili a svolgere compiti di manutenzione e miglioramento del software.
Questa tendenza a produrre buon codice non era universale ma si stava affermando con crescente frequenza in progetti di software libero in giro per il mondo. Imprese che trattavano principalmente software incominciarono gradualmente ad averne notizia. Molte di esse scoprirono che stavano già usando software libero nelle operazioni giornaliere solo che semplicemente non lo avevano saputo (la parte superiore dell'organizzazione spesso non è a conoscenza di ciò che il dipartimento IT fa). Le grandi imprese incominciarono ad assumere un ruolo sempre più attivo nei progetti di software libero, contribuendo con tempo e mezzi e a volte persino finanziando lo sviluppo di programmi liberi. Tali investimenti nel migliore degli scenari avrebbero potuto ripagarli molte volte di seguito. Lo sponsor paga solo un piccolo numero di programmatori esperti affinchè essi si dedichino al progetto a tempo pieno ma raccoglie i benefici del contributo di ognuno incluso il lavoro non pagato dei volontari e dei programmatori pagati da altre grandi imprese.
Nella misura in cui le grosse imprese guardavano con sempre più attenzione al software libero i programmatori erano messi di fronte ai nuovi problemi della presentazione. Uno era la parola “free” in se stessa. In un primo momento nell'ascoltare la parola “free” molta gente pensava erroneamente che questa significava semplicemente software a "costo zero". E' vero che tutto il software libero è a costo zero, ma non tutto il software a costo zero è libero.[7] Per esempio, durante la battaglia dei browsers negli anni '90 sia Microsoft che Netscape diedero via i propri browsers in competizione gratis, nella zuffa per accaparrarsi un fetta di mercato. Nessuno dei due browsers era libero nel senso di “software libero”. Non si poteva ottenere il codice sorgente e anche si si fosse potuto ottenere non si aveva il diritto di modificarlo e redistribuirlo. [8] L'unica cosa che si poteva fare era scaricare un eseguibile e farlo girare sul computer. I browsers erano non più liberi di un software incartato comprato in un negozio. Essi avevano soltanto un prezzo abbastanza basso.
Questa confusione sulla parola “free” è dovuta a una sfortunata ambiguità nella lingua inglese. Molte altre lingue distinguono fra prezzi bassi e libertà (la distinzione fra gratis e libre è chiara immediatamente a coloro che parlano una lingua neolatina, per esempio. Ma a causa della posizione della lingua inglese come lingua ponte di fatto di Internet, un problema con la lingua inglese è in una certa misura un problema per chiunque. L'incomprensione sulla parola “free” era così prevalente che i programmatori di software libero alla fine elaborarono una formula standard nella risposta: “E' libero nel senso di in in regime di libertà—il pensiero libertà di parola, non il pensiero birra gratis." Comunque doverlo spiegare ancora e ancora è stancante. Molti programmatori ebbero la sensazione, non ingiustificata, che l'ambiguità della parola “free” stava ostacolando la comprensione di questo software.
Ma il problema diventò più profondo di così. La parola “free” portò con sè una inevitabile connotazione morale. Se in effetti la libertà era un fine, non era importante il fatto che che potesse succedere che il software libero fosse migliore oppure più profittevole per certi affari in certe circostanze. Quelli erano graditi effetti secondari di una causa che non era in fondo né tecnica né mercantile, ma morale. Inoltre la collocazione di “libero nel senso di in libertà” evidenziò una chiara incoerenza delle grosse imprese che da un lato dei propri affari volevano supportare particolari programmi liberi mentre dall'altro continuavano a commerciare software proprietario.
Sopraggiunsero questi dilemmi per una comunità che si trovava già in sospeso per una crisi di identità. I programmatori che realmente scrivevano software libero non erano stati mai unanimi su tutti gli obiettivi, se ce n'erano, del movimento del software libero. Persino dire che che le opinioni vanno da un estremo all'altro sarebbe fuorviante, giacchè ciò farebbe erroneamente pensare che esso sia in una zona lineare invece che in una dispersione multidimensionale. Comunque si possono distinguere due categorie di pensiero, se vogliamo ignorare le sottigliezze per il momento. Un gruppo fa proprie le vedute di Stallman che la libertà di condividere e modificare è la cosa più importante e che quindi se si finisce di parlare di libertà si perde il cuore della questione. Altri sentono che il software è l'argomento più importante in favore del software stesso e trovano scomodo proclamare che il software proprietario è cattivo per il fatto di essere software proprietario. Alcuni, ma non tutti i programmatori pensano che l'autore (e chi lo impiega, nel caso di lavoro pagato) dovrebbe avere il diritto di controllare termini della distribuzione e che non c'è bisogno di dare nessun giudizio morale sulla scelta dei particolari termini.
Per lungo tempo non ebbero bisogno di essere esaminate e coordinate ma il nascente successo del software libero nel mondo del business rese il problema ineludibile. Nel 1998 il termine open source fu creato in alternativa a “libero” da una colizione si programmatori che alla fine diventarono l' Open Source Initiative (OSI).[9] L'OSI si convinse non solo che il “software libero” era potenzialmente portatore di confusione ma che la parola “libero” era appunto un sintomo di un problema generale: che il movimento aveva bisogno di un programma di marketing per agganciarsi al mondo delle grandi imprese, e che il discorso della morale e di benefici sociali non avrebbe mai preso il volo al tavolo dei consigli di amministrazione. Nelle loro parole:
La Open Source Initiative è un programma di marketing per il software libero. Esso è un montare per il software libero su basi pragmatiche piuttosto che su una barca ideologica che fa rumore. La sostanza prevalente non è cambiata, la tendenza a perdere e il simbolismo si. ...
L'involucro che deve essere fatto per molte tecniche non è il concetto di open source ma il nome. Perchè non chiamarlo, come facevamo, software libero?
Una ragione diretta è che il termine “software libero” è facilmente mal compreso in modi che portano al conflitto. ...
Ma la vera ragione del cambiamento di etichetta e di tipo commerciale. Stiamo cercando di agganciare la nostra concezione a quella del mondo delle grosse imprese. Noi abbiamo un prodotto vincente ma il nostro posizionarsi in passato è stato spaventoso. Il termine “software libero” è stato mal interpretato dagli uomini d'affari che scambiarono il desiderio di scambiare con anti commercialismo, o peggio con imbroglio.
Le principali corporazioni CEOs e CTOs non compreranno mai il “software libero”. Ma se noi facciamo nostra proprio la stessa tradizione, la stessa gente e e le stesse licenze di software libero e ne cambiamo l'etichetta a “open source”? Così, essi lo compreranno.
Alcuni esperti di computer troveranno questo difficile da credere, ma ciò accade perchè essi sono tecnici che pensano in concreto, in termini di sostanza e non capiscono quanto sia importante l'immagine quando si vende qualcosa.
Nel marketing l'apparenza è realtà. L'apparenza che noi vogliamo togliere le barricate e che stiamo volendo lavorare con il mondo delle grosse imprese conta quanto la realtà del nostro comportamento, delle nostre convinzioni e del nostro software.
(da http://www.opensource.org/. O piuttosto, in passato da quel sito — l' OSI ha chiaramente preso le pagine sin d'allora, sebbene esse possano essere viste ancora a http://web.archive.org/web/20021204155057/http://www.opensource.org/advocacy/faq.php and http://web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/case_for_hackers.php#marketing.)
Le punte dei molti icebergs della controversia sono visibili in questo testo. Esso si riferisce alle “nostre convinzioni” ma evita abilmente di parlare di cosa esattamente siano le nostre convinzioni. Per qualcuno potrebbe essere la convinzione che il codice sviluppato in accordo con un processo aperto sarà un codice migliore; per altri potrebbe essere la convinzione che tutte le informazioni debbano essere condivise. C'è l'uso della parola “furto” per riferirsi (presumibilmente) alla copia illegale. Uso su cui molti hanno da ridire, sulla base del fatto che non è furto se tuttavia il possessore ne ha la notizia dopo. C'è il fatto che è allettante lasciar credere che il movimento del software libero potrebbe erroneamente essere accusato di anti comercialismo, ma si lascia non attentamente esaminata la questione se una tale accusa abbia di fatto una base.
Nessuna delle quali cose voleva dire che il sito dell'OSI era incoerente o ingannevole. Piuttosto era un esempio di quello che esattamente l'OSI dichiarava essere stato perso dal movimento del software libero: il “buon marketing” dove “buon” sta per “attuabile ne mondo degli affari”. L'Open Source Initiative diade a tanta gente esattamente quello di cui erano andati in cerca: un vocabolario per parlare del software libero come metodologia di sviluppo del software e di strategia di affari, non come una crociata morale.
La comparsa della Open Source Initiative cambiò il panorama del software libero. Essa formalizzò la dicotomia che era stata non nominata a lungo e nel fare ciò forzò il movimento a prendere atto del fatto che essa aveva un politica sia interna che esterna. L'effetto oggi è che ambedue le parti hanno dovuto cercare un comune terreno dato che molti progetti includono programmatori di ambedue i campi e anche partecipanti che non si inseriscono in nessuna categoria. Ciò non significa che la gente non parla mai di motivazioni morali gli errori nell'etica tradizionale di coloro che volevano abbattere certi limiti furono nominati ad alta voce, per esempio. Ma era raro per uno sviluppatore di software libero/opensource farsi domande sulle motivazione degli altri in un progetto. Il contributo vince su chi contribuisce. Se uno scrive del buon codice tu non gli chiedi se lo fa per ragioni morali, o perchè il suo datore di lavoro lo paga, o perchè si sta costruendo un curriculum vitae o per qualcos'altro. Tu valuti il software su basi tecniche e su basi tecniche dai il responso. Anche organizzazioni esplicitamente politiche come il progetto Debian, il cui obiettivo era quello di offrire un ambiente di calcolo libero al 100% (cioè “libero nel senso di in libertà”) era abbastanza permissivo nell'integrarsi con codice non libero e nel cooperare con programmatori che non condividevano esattamente gli stessi obiettivi.
[2] SourceForge.net, sito popolare solo di hosting aveva 79.225 progetti registrati a metà Aprile 2004. Questo non è neanche lontanamente il numero dei progetti in Internet, certamente; è solo il numero di quelli che scelgono di usare SourceForge.
[3] Stallman usa la parola “hacker” per indicare “chi ama programmare ed è abile nel farlo” non nel relativamente nuovo significato di “chi entra nei computers”.
[4] Esso sta per "GNU's Not Unix" e il “GNU” in quella espansione sta per ...la stessa cosa.
[5] Tecnicamente Linux non era il primo. Un sistema operativo libero per computers IBM compatibili, chiamato 386BSD era venuto fuori poco prima di Linux. Comunque sarebbe stato molto più difficile rifinire 386BSD e farlo girare. Linux così fece tale colpo non solo perchè era libero ma perchè aveva realmente una grande possibilità di avviare il vostro computer quando lo aveste installato.
[6] Essi preferiscono essere chiamati "X Window System", ma in pratica, la gente usualmente li chiama "X Window” perchè tre parole sono proprio troppo scomode.
[7] Uno può imporre un costo alle copie di software libero distribuite, ma dal momento che non può impedire al destinatario di offrire il software a costo zero dopo il prezzo è forzato a scendere completamente a zero,
[8] Il codice sorgente di Netscape Navigator fu alla fine rilasciato come licenza open source nel 1998 e diventò il fondamento di Mozilla. Vedere http://www.mozilla.org/.
[9] La web home dell OSI è http://www.opensource.org/.