IPPOLITA
OPEN NON È FREE
comunità digitali tra etica hacker e mercato globale (Parte 2)

I Cittadini possono scaricare l'intero testo da fondo pagina.pdf 1,08 Mb
Parte 1 - Parte 2

5. Non siamo fanatici, «Ci va bene qualunque licenza»...

«Ma non intendiamo farne una questione ideologica. Ci va bene qualunque licenza che ci permetta il controllo del software che usiamo, perché questo ci mette in grado a nostra volta di offrire ai nostri clienti e utenti il vantaggio del controllo, siano essi ingegneri della nasa o sviluppatori di applicazioni gestionali per studi dentistici» (19).
Robert Young, spiegando la nascita di Red Hat, una delle principali distribuzioni commerciali di Linux, è molto chiaro: ci va bene qualunque licenza, il mercato lo abbiamo già. Questo per l’economia globale è decisamente un bel passo in avanti, significa partire con il vento in poppa, un po’ come pescare in una vasca da bagno già colma di pesci: gli utenti – anzi i consumatori – ci sono, dateci gli strumenti per raggiungerli...
Alcune licenze costituiscono semplicemente una sorta di «lasciapassare» che una comunità più incline al richiamo commerciale recepisce per favorire il passaggio all’Open Source, visto come un modello di capitalismo alternativo, magari addirittura dal volto umano. La differenza tra software proprietario e Open Source nel «fare soldi» è infatti minima: si crea un grande prodotto, si fa del marketing creativo e accattivante, si genera «il bisogno», ci si cura degli utenti/clienti e si costruisce l’affidabilità del prodotto e di chi lo produce.
L’Open Source in questo modo diventa un marchio qualunque, un logo, un simbolo di affidabilità, qualità e coerenza e, come tale, porta profitti. Robert Young chiarisce molti aspetti relativi alle licenze e al loro attuale valore, che pare rimanere una dichiarazione di principi elastici quanto basta per consentire all’Open Source di affermarsi come modello economico di salvezza per il capitalismo in crisi di crescita.
Dal closed all’Open Source: cambia poco nei metodi di affermazione di un prodotto, ma cambia moltissimo nel mondo monopolistico del software. Il vantaggio di una marca che produce in un determinato settore è infatti l’ampiezza del proprio mercato, prima ancora delle quote che la società produttrice detiene: più utenti gnu/Linux in circolazione significa più clienti potenziali per Red Hat.
I rapporti di potere all’interno delle comunità hacker si rispecchiano quindi anche nell’ambito delle licenze; nel giugno del 2003 ad esempio la Red Hat è stata accusata di «uscire dalla GPL»: alcune parti dell’End User License Agreement (eula) del software Red Hat Advanced Server sembrerebbero essere in netto disaccordo con la licenza GPL (20).
Questo chiarisce inoltre come il capitalismo sia disposto ad assumere l’Open Source come alternativa economica all’attuale sistema monopolistico di Microsoft Windows e come parti di questo mondo cerchino costantemente strade per aprire nuovi mercati, per elaborare nuove strategie, per fare nuovi profitti.
L’Open Source in definitiva è solo il tentativo (fino ad ora riuscito) di adattare il metodo altamente produttivo delle comunità hacker, che rispetti la condivisione, ma che sia più elastico rispetto a ingerenza economiche commerciali. Questa elasticità, o flessibilità, è ormai usuale nei metodi di lavoro ed è sancita, verso l’esterno, con le licenze. L’Open Source rappresenta la vittoria del modello liberale sul modello libertario del Free Software: l’unica libertà che si preserva, in fondo, è quella del mercato.
Ogni tipo di licenza si presta a usi commerciali, si tratta di scegliere quella più adatta al proprio business. Tra il 1997 e il 1998, infatti, Linux, Freebsd, Apache e Perl hanno visto crescere l’attenzione di personaggi provenienti dal mondo commerciale (manager di progetto, dirigenti, analisti d’industria e venture capitalist). La maggior parte degli sviluppatori ha accolto quest’attenzione con molto favore: un po’ per orgoglio, un po’ per motivare i propri sforzi e, non ultimi, i propri compensi.

6. Nella pratica... modelli di business molto «aperti» e molto poco «liberi»

I moderati dunque spopolano. Molti ritengono ormai che il modello Open Source sia davvero un modello affidabile per la conduzione dello sviluppo software a scopi commerciali. Un’analisi ad ampio raggio delle licenze disponibili rileva che la bsd è, da un punto di vista commerciale, la migliore quando si debba intervenire su un progetto preesistente.
La bsd (21) in pratica specifica che il codice può essere utilizzato come meglio si crede, salvo darne credito all’autore. La licenza bsd fu scelta inizialmente da Apache, progetto nato da webmaster di ambiti commerciali che cercavano un web server in grado di ottimizzare le proprie esigenze di business. La bsd, molto semplicemente, permette l’inserimento di prodotti all’interno di software proprietari: per molti è una licenza pericolosa, volta a minimizzare l’impatto etico della cosiddetta economia del dono.
La licenza bsd o x e affini, in pratica, permette di fare ciò che si vuole del software licenziato. Questa «liberalità», spesso utilizzata contro la viralità «politicante» della GPL, ha radici precisamente politiche: il software originariamente coperto dalle licenze x e bsd era sovvenzionato con sussidi del Governo degli Stati Uniti. Dal momento che i cittadini statunitensi avevano già pagato il software con i soldi delle tasse, fu loro garantito il diritto di fare del software tutto ciò che volessero...
La bsd è un esempio calzante anche della possibilità di modifica delle licenze. Un dettaglio negativo era costituito da una clausola che fu poi espunta: la bsd prescriveva infatti che, ogni volta si facesse cenno a una caratteristica di un programma sotto bsd in una sua pubblicità, si esplicitasse il fatto che il software è stato sviluppato all’Università della California. Era evidente la problematicità di questa clausola per distribuzioni contenenti migliaia di pacchetti software.
La prima licenza, vicino alla bsd, che ha portato novità importanti, è stata quella di Mozilla: tale licenza prescrive che le modifiche alla distribuzione siano rilasciate sotto lo stesso copyright della mpl, rendendoli nuovamente disponibili al progetto. Evidente in questo caso il rischio di utilizzo di software proprietari: se per distribuzione si intendono i file così come vengono distribuiti nel codice sorgente, questo consente a un’azienda di aggiungere un’interfaccia a una libreria di software proprietario, senza che quest’ultimo sia sottoposto alla mpl, ma solo l’interfaccia.
Anche la GPL consente utilizzi commerciali, per quanto solo di riflesso e non esplicitamente nel testo: diciamo che il mercato non è il problema principale. Infatti, la GPL prescrive che «gli incrementi, i derivati e perfino il codice che incorpora altri codici» vengano rilasciati sotto GPL; per questo motivo la GPL viene definita «virale», per consentire che il codice che nasce free rimanga free.
Tuttavia anche la GPL può agire come «eliminatore» di concorrenti su un determinato progetto: con la GPL, come dimostra l’esempio di Cygnus, citato da Brian Behlendorf (uno dei leader del progetto Apache): «non c’è speranza che un concorrente possa trovare una nicchia tecnico-commerciale che sia sfruttabile con la struttura gcc senza dare a Cygnus la stessa opportunità di approfittare anche di quella tecnologia. Cygnus ha creato una situazione in cui i concorrenti non possono competere sul piano della diversificazione tecnologica, a meno che non intendano spendere quantità ingenti di tempo e di denaro e usare una piattaforma completamente diversa da gcc» (22).
La fsf di fronte ai cambiamenti in atto ha tentato di ovviare in qualche modo e recuperare terreno: nel 1999 nasce la lGPL (Lesser General Public Licence) (23) in relazione al problema delle librerie e per diminuire l’impatto considerato un po’ troppo limitante della GPL.
La lGPL, come la GPL, si presenta contemporaneamente come una licenza e come un manifesto politico: viene infatti specificato che le licenze della maggior parte dei programmi hanno il solo scopo di togliere all’utente la possibilità di condividere e modificare il programma stesso. Al contrario le Licenze Pubbliche Generiche gnu sono intese a garantire la libertà di condividere e modificare il software libero, al fine di assicurare che i programmi siano liberi per tutti i loro utenti.
Nella licenza viene messa in evidenza la finalità principale, ovvero garantire che anche un programma non libero possa utilizzare delle librerie open (ad esempio la libreria C del progetto gnu in modo da consentire a più persone di usare l’intero sistema operativo gnu), ma allo stesso tempo viene specificato di usare la licenza con parsimonia, nonché l’invito a sviluppare librerie libere in modo che chiunque possa ridistribuirle o modificarle (24).
Infine, nata nel 2000, la licenza gfdl (gnu Free Documentation Licence) (25) è una licenza libera, copyleft, ma per distribuire documentazione e non software; l’elaborazione è della fsf. Un esempio di applicazione concreta della gfdl è l’esperimento di Wikipedia (26), un’enciclopedia libera e multilingue open publishing: nella versione inglese è arrivata a contare oltre 500.000 voci, quella italiana al momento ne conta circa 40.000.

Le licenze software sono una modalità di relazione verso l’esterno di creazioni per lo più comunitarie. Vediamo ora come si relazionano al loro interno queste comunità.

Note al capitolo
1. la filosofia della GNU
2. definizione di open source (cache)
3. Il sito dell'open source (cache)
4. http://www.gnu.org/philosophy/free–sw.it.html
5. Il monopolio commerciale della microsoft si è ampliato a dismisura: dalle patenti europee del computer (ecdl), all’email su hotmail, passando ovviamente per msn, i sistemi operativi windows le certificazioni per sistemisti e programmatori. Tanta strada è stata fatta da quando Bill Gates nel 1975 vendette il porting per il linguaggio basic (Beginner’s All–Purpose Symbolic Instruction Code) per Altair 8800 a oggi; la softwarehouse Microsoft ha cambiato in questo lasso di tempo svariate facce. In origine nacque come società di sviluppo software (furono scritte infatti diverse versioni del linguaggio basic – non di sua invenzione –, il fortran, il cobol, pascal, visual basic e il nuovo c#), ma si specializzò ben presto in applicativi gestionali (visiCalc, ms–word, ms–excel) e sistemi operativi (Xenix e ms-dos). Sicuramente è da attribuirsi alla Microsoft l’introduzione in ambito professionale e, grazie ad un totale supporto di questa «nuova» tecnologia su tutti gli applicativi Microsoft, in soli 7 anni, la softhouse di Bill Gates si era guadagnata una fetta di tutto rispetto nel mercato informatico. L’anno decisivo è sicuramente il 1990 col rilascio di Windows 3.0: un sistema operativo abbastanza usabile, dotato di interfaccia grafica, a un costo nettamente inferiore rispetto al più avanzato Apple Macintosh. Windows 95, Windows nt, Windows 98, Windows 2000, Windows xp e molti altri sistemi operativi hanno invaso il mercato. Oggi Microsoft è la più grande società di software del mondo. Wikipedia: la storia di Microsoft (cache)
6.: Richard Stallmann definisce free software e open source «due partiti politici»
7. Più correttamente, Software Gratuito, ma non libero, si traduce con Freeware.
8. Molti «osservatori esterni» confondono erroneamente i piani: Negri e Hardt nel loro ultimo lavoro dedicano una parte all’Open Source descrivendolo come si descriverebbe il Free Software. A conferma di questa confusione, nelle note, viene citata un’opera di Stallmann da cui sono ripresi alcuni brani. Stallmann Open Source! (Michael Hardt, Antonio Negri, Moltitudine. Guerra e democrazia nel nuovo ordine imperiale, Rizzoli, Milano, 2004, p. 350)
9. http://www.Linux.it/GNU/softwarelibero.shtmlIl software libero per Linux.it
10. etimologia di "Licenza" (cache)
11. Mozilla Public Licenze
12. John Woo, Paycheck, 2003. Tratto dal racconto di Philip K. Dick, I labirinti della memoria, Fanucci, Roma, 2004.
13. Si veda ad esempio Philip K. Dick, Ubik, Fanucci, Roma, 1995 (ed. or. Ubik, 1969): i personaggi utilizzano già dei telefoni cellulari. Al di là dell’anticipazione tecnologica, più interessante è però la visione di nuove pratiche possibili: in fondo l’etica hacker, nella vulgata di «Stallman vs. software close», ricorda il libro proibito, che racconta un’altra storia possibile, «La cavalletta non si alzerà più», in La svastica sul sole, Fanucci, Roma, 1997 (ed. or. The Man in The High Castle, 1962), la terrificante ucronia sul nazismo.
14. Certo l’ufficio brevetti si occupa fin da troppo tempo di «proteggere» le conoscenze, costituendo di fatto un ostacolo sempre più insopportabile anche per le stesse aziende; per una lettura di Paycheck alla luce della situazione attuale, si veda l'archivio di quintostato.org (cache)
15. Da sempre oggetto di aspri dibattiti, la gpl è stata accusata nel 2003 da sco di violare la costituzione degli Stati Uniti, e le leggi sul copyright, sull’antitrust e sulle esportazioni (cache) E' invece di fine luglio 2004 il riconoscimento legale della licenza gpl da parte del tribunale tedesco di Monaco di Baviera.
16. Bruce Perens, The Open Source Definition (cache)
17. Eric S. Raymond, Colonizzare la Noosfera, 1998 (cache)
18. Ironicamente, una falla di sicurezza del sito della società delegata a gestire gli accessi al codice sorgente ha causato nel febbraio del 2004 la diffusione di una parte del sorgente di una versione preliminare di Windows 2000 (circa 200 mb di codice), da cui derivano anche Windows xp e Windows 2003.
19. la filosofia di Robert Young (cache)
20. David McNett? scrive infatti: «would appear to be at odds with the also included gnu General Public License.» (cache)
21. Testo originale della Licenza bsd versione 4.4 (inglese) (cache)
22. Brian Behlendorf, Open Source come strategia commerciale (cache)
23. Testo completo della licenza lgpl, (in inglese) (cache)
24. Un breve accenno all’Artistic License . Questa licenza è considerata incompatibile con la gpl e il progetto gnu: farraginosa e imprecisa nelle specifiche, non rappresenta né una novità né una rilettura di altre licenze; è mal formulata, perché impone dei requisiti e fornisce poi delle scappatoie che rendono facile aggirarli. Per questo molto software che utilizza questa licenza si avvale di una seconda licenza, quasi sempre la gpl.
25. gnu Free Documentation Licence (cache) Da notare che Debian sta eliminando tutti i software rilasciati sotto GFDL per incompatibilità con le proprie linee guida (cache)
26. Un esempio di applicazione concreta della gfdl è l’esperimento di Wikipedia

III- Comunità

1. Etica: pratiche non scritte

Le connotazioni etiche del software, come abbiamo visto nel capitolo precedente, sono definite da interazioni fra le modalità di distribuzione, le metodologie di sviluppo e le licenze applicate. Non dipendono dunque dal software in sé, non sono inscritte nel codice, ma sono frutto di un sistema complesso di sinergie.
In sostanza il discrimine è costituito dalla comunità di sviluppo che col proprio lavoro marca le caratteristiche peculiari del software sia in senso tecnico che culturale. Se la licenza di un software rispetta le caratteristiche espresse nei punti osi o fsf, allora questo applicativo si può definire «amico» del mondo Open Source o Free Software: è ragionevole aspettarsi che riceva tutti i benefici derivanti dall’uso di strumenti messi a disposizione dalla comunità.
Sin dalla nascita di internet, e nella maggior parte dei casi ancora oggi, è stata regola non scritta (ma fondante dei principi collaborativi tra sviluppatori) l’accordo a non riscrivere mai applicativi o librerie già esistenti. Al contrario: è pratica corrente avere sempre presenti gli aggiornamenti circa gli sviluppi degli altri progetti (1).
Non si tratta di una banale «usanza», ma di una pratica consolidata per ragioni precise. Infatti, è ritenuto più utile e interessante aderire a un progetto già avviato piuttosto che iniziarne uno nuovo, poiché la rete per sua natura si sviluppa in una miscela complessa nella quale l’emersione di grandi progetti avviene attraverso la collaborazione reale e non competitiva tra sviluppatori, debuggers e utenti.
Il processo attraverso il quale si raggiunge l’obiettivo spesso è più importante dell’obiettivo stesso; o meglio, se non si fosse sperimentato il metodo di sviluppo aperto, paritetico e di interdipendenza, il mondo del software non avrebbe avuto le stesse ricadute politiche sulla vita reale.
Molti interventi analizzano l’aspetto metodologico in questione avvalendosi di termini come «Passione», o «Economia del Dono» (2): viene così descritta e spiegata la ragione di tanta dedizione a progetti anche estremamente impegnativi nell’assoluta mancanza di una gratificazione economica.
Sicuramente il desiderio di aderire a un progetto comunitario è un elemento fondamentale: è un’energia che deriva dalla propensione al gioco, dalla scelta del gioco, peculiare dello spirito hacker. Per noi si tratta di una combinazione sinergica tra il piacere della creazione fine a se stessa e il senso di appartenenza a un gruppo, una comunità, capace di gratificazione e stimoli nei confronti dell’individuo. In ogni caso, più che di «economia del dono» si tratta di una «ecologia del desiderio»: un discorso fluido, non un paradigma strutturato di regole normative.

2. Come nasce e si sviluppa un software: dall’humus alla comunità

Una delle tante novità apportate dalla nascita del kernel Linux al Free Software è stata quella di espandere l’équipe di sviluppo del programma. Vengono aggiunti al core nuovi e diversi gruppi dedicati: per esempio, alla documentazione, alle distribuzioni complete, o alla creazione di temi grafici; fino alla nascita di community di semplici utilizzatori e appassionati.
Attualmente molti progetti di applicativi giungono al mondo Open Source da un passato commerciale di sviluppo close, affascinati o costretti a liberare i codici sorgenti proprietari per ragioni di business; altri invece, che nascono con precisi intenti commerciali, iniziano da subito a muoversi nel mondo del codice libero.
In qualunque caso, siano le comunità libere o interamente gestite da un’amministrazione aziendale, identifichiamo almeno cinque macro nodi, cinque tipologie che si intersecano variamente e compongono morfologie complesse: comunità di sviluppo, di distribuzione, di documentazione, di utenti, di sicurezza.
Cominceremo ad analizzare alcune diverse tipologie di comunità, a partire da come viene originariamente costruito un manufatto digitale. Per evitare noiose tassonomie, le chiameremo genericamente comunità Open Source, comprendendo anche le comunità che più si riconoscono nell’originario movimento Free Software.

3. Comunità di sviluppo

Quando nasce un applicativo, generalmente la spinta iniziale si deve alla volontà di un piccolo gruppo o di un singolo sviluppatore che ne abbozza i codici; capita molto di frequente, infatti, che gli hacker si dedichino per gioco ai propri progetti, pur portandoli a livelli di elevata comprensibilità, fruibilità e professionalità.
Attorno a una nuova idea di applicativo, troviamo sempre un ribollire di micro progetti, software completi e funzionanti, idee e codice. L’emersione di ogni singolo elemento da questo magma è frutto di una scrematura a ognuno dei grandi nodi; una volta affermata la stabilità dell’applicativo nessuno generalmente sceglie la via della competizione (imbarcandosi magari nella scrittura di qualcosa di analogo), piuttosto si collabora alla messa a punto di nuove idee presso il software «dominante» (3).
Di regola l’implementazione di un software avviene attraverso la scrittura di plugins, cioè per mezzo di aggiunte funzionali per programmi a gestione modulare. Pensiamo per esempio a Xmms, il clone del noto lettore di file audio Winamp per piattaforma Windows; la struttura di questo applicativo è pensata per supportare moduli che leggano nuove tipologie di file, ulteriori output audio, effetti grafici più avanzati.
Tramite la compilazione di plugins si formano piccole comunità o reti informali di singoli programmatori che forniscono il proprio contributo relazionandosi occasionalmente al progetto.
Questo fenomeno di cooperazione aperta è in corso da oltre dieci anni ed è particolarmente visibile anche in campi nuovi come il multimedia, il video e l’audio ove un numero incredibile di programmi sta iniziando a prendere piede con il desiderio di sfondare presso il grande pubblico (che a sua volta è in crescita verticale, data la disponibilità sempre maggiore di strumenti di riproduzione audio-video) (4).
Nella maggior parte dei casi i software che emergono sono quelli il cui team riesce ad affrontare con successo e rapidità le questioni tecniche e relazionali.
La velocità di risposta ai debuggers, che utilizzano l’applicativo e segnalano i problemi, e alle implementazione delle nuove funzioni, possono mettere in luce la capacità dei coder di sostituirsi alla figura del/dei mantainer condividendone il lavoro. Il mantainer, dal canto suo, dovrà essere in grado di puntualizzare o gratificare prontamente la mailinglist di sviluppo e/o della community allargata, confermando le modalità d’uso condivisa degli strumenti e la netiquette.
In sintesi, si può affermare che la possibilità di livellare la struttura gerarchica insita nelle comunità (vedi cap. i) dipende dalla capacità di scomposizione dei ruoli a opera del core di sviluppo.
Vi sono casi in cui software validi e complessi si formano attraverso la summa di progetti minori nati non tanto attraverso delle comunità, quanto piuttosto dal dialogo e dalla messa in relazione di patch individuali e scheletri di progetti abbandonati (5).
Le relazioni tra una specifica équipe di sviluppo e il resto della rete è spesso agevolata dalla presenza di individui chiave che aderiscono parallelamente a più progetti e sono capaci di travasare non soltanto le proprie competenze da un progetto all’altro, ma anche le informazioni e gli aggiornamenti sullo status di ciascuna elaborazione.
In maniera analoga esistono progetti che legano trasversalmente le comunità tra loro in un rapporto di interdipendenza.
Questo particolare legame tra applicativi non è da ritenersi una relazione di subalternità, bensì chiarisce quell’aspetto metodologico reticolare che rende la collaborazione paritetica la modalità attraverso la quale ogni nodo della rete è collegato esponenzialmente a un altro.
L’esempio migliore di correlazione tra progetti è costituito dalle librerie, ovvero porzioni di codice compilate che forniscono strumenti a programmi che abbiano la necessità di funzioni semplificate. Le librerie grafiche gtk, qt e fltk implementano gli elementi standard di un’applicazione visuale (pulsanti, menu, icone...), semplificando il lavoro dei programmatori che, appoggiandosi alla libreria preferita, scriveranno solo le funzioni reali del programma. Saranno infatti le librerie a disegnare i pulsanti, gestire i click del mouse, tracciare le ombre e molto di tutto ciò che siamo abituati a vedere come utenti (si vedano le Appendici in merito alle librerie qt).
Le librerie sono progetti trattati diffusamente da comunità il cui intento è fornire strumenti generici e trasversali per risolvere problemi complessi (connessioni di rete, comunicazione tra applicativi, gestione del testo, immagini, compressione). Esattamente come un software viene scritto con l’obiettivo di raggiungere più utenti possibile, una libreria è fatta per arrivare a quante più comunità possibile (chiariremo più avanti le contraddizioni, e le tensioni, insite nello sviluppo di queste applicazioni).
Abbiamo detto che all’interno delle comunità di sviluppo si trovano precise modalità organizzative. La maggior parte dei progetti ha una struttura mobile che ruota attorno a un elemento centrale: il mantainer, colui che dà inizio al progetto, che svolge la supervisione di ogni proposta, codice o suggerimento proveniente dalla comunità; infine, il mantainer decide circa l’uscita delle release del software.
In alcuni progetti particolarmente ampi e complessi, può accadere che alcuni fra i ruoli del mantainer siano gestiti da soggetti diversi. Un prototipo è la struttura cosiddetta «a stella» della comunità Linux ove esistono dei capo progetto per ogni singola sezione del kernel. Compito dei capi progetto (che nella fattispecie sono detti «luogotenenti») è quello di vagliare ogni materiale proveniente dai sotto-gruppi combinandolo per la consegna a Linus Torvalds che farà un ultimo check prima dell’uscita della release. In questa imponente struttura anche il ruolo della «messa online», della pubblicazione effettiva delle nuove versioni, è delegata a un responsabile. In questo modo il mantainer può dedicarsi, oltre alla scrittura di codice, solo a una supervisione generale di parti già testate e controllate da altri.
Esistono poi dei meta progetti che si possono descrivere come la collezione di un numero, a volte molto elevato, di ulteriori progetti o software. È il caso dei desktop grafici gnome e kde, formati da tante librerie e programmi, ognuno gestito da una comunità spesso anche totalmente indipendente dalla suite grafica stessa.
Editor, giochi, applicativi di rete, strumenti di configurazione sono alcuni degli elementi che formano i desktop grafici. Il ruolo di congiunzione per questi singoli progetti è ricoperto dalle librerie che attraverso una veste grafica omogenea fanno interagire gli elementi, controllandone l’esecuzione e passando ai vari programmi autonomi funzionalità automatizzate.

4. Comunità di distribuzione

Una distribuzione (gnu/Linux, ma non solo) è un insieme di programmi, file di configurazione, utility di amministrazione e un kernel, il tutto installabile su un computer e aggiornabile da repository appositamente dedicati sulla rete internet. Inoltre, almeno nella maggior parte dei casi, l’aggiornamento è gratuito.
Un’attività imprescindibile delle comunità di distribuzione consiste nel passare al setaccio la rete internet con l’obiettivo di trovare sempre nuovi applicativi che, compatibilmente con la policy della «distro» (cioè con le regole scritte della comunità di distribuzione), possano essere «pacchettizzati», ovvero resi installabili dall’utente finale attraverso i tools della distribuzione stessa.
Debian (6) è una distribuzione storica da sempre indipendente dalle grandi case commerciali; nel corso degli anni ha saputo brillantemente investire sulla formula della comunità aperta, includendo al proprio interno esclusivamente software di standard osi. Come si legge sul sito ufficiale della distribuzione:

«Debian è un sistema operativo (os) libero (free) per il tuo computer. Un sistema operativo è l’insieme dei programmi di base ed utilità che fanno funzionare il tuo computer. Debian utilizza Linux come kernel (la parte centrale di un sistema operativo), ma molti dei programmi di utilità vengono dal progetto gnu; per questo usiamo il nome gnu/Linux. Debian gnu/Linux fornisce più di un semplice os: viene distribuito con oltre 8710 pacchetti, programmi già compilati e impacchettati in modo tale da permettere installazioni facili sulla tua macchina».

Tuttavia, paradossalmente, per preservare la propria specificità «free», il team di Debian ha creato una struttura altamente gerarchica; per accedere alla comunità infatti occorre essere presentati da qualcuno già membro e superare alcune prove sulla storia, l’organigramma, e i rapporti della comunità Debian con il mondo gnu/Linux (7).
Questo passaggio di «iniziazione» è lungo e complesso, ma una volta entrati, si appartiene a una delle comunità più ampie ed eterogenee possibili, la cui etica è saldamente legata ai parametri del software libero. Certamente Debian non è l’unica distribuzione slegata dal mondo commerciale; ve ne sono molte altre, e di diverse tipologie.
Slackware (8) è una fondazione no profit; per scelta stilistica si presenta come una distribuzione minimale: infatti spesso è difficile trovare software pacchettizzati o appositamente configurati per le installazioni. Slackware prende spunto da un modello di boot simile a quello dei sistemi bsd: per questa ragione si differenzia parecchio dalla stragrande maggioranza delle altre distribuzioni gnu/Linux che invece sono livellate su un’organizzazione di script e directory detta System v (9).
Invece nel caso di Gentoo (10), una distribuzione recente realizzata da giovani hacker in ambiente universitario, l’installazione di un software si compie attraverso la compilazione ad hoc dei codici sorgenti. La compilazione di un programma direttamente sulla propria macchina rende l’applicazione maggiormente performante rispetto a un’installazione precompilata, ma i tempi dell’operazione si dilatano enormemente. Il successo di questo stile si deve all’illusione di possedere una distribuzione personalizzata creata passo dopo passo sul proprio computer.
Infine, anche se non sono basati su un kernel gnu/Linux, esistono anche i port di bsd, che presentano un sistema di compilazione parziale del codice sorgente dei programmi richiesti.
Queste le principali distribuzioni libere.
Le distribuzioni commerciali, come Redhat, suse, Mandrake, capofila di un discreto elenco, funzionano diversamente. Generalmente il core di sviluppo, documentazione ecc. della distribuzione viene retribuito dalle società finanziatrici del progetto; le propaggini secondarie vengono lasciate invece al lavoro volontario. Il team delle distribuzioni commerciali, per ovvi motivi di mercato, si impegna si impegna soprattutto nel creare tools di amministrazione semplificata e software di installazioni più grafici possibili (11).

5. Servizi

Tra comunità di sviluppo e comunità di utenti la comunicazione avviene attraverso il Web, ma sono i repository delle singole distribuzioni ad essere il mezzo maggiormente utilizzato per l’installazione o l’aggiornamento dei programmi.
Esistono poi degli specifici fornitori di servizi che mettono a disposizione, a chiunque ne faccia richiesta, computer per testing, repository, mailing list, spazio web e altro ancora. Di questi paradisi digitali solo due possono vantare una fama mondiale e un numero di progetti ospitati superiore a ogni altro concorrente: sourceforge.net e freshmeat.net.
Dietro a questi nomi, però, si trova un’unica società: la Va Software Corporation, che fornisce al mondo dell’Open Source computer estremamente potenti e banda larga, harddisk e assistenza non alla portata di tutti.

Il prestigio della Va Software è dovuto in particolare ai propri portali, che ospitano gratuitamente il codice sorgente delle comunità e dei singoli programmatori e permettono a chiunque di effettuare ricerche sul database dei progetti ospitati. Questi portali hanno una tale risonanza che anche i progetti più piccoli, una volta comparsi sulle prime pagine, arrivano tranquillamente a contare centinaia di visite al giorno.
Potete quindi immaginare come, con un database utilizzato gratuitamente da migliaia di coder, la Va Software possa garantire un ottimo servizio di business to business per aziende legate al mondo Open Source ma non solo. Un data mining di particolare interesse per business miliardari. Tra gli sponsor e advertiser di sourceforge e freshmeat troviamo infatti dalla Red Hat fino alla Microsoft.

6. Comunità di sicurezza

Le comunità nate attorno al tema della sicurezza informatica si costruiscono attorno a mailinglist, portali web e canali di chat; non hanno un aspetto progettualmente tecnico, o meglio: la loro finalità è quella di fare ricerca tecnica generica su bug critici.
L’obiettivo del security hacking è quello di trovare modalità di intrusione, prevenire l’esistenza di virus e ipotizzare nuove percorsi di attacco ai sistemi; per questa ragione si analizzano ogni tipo di software, anche le applicazioni close.
Gli ambiti di incontro e discussione su questi temi sono altamente compositi: vi si trovano ad esempio autorevoli cani sciolti che collaborano alle discussioni per qualche tempo per poi andarsene dedicandosi ad altro, sistemisti ed esperti di sicurezza, giovani hacker della scena underground, ovviamente la polizia e i servizi di ogni tipo, professionisti freelance oppure legati a società di penetration test o sistemistica (12).
Questo circuito della sicurezza è tra quelli che maggiormente suscita fascinazioni e ambiguità nell’immaginario, spesso superficiale, dell’opinione pubblica. Ma i cattivi pirati informatici sono una banalità mediatica, che riesce addirittura a confondere gli script kiddies (solitamente ragazzini che lanciano codici altrui per fare danni, ignorandone il funzionamento) con criminali comuni che usano le proprie capacità informatiche per semplici furti. La scena della sicurezza è ben più complessa e articolata, ma in ogni caso le comunità che scrivono gli exploit con i quali è possibile penetrare nei server per effettuare crimini informatici, sono anche quelle che forniscono supporto alle applicazioni per quel debug altamente tecnico che rende un’applicazione sicura e realmente affidabile (13).
Scendendo un poco più nel dettaglio, possiamo distinguere tre tipologie di soggetti connessi alla sicurezza informatica: gli utilizzatori di exploit, che si pongono come fine la semplice violazione dei sistemi, sono la categoria più ampia, perché essenzialmente costituiscono un fenomeno legato alla formazione di un’identità digitale e all’affermazione del sé. Questi soggetti spesso non conoscono nessun linguaggio di programmazione, ma nonostante questo svolgono anch’essi un importante lavoro di debug.
Coloro che scrivono l’exploit devono invece comprendere il funzionamento delle architetture di un computer ad alto livello. Hanno la capacità di comunicare col processore quasi a linguaggio macchina, possiedono uno stile proprio, ma non per forza sono veri e propri coder, anzi normalmente nutrono per questi ultimi profondo rispetto. I loro codici nella maggior parte dei casi sono brevi ed eleganti, ma non particolarmente articolati rispetto alle creazioni dei coder.
Infine, troviamo i soggetti che studiano i bug e creano nuove tipologie di exploit. Si tratta di un numero estremamente esiguo di ricercatori informatici con competenze e lampi di genio fuori dal comune che, con la loro intelligenza, creano nuovi percorsi e spazi nello scenario non solo della sicurezza ma della stessa programmazione.
Senza la resa pubblica del lavoro dei security hacker, su siti appositi come securityfocus.com (14), gli sviluppatori non potrebbero correggere al meglio i propri codici lasciando i dati alla mercé di chiunque sia in grado di sfruttarne i bug. Normalmente la scrittura di un exploit coincide con la scoperta del corrispettivo bug; entrambi i passaggi vengono realizzati e resi pubblici dalla stessa persona
Dal punto di vista della condivisione dei codici, esistono diverse tipologie di exploit. In alcuni casi i bug non vengono immediatamente resi noti, oppure sono conosciuti ma si ritiene che non esistano metodi per sfruttarne la vulnerabilità. Sono comunemente detti “0day” o “zero–day” quegli exploit che vengono usati ma di cui non si conosce subito né il bug né la relativa patch. Questo accade per ragioni commerciali o di altra varia natura. Si tratta di exploit dalle qualità strategiche capaci di riconfigurare i rapporti di forza interni alla scena di sicurezza; il giro di condivisione di questi codici è molto elitario e limitato a un tempo di poche settimane entro le quali vengono resi pubblici presso le comunità di riferimento. La ragione di questa particolarità è dovuta generalmente a errori negli algoritmi utilizzati (15).
Nella realtà questi ambienti sono altamente apprezzati sia per la ricerca puramente tecnica sia per l’aiuto offerto ai coder e agli utenti finali.
Per quanto spesso malvisti dalle società commerciali, i security hacker svolgono un ruolo fondamentale per l’intero mondo del software libero (16). La scrittura di exploit, per cercare una metafora «organica», equivale infatti a una poderosa scossa di adrenalina per la comunità del software «colpito»: tale comunità reagisce attivandosi immediatamente nella realizzazione di un’apposita patch (codice correttivo); frattanto a seconda della propagazione dell’exploit tutti gli utilizzatori del software non potranno che attendere la soluzione o la propria capitolazione.

7. Comunità, azienda, stato: casi interessanti

Come accennato nel primo capitolo, Mozilla è il primo progetto commerciale impiantato nell’Open Source; rappresenta uno dei più poderosi colpi inferti al dominio di Microsoft e il primo passo delle comunità verso le contraddizioni del mondo economico.
I risultati sono stati tecnicamente eccellenti, ma le ragioni politiche della società Netscape sono facilmente individuabili. Quando la Netscape nel 1998 decide di rilasciare il proprio browser sotto una licenza aperta e di investire su una comunità ad accesso libero, l’idea era chiara: ampliare quella fetta di mercato che stava pian piano perdendo spazio per colpa della Microsoft.
Il duo Mozilla-Firefox? sta velocemente minando il dominio del browser internet Explorer: nella versione suite (Mozilla, che comprende anche un client di posta e altre funzionalità), o standalone (Firefox), è disponibile praticamente per ogni sistema operativo e architettura e ha funzioni uniche nel suo genere, dal tabbed browsing (molteplici finestre aperte in contemporanea) all’espansione di funzionalità tramite plugins.
La Netscape ha certamente vinto la battaglia sui browser, diventando un logo nascosto dietro alle quinte di una comunità libera, tirandone i fili e indirizzandola verso ciò che ritiene commercialmente utile grazie a investimenti economici diretti ai programmatori.
Quando Netscape iniziò la propria mutazione era l’unico soggetto commerciale a investire in maniera cospicua nel mondo Open Source e quindi se si fosse presentata in forma troppo visibile come progetto commerciale non avrebbe potuto beneficiare della partecipazione spontanea intrinseca nelle comunità.
La comunità di Mozilla-Firefox?, ormai attiva da otto anni, presenta un’amministrazione molto verticale, basata su un team centrale coordinatore di singole unità più o meno tecnocratiche; questa struttura gerarchizzata tende a sviluppare tutti i codici necessari all’interno del proprio gruppo senza appoggiarsi, se non in rari casi, ad altri software o librerie, contravvenendo in questo modo all’assioma di interdipendenza tra progetti come forma di autovalutazione.
Un esempio eclatante è il supporto ssl, ovvero le connessioni criptate secondo uno scambio di chiavi pubbliche e private (rsa) (17), sviluppato e compilato come blocco unico dal core dei programmatori di questo progetto. La scelta di Firefox suscita diffidenza perché la proposta sugli algoritmi di criptazione più conosciuta e apprezzata sulla scena digitale, ovvero le librerie Openssl, sono sviluppate da una comunità molto attiva che da anni segue tutte le novità matematiche sulla criptografia: dallo streaming di rete alla criptazione di file e all’hashing di dati (18).
A un rapido controllo si noterà che il browser in questione si appoggia a poco più di tre progetti: x server, le librerie grafiche, le librerie base del sistema. Quest’aspetto monolitico è il principio della grande portabilità su altri sistemi operativi poiché in questo caso l’applicativo viene modificato solo in minima parte (giusto quella di grafica), lasciando la maggior parte del codice inalterato. Di contro, questo approccio sarà causa di una pesantezza e lentezza notevole rispetto a un software che sappia comunicare maggiormente con ciò che è già presente e attivo all’interno del sistema.
In ragione di queste scelte tecniche, progetti simili a Mozilla-Firefox?, come vedremo in seguito, privilegiano un preciso target comunitario: quello dell’utenza medio bassa, la quale si prodigherà nel debuggare il browser ma a livello di sola funzionalità del programma; mentre coloro che in un applicativo considerano prima di tutto l’affidabilità del codice saranno decisamente poco stimolati dalla ridondanza proposta o addirittura disturbati dalla mancata valorizzazione delle competenze sviluppate da altre comunità.
Da Netscape in poi, con la nascita del movimento Open Source, nel corso di qualche anno lo scenario è cambiato a tal punto che attualmente esistono intere aziende nate con lo scopo di interagire con il metodo proprio della libera condivisione. Uno degli episodi più emblematici degli ultimi anni è stato l’acquisto da parte della Novell, un’azienda produttrice di hardware, di una piccola software house, la Ximian, nota per il client di posta Evolution, un clone di Ms Outlook per Windows. Novell è una delle tante società che ha giostrato i copyright commerciali dello unix rimbalzati di mano in mano come il testimone in una gara economica. Ximian era un team di programmatori Open Source come altri, e in pochissimo tempo si è trasformata in uno dei poli centrali per progetti aperti dal valore strategico. Oggi la Ximian detiene il core di sviluppo di applicazioni come gnome, uno dei desktop più utilizzati sotto Linux, il già citato Evolution, e Gnumeric, foglio di stile compatibile con Ms Excel.
I software Ximian infatti sono scaricabili dal sito internet della Novell e le comunità degli applicativi si basano su server che come desinenza hanno sempre novell.com.
Per molti la possibilità di lavorare con un contratto per un’azienda che sviluppa progetti open sotto GPL ha rappresentato il raggiungimento completo di un obiettivo etico; per molti altri però, che ne intravvedevano le ambiguità politiche, la soddisfazione è stata solo parziale.
Succede sempre più spesso che gli sviluppatori, consapevoli delle posizioni equivoche assunte dalle multinazionali, scelgano un doppio passaporto: da una parte svolgono un lavoro remunerato presso le majors che investono dell’Open Source; dall’altra proseguono un’attività creativa non retribuita presso progetti indipendenti.
Interessante anche la vicenda di Open Office, il clone della suite per ufficio Microsoft Office. Acquistato nel 1999 dal colosso Sun Microsystems, i suoi codici vennero liberati a partire dall’anno successivo. Attualmente, in ragione della sua estrema portabilità, rappresenta una delle migliori teste d’ariete puntate verso i cancelli dell’impero Microsoft.
Ogni release del software è posta sotto una duplice licenza: lGPL e sissl (Sun Industry Standards Source License), con la quale la Sun commercializza l’applicativo.
Al pari di Mozilla, OpenOffice? è un applicativo completamente indipendente e allo stesso modo reca con sé le problematiche di lentezza e pesantezza.
Programmi come questi possono infatti funzionare al meglio solo su architetture realativamente recenti. Per questa ragione rappresentano un ostacolo per chi non ha modo di comprare agevolmente hardware all’avanguardia o cerca di dimostrare che con la tecnologia libera è possibile riciclare le vecchie architetture.
La velocità di avvio in grafica di un programma è estremamente favorita dalla compatibilità di questo con le librerie preinstallate; mancando quel rapporto di interdipendenza che abbiamo descritto, quegli applicativi completamente separati dal sistema risulteranno inutilizzabili sotto la soglia del Pentium iii.
Ammantandosi della filosofia propria del Free Software e appoggiando le battaglie europee per la lotta ai brevetti, il progetto OpenOffice?.org riceve la collaborazione spontanea e gratuita di centinaia di sinceri democratici, che ritengono così di contribuire all’apertura orizzontale dei software. In molti, infatti, ritengono sia più importante mettere a segno una vittoria dell’Open Source sul mercato piuttosto che affrontare un ragionamento sulle risorse disponibili per la popolazione esclusa dal paradigma digitale. La crescita parallela, concordata (il duo Intel-Microsoft? è solo il più noto) e del tutto assurda, di hardware sempre più potenti necessari solo a far girare software pesanti, con milioni di funzioni inutili, è la dimostrazione lampante dell’ipocrisia delle analisi in merito al digital divide.
In molti sostengono che in questa fase sia prioritaria la diffusione su larga scala della consapevolezza della non brevettabilità del codice e quindi auspicano la sistematizzazione dei cloni di programmi proprietari come Ms Office. Dal nostro punto di vista la lotta contro il copyright è certamente imprescindibile, ma riteniamo vada supportata a partire da una conoscenza critica degli strumenti e non da un generico «uso di applicativi aperti». Non siamo disposti a rinunciare alle libertà in nome di una più conciliante apertura.
Naturalmente c’è anche chi non nasconde i propri intenti meramente commerciali. È il caso di Snort (19), uno tra i più famosi e utilizzati Intrusion detector; questo tipo di software serve per rilevare e segnalare intrusioni sul sistema. Marty Roesch, sviluppatore e mantainer del progetto, in molte interviste ha chiarito la sua posizione di fronte al mondo del codice aperto. Ha definito il proprio lavoro come un bell’esperimento commerciale: sviluppare con strumenti Open Source semplifica il lavoro, permette di avere codice più sicuro e più in fretta.
Snort è distribuito sotto licenza GPL, ma attorno a esso è nata una società diretta dallo stesso Roesch che distribuisce moduli aggiuntivi close a pagamento. I moduli sono aggiunge funzionali al software e permettono di estendere regioni del programma in maniera quasi illimitata. In poche parole l’utente può scaricare la versione base di Snort gratuitamente e sondarne il codice, ma se desidera considerare le evoluzioni del software dovrà pagarne i moduli senza poter accedere ai nuovi codici.
Diametralmente opposta è la visione della comunità kde, la quale, nel suo manifesto (20), scrive di definirsi free in ogni aspetto del termine.
kde, però, è finanziata dal governo tedesco dal 2003, ovvero da quando la Germania iniziò a investire nell’Open Source per passare tutta l’Amministrazione Pubblica a gnu/Linux. In questo senso kde e Suse sono state scelte abbastanza obbligate dal momento che Suse è una distribuzione nata e sviluppata in Germania e la comunità tedesca kde è una tra le più attive.
kde propone un desktop grafico free basato su server x, ma va ricordato che la sua grafica è frutto delle librerie qt, sviluppate close dalla Trolltech (21) e rilasciate solo nel 1999 con una licenza Open Source. Quindi, per quanto kde si sia sempre definito libero, ha avuto per oltre quattro anni di sviluppo una contraddizione difficile da gestire; ancora adesso le librerie qt (vedi Appendice: Le librerie qt) non sono sviluppate da una comunità libera, ma dal team ufficiale della Trolltech, società con relazioni commerciali talmente ramificate da coprire ogni aspetto del mondo dell’it.
Per la somma di 210 milioni di dollari nel gennaio 2004 Novell ha acquisito suse: con questa mossa, diventa il primo fornitore di soluzioni gnu/Linux per l’azienda, dai desktop ai server. I toni sono stati trionfalistici: «Novell sarà l’unica azienda software da 1 miliardo di dollari con una distribuzione Linux e con personale tecnico in tutto il mondo in grado di fornire supporto».
Sempre nel gennaio 2004 Novell ha rinnovato il proprio accordo con ibm per circa 50 milioni di dollari. L’accordo permette a ibm di distribuire suse Linux Enterprise Server con i server ibm. Novell apre così un nuovo canale per distribuire suse Linux in tutto il mondo.
È interessante seguire le peripezie finanziarie di questi colossi e le loro alleanze al di fuori del mondo specificamente informatico: aziende che si fanno paladine dell’apertura dei codici, contro la chiusura di Microsoft, ma poi nei fatti sono mosse dai medesimi interessi commerciali di profitto a qualunque costo e non certo da uno sfrenato desiderio di condivisione del loro know-how tecnologico.
Gli investitori di suse Linux sono e-millenium1, AdAstra? Erste Beteiligungs GmbH e apax Partners & CO. Apax (un termine greco che significa «una volta sola») è una società di servizi finanziari di «venture capital e private equity», gestisce 12 miliardi di euro nel mondo (dato 2001), con uffici a New York, Londra, Parigi, Milano, Monaco, Madrid, Tel Aviv, Stoccolma e Zurigo. Ultimamente ha fatto shopping in Italia stringendo un accordo per 8,6 milioni di dollari per finanziare l’italiana Kelyan Lab, azienda del gruppo Bernabè (partner tim), per Net solutions avanzate. Con le Telco italiane sembrano proprio essere affari d’oro per la Apax, che ha incrociato anche Telecom nei propri affarucci israeliani. Apax infatti è nota (spesso accostata alla Jerusalem Global Ventures) anche per le sue operazioni in Israele dove investe soprattutto in microelettronica e materiali avanzati, settori indissolubilmente legati alla produzione di armi nonché al controllo militare del territorio; per questo è stata oggetto di boicottaggio. AdAstra? Erste è una società di venture capital con sede a Monaco di Baviera: Lead Investor è la HypoVereinsbank?, la seconda banca in Germania.
Quest’ultima fa parte del consorzio di collocamento della Deutsch Post di cui azionista di maggioranza è il governo tedesco. Inoltre AdAstra? Erste nell’ottobre 2004 ha investito parecchi milioni di dollari a sostegno della Biomax, una società di bio–informatica.
Insomma dietro alla «libera» suse, ora la «aperta» suse-Novell, c’è la crema del venture capital tedesco.
In Francia invece il ministro della Funzione pubblica Renaud Dutreil, ha dichiarato nel giugno 2004 che, per aggiornare una parte dei computer dell’amministrazione statale, intende chiamare in causa i fornitori di programmi Open Source, con un’iniziativa mirata a contenere il deficit pubblico.
«Non abbiamo intenzione di dichiarare guerra a Microsoft o alle compagnie informatiche statunitensi», ha precisato Dutreil in un’intervista. «La competizione è aperta e ci auguriamo di riuscire a portare in fondo un taglio dei costi di almeno il 50%, ha aggiunto il ministro» (20).
Come in Germania il consorzio di aziende si è dato disponibile ad agevolare il business è formato da ibm e Novell-suse

8. Gare

Sfruttando la meritocrazia e la competizione insite nel mondo dell’hacking, il desiderio di creare un hack sempre migliore, vi sono state anche particolari derive che sono riuscite a influenzare persino la fsf. I sistemi di infiltrazione e finanziamento più o meno nascosti promossi dagli investitori commerciali – in un mondo regolato essenzialmente dalle licenze – sono sempre più palesi.
Fra le novità indicative del cambiamento in corso nel mondo dell’Open Source le gare a progetto sono certo la più notevole. Si tratta di vere e proprie sfide sulla scrittura di intere parti di codice con premi economici ai vincitori: chi prima consegna o chi trova e corregge più velocemente i bug riceve infatti una somma tra i 200 e i 1200 dollari.
Le applicazioni più eclatanti di questa strategia sono state messe in atto dalle comunità di mono e .gnu, progetti apparentemente (22) in competizione fra loro per la clonazione del framework .net, sviluppato da Microsoft, su piattaforma gnu/Linux.
mono è gestito dalla ximian, e quindi di proprietà dalla Novell, mentre .gnu è curato dalla Free Software Foundation.
.net è un’idea e una implementazione Microsoft di un terreno digitale (framework) sul quale possono girare programmi scritti nei più diversi linguaggi (c++, Visual Basic, c# e altri) con l’obiettivo di rendere gli applicativi portabili da un computer all’altro, anche in streaming, su ogni sistema Windows (23).
mono e .gnu sviluppano un medesimo framework su piattaforma gnu/Linux con l’idea di far girare applicazioni Microsoft e in genere per Windows anche su sistemi operativi liberi. Avere un terreno digitale su cui è possibile programmare con un linguaggio intermedio tra il linguaggio macchina e il linguaggio scelto dal programmatore rende ogni programma teoricamente portabile su qualsiasi sistema operativo dotato di tale framework.
Il linguaggio intermedio è un qualcosa di commestibile dal framework che lo esegue in linguaggio macchina per il processore e il sistema operativo su cui sta girando. In altre parole il programmatore potrà scegliere il suo linguaggio, il compilatore lo trasformerà in linguaggio intermedio, il framework lo eseguirà su ogni architettura.
L’idea è già stata ampiamente implementata e utilizzata con alterne fortune. Java, ad esempio, si basa su una Virtual Machine che rende un applicativo scritto in questo linguaggio portabile su ogni sistema operativo dotato del framework opportuno. (24) In sostanza, lo stesso programma Java può girare su un pc, su un Mac, su un’Alpha Station ma anche su un cellulare o su una lavatrice (25).
Un altro modo per conseguire il traguardo della portabilità è quello di scrivere applicazioni in linguaggi interpretati, che quindi, non essendo compilati, girano ovunque ci sia un software capace di comprenderne la sintassi.
L’innovazione di .net è quella di aver reso la portabilità un elemento nativo del compilatore. In questo modo una qualunque applicazione scritta in un qualunque linguaggio girerà su ogni sistema dotato del framework .net.
Progettare questi compilatori implica notevoli modifiche a progetti da tempo già affermati (in particolare gcc) e per il mondo Open Source la scrittura da zero di nuovi compilatori per c# e Visual Basic che sono linguaggi proprietari di Windows.
Entrambi i gruppi si sono confrontati con la complessità del lavoro intrapreso e hanno optato per una scelta operativa similare: pagare chi consegnava per primo una delle parti più «noiose» da effettuare. Questi codici riguardano per lo più la grafica e le comunicazioni di rete mentre lo sviluppo delle parti più complesse e interessanti viene lasciato alle comunità. Ricorre a questo metodo di sviluppo anche Mozilla: in questo caso però le gare sono limitate ai bug e il contributo economico è proporzionato alla complessità del problema risolto.
Gli esempi di comunità spurie o metodi eterodossi sono innumerevoli. Potrebbe sembrare del tutto incidentale, superflua, la quantità di dati tecnici posta sul piatto. In fondo, sembrerebbe un banale scambio di tempo-uomo per programmare macchine in cambio di denaro. Vedremo nel prossimo capitolo come questo sia in realtà un problema relativamente marginale, o comunque derivato: del resto, abbiamo già sottolineato che lo spirito della fsf non sia contro il mercato, lo contempla fin dalle origini come una delle molteplici possibilità ma certo non la più importante. Il problema, dunque, non è il denaro, bensì le relazioni di potere.
La questione si articola riguardo all’individuo e alla comunità di riferimento.
Siamo arrivati fin qui perché scoprendo i nervi, le viscere delle comunità in alcuni passaggi critici, l’elemento comunitario sembra dissolversi. Le gare indette anche da .gnu sono un elemento di verifica lampante di come l’equilibrio complesso, l’humus delle comunità, si riduca a una prestazione seriale di competenze in cambio di identità. Dilatare il tempo dell’emergenza, continuare a insistere sulla necessità di risultati, subito, adesso, e sempre, significa mutuare una metodologia propria della produttività capitalistica. Ma dilatare il tempo nell’urgenza perenne (centrare gli obiettivi a ogni costo) corrisponde a un movimento di contrazione compulsiva nella quale il desiderio non ha più spazio. Il potere tecnico dell’individuo (semplice atomo e non parte di una comunità) si cede in cambio di un riconoscimento troppo ristretto, ridotto, non condiviso, senza adesione a un piacere più ampio. Il desiderio deve allora essere sostituito con il denaro: questa è la nuova identità trovata. Scambio di know-how tecnico per alimentare una dipendenza dall’ultimo ritrovato, dallo stare sulla breccia a qualsiasi prezzo: sopravvivenza immediata, non più hacking creativo.
A questo livello, la ricaduta nella realtà è completamente priva di stile. I piani vengono schiacciati, banalizzati, e ridotti a un puro, semplice, scambio di tempo, denaro, potere.
Si apre uno scenario a cui si aggiunge, oltre che la sfida tecnica, un confronto e una lotta serrata sui rapporti di forza nel lavoro telematico e dei diritti digitali in seguito alla vittoria, de facto, della GPL. La difficoltà ora sta nel comprendere che l’etica di un software non sta solo nella licenza, ma nell’interazione tra le modalità di distribuzione e la metodologia di sviluppo, poichè il sistema si è fatto più complesso.
Da una parte i programmatori dovranno fare i conti con il dilagante vortice di precarietà della quale, se isolati da un confronto critico, saranno facilmente preda; dall’altra i futuri consumatori–utenti di prodotti Open Source dovranno affinare le proprie capacità autoformative al di là della veste user–friendly di un qualunque applicativo.
Si tratta di rendersi consapevoli degli aspetti multi-identitari che il mondo digitale reca con sé, sviluppandone al massimo la tensione ricombinatoria.
Per esempio: per i coder, utilizzare un doppio passaporto (triplo, ecc.), costruendo la propria identità intorno a molteplici scelte e attività: compiti magari noiosi (la grafica dei pulsanti) ma retribuiti, compiti non creativi ma utili a un progetto a cui si aderisce, compiti creativi svincolati da riconoscimenti monetari, e così via, giocando a diversi livelli.
Più in generale, anche in senso non tecnico, è necessario rendere pubblici i modelli organizzativi della propria équipe di lavoro, in un’ottica di apertura, condivisione, implementazione collettiva. È necessario implementare le mediazioni economiche che da singoli o comunità si pongono a garanzia della propria indipendenza. Sabotare in qualità di utenti smaliziati le semplici barriere ideologiche che impediscono la comunicazione diretta oltre lo steccato del proprio posto di lavoro.
Tuttavia questi sarebbero temi buoni per un manuale di autodifesa digitale dagli sciacalli del know-how nell’era della mezzadria globalizzata; gente ridicola che si riempie la bocca di parole come skill, mission, framework, workaround, development, naturalmente senza aver mai messo le mani su una macchina né tanto meno aver mai lavorato davvero a un progetto condiviso; perciò ci riserviamo di scriverne in altro ambito.
Le pratiche delle comunità, in ogni caso, sono di capitale importanza per la comprensione delle dinamiche in atto. Prima di vedere come gli individui agiscono e interagiscono nei contesti comunitari, diamo un’occhiata alle relazioni che il mondo delle comunità Open Source ha stabilito con il mercato.

note
1 . È curioso che nel mondo del codice le pratiche siano spesso non codificate, non scritte, o meglio, vengano codificate ed esplicitate solo quando si pone un problema concreto da risolvere... Un approccio sicuramente improntato alla funzionalità, al desiderio di creare qualcosa che dia soddisfazione piuttosto che a realizzare una solida costruzione coerente e inattaccabile, o riconducibile in modo inequivocabile a una qualsiasi corrente di pensiero.
2 . Si vedano, in particolare sull’economia del dono riguardo al software: Eric S. Raymond, op. cit.; la micro introduzione al tema di Francesco Varanini, http://www.bloom.it/vara39.htm (cache). Il testo di riferimento rimane comunque Marcel Mauss, Saggio sul dono, Einaudi, Torino, 2002 (ed. or. Essay sur le don, Paris, PUF, 1950 1924). In sostanza, la descrizione antropologica dei rituali del dono compiuta da Mauss (come l’anello di kula polinesiano e il potlach fra le tribù dei nativi americani) viene applicata all’attuale congiuntura economica: spesso, va detto, con eccessivo semplicismo e toni profetici sull’avvento di un capitalismo “postmoderno” o di un’economia della complessità. Sicuramente lo studio delle teorie sul dono in ambito economico è un passo in avanti rispetto alla chiusura concettuale del liberismo classico; inoltre, riscoprendo antichi rituali, queste teorie contribuiscono alla formulazione di un pensiero critico sull’identità, poiché il legame sociale appare il fine e non il mezzo per l’affermazione dell’io e la costruzione dell’identità stessa. Il dono è però un concetto ambiguo e ambivalente, colmo di aporie come tutto ciò che riguarda l’antropologia. I discorsi sull’open economy (si veda ad esempio http://www.open–economy.org/) dovrebbero come minimo tener presente le riflessioni di Jacques Derrida “Se la persona cui dono qualcosa ne è consapevole e mostra quindi la sua riconoscenza dicendomi ad esempio: ‘ho ricevuto questo da parte tua, grazie’, questa semplice gratitudine e questa presa di coscienza mettono in moto un circolo economico e un gesto di restituzione che, come tali, distruggono il dono”. http://lgxserver.uniba.it/lei/rassegna/990218.htm (cache); si veda anche Jacques Derrida, Donare il tempo, Cortina, Milano, 1996 (ed. or. Donner le temps, Editions Galilée, Paris, 1991).
3 . Lo strumento cardine della condivisione nel lavoro in rete è il CVS (Concurrent Versions System), un programma che permette di modificare un insieme di file tenendo traccia di ogni singola modifica, in modo da poter risalire con facilità a una versione precedente in caso di errori. Parlando di CVS si intende un metodo di lavoro ma anche un software vero e proprio. Tuttavia, come è usuale nel mondo del software libero, non esiste mai solo un applicativo che copre una funzione, ma si può scegliere tra una vasta gamma di possibilità. Oltre al CVS (http://www.gnu.org/software/cvs/ (cache)), citiamo quindi anche SVN (SubVersion – http://subversion.tigris.org (cache)), un software altrettanto valido e utilizzato.
4 . SITOGRAFIA: Il mercato Macintosh.
5 . Fetchmail è un esempio di software nato dagli scheletri di altri. Si tratta di un vero e proprio patchwork realizzato da Raymond. SITOGRAFIA: Fetchmail.
6 . Sito ufficiale http://www.debian.org (cache)
7 . Debian sostiene la FSF anche nello sviluppo di HURD: http://www.debian.org/ports/hurd/ (cache)
8 . Sito ufficiale http://www.slackware.com/ (cache)
9 . System V e BSD. UNIX System V (spesso chiamato semplicemente System V), era una delle versioni del sistema operativo proprietario UNIX. Sviluppato dalla AT&T e rilasciato nel 1989, ne furono sviluppate 4 versioni successive (release). System V Release 4 (o SVR4), che unisce caratteristiche del System V, di Xenix e di BSD, è sicuramente stata la più famosa, introducendo numerose caratteristiche tipiche dei sistemi unix–like, quali il sistema di Sys V init scripts (/etc/init.d), usato per l’avvio e lo spegnimento del sistema, e le System V Interface Definition, uno standard che definisce quello che dovrebbe essere il funzionamento dei sistemi System V. Berkeley Software Distribution (più noto come BSD) è invece il primo e l’ultimo flavour (versione) che tenta il distacco dalla linea concepita da AT&T; BSD soprattutto ha significato: nuove chiamate al kernel; una nuova concezione dei processi di boot, configurazione dei servizi, gestione di account, dischi e dispositivi; nuovi comandi. Timeline aggiornata sulla storia di Unix: http://www.levenez.com/unix/ (cache)
10 . Sito ufficiale http://www.gentoo.org (cache)
11 . Esistono poi altre tipologie di distribuzioni chiamate LiveCD (Live Distro), ovvero cdrom autoavvianti (ma ormai anche minidistribuzioni per penne USB o altre memorie di massa) che rendono subito utilizzabile un sistema GNU/Linux senza bisogno di installazione; ne esistono per varie architetture (PC, PowerPC, ecc.). Knoppix, Gentoo livecd, ecc. (ma ormai anche le principali distribuzioni commerciali offrono una versione live) sono alcuni esempi fra i più noti di una lista molto lunga: http://www.frozentech.com/content/livecd.php (cache)
12 . Le società di penetration test producono questi codici o semplicemente vendono come servizio alle aziende test per implementare la sicurezza e svelare violazioni dei sistemi informatici.
13 . Il server di posta Qmail, oggi largamente utilizzato, non è soggetto ad aggiornamenti dal 1997 e non perché il progetto sia morto, tutt’altro: da quella data non necessita di correzioni legate a problemi di sicurezza, ovvero nessuno fino a oggi è riuscito a trovare dei bug. Questa insolita circostanza ha destato curiosità a tal punto da suscitare il desiderio di una vera e propria sfida, infatti per il primo che riuscirà a trovare una falla di sicurezza nel programma c’è un simbolico premio in denaro (1000 dollari). L’eccentrico programmatore Daniel J. Bernstein, autore del codice di qmail, ha pubblicato al link http://web.infoave.net/~dsill/dave/qmail/qmail–challenge.html le regole per partecipare alla sfida, tutt’ora imbattuta.
14 . La media degli exploit pubblicati su securityfocus.com si aggira intorno ai 5 giornalieri. La società è stata fondata da Elias Levy meglio conosciuto come aleph1 alias l’hacker che ha redatto il primo testo sulla scrittura di exploit. Si veda http://www.phrack.org/phrack/49/P49–14. Nell’agosto 2002, dopo meno di un anno dalla fondazione (ottobre 2001) il portale è stato acquistato dalla Symantec, nota società di antivirus.
15 . La trasmissione di queste conoscenze è, curiosamente, orale. Non esistono siti che riportino aneddoti dettagliati circa gli zero-day e il loro ciclo vitale.
16 . SITOGRAFIA: SHA1, Secure Hashing Algoritm. L’algoritmo SHA1, usato in molti programmi di criptazione, restituisce in alcuni casi lo stesso hash date informazioni differenti: questo bug potrebbe essere utilizzato per la scrittura di exploit.
17 . http://en.wikipedia.org/wiki/RSA (cache)
18 . Sito ufficiale http://www.openssl.org (cache). Il gruppo rilascia un software stabile ed disponibile per qualsiasi programma voglia usufruire di criptazione dati dal 1996 a oggi ed è de facto uno standard nel mondo del codice libero.
19 . http://www.snort.org/ (cache)
20 . Il Manifesto etico di KDE: http://www.kde.org/whatiskde/kdemanifesto.php (cache)
21 . SITOGRAFIA: Trolltech. Vedi Appedice: Le librerie QT.
22 . http://www.unita.it/index.asp?SEZIONE_COD=HP&TOPIC_TIPO=&TOPIC_ID=35567 (cache) Una curiosità: nell’aprile 2004 Sun e Wal Mart hanno stretto un accordo per distribuire al dettaglio i PC Microtel dotati della distribuzione GNU/Linux di Sun Microsystems.
23 . I progetti Mono (cache) e .GNU (cache) non competono fra loro ma coprono due aspetti del panorama generato dall’avvento di .NET. Mentre Mono rappresenta il porting quasi completato del framework .NET di Microsoft sotto GNU/Linux, .GNU crea l’alternativa sfruttando le stesse tecnologie. Contrastando una politica di centralizzazione dei dati portata avanti dalla Microsoft, la GNU vuole utilizzare gli stessi strumenti per decentralizzare le informazioni e i programmi. In pratica entrambi i progetti hanno completato lo sviluppo di compilatori pressoché identici per i linguaggi C, C# e stanno procedendo con la scrittura di quelli per java e Visual Basic. Mentre .GNU ha rilasciato il suo webserver per realizzare groupware, la Mono ha concluso anche il supporto per i linguaggi ADO.NET e ASP.NET oltre alle librerie grafiche GTK. Segnaliamo un interessante dibattito sulle ragione per cui proseguire lo sviluppo di progetti che di fatto aumentano l’influenza di Microsoft nel panorama Open Source: http://www.theregister.co.uk/content/4/35481.html (cache)
24 . La portabilità di un software consiste nella sua idoneità di funzionamento su sistemi operativi diversi, architetture dissimili e processori differenti, senza bisogno di ricompilazioni o modifiche. Non bisogna confondere la portabilità col fatto che molti programmi esistano sia in versione Windows che GNU/Linux (o per Apple e altre architetture ancora), perché spesso questa possibilità è dovuta a modifiche anche sostanziali del codice.
25 . Vi sono diverse ragioni per evitare l’utilizzo di java, in primis la lentezza e l’eccessivo dispendio di CPU; rimane comunque un ottimo esempio di portabilità elevata attraverso un framework condiviso, anche se nello specifico è necessaria una Java Virtual Machine diversa per ogni macchina e installata per eseguire i codici Java.

V HIC SUNT LEONES
1. Formazione permanente

Educazione e formazione sono due elementi cardine dell’economia dell’era informazionale.
È evidente, ad esempio, che una scuola situata in una condizione di isolamento relazionale, in un mercato sempre più improntato alla trasmissione dell’informazione, non riuscirà a fornire le capacità di interagire con il mondo circostante: si trasformerà quindi in un terreno fertile per la cosiddetta “irrilevanza sociale” (1).
Simili analisi sono valide e condivisibili per quanto riguarda la sistematizzazione di alcuni processi; decisamente meno convincenti sono però le conclusioni.
Sottolineare l’importanza della condivisione e del networking, ribadendo però continuamente il ruolo di garanzia delle istituzioni, conduce sempre a sostenere la possibilità di formare persone per un “altro capitalismo possibile”. L’ottica proposta rientra a pieno titolo nei meccanismi di mercato e di produzione, anche informazionale: è improntata al consumo e basata pur sempre su modelli statici e repressivi, come solo lo possono essere le istituzioni e il loro sistema di rappresentanza e delega.
La rivalutazione della “democrazia reale” sembra essere il leitmotiv dell’intellighenzia socialdemocratica, ben decisa a conquistarsi la maggiorità ancor prima della maggioranza; questo orientamento non si pone affatto problemi riguardo invece a percorsi che – ben più profondi e critici – tendono a invertire il senso: non una base più ampia, che garantisca maggior consenso e dunque maggior potere, ma più basi autogestite, fittamente intrecciate fra loro in contesti di affinità (2).
La formazione, una delle chimere dell’era informazionale, considera l’utente come produttore e consumatore: sfuma le differenze, finge di ampliare le scelte, salvo poi ridurle a quelle realizzabili, praticabili sul mercato. Questa formazione serializzata e l’educazione alla disponibilità totale tende a trasformare anche il tempo dell’ozio – in generale il tempo “improduttivo” e “libero” – in una produzione “sistematica” attraverso il consumo, l’enfasi sull’occupazione e la chiusura della proprietà delle informazioni.
Nell’ambito tecnologico un esempio paradigmatico è quello delle patenti europee informatiche (ECDL): un attestato che rivela non capacità critiche ma un utilizzo da automa del computer, con Windows come solo sistema operativo. La patente di guida del computer è limitata quindi solo all’uso e non certo alla comprensione di come funziona una macchina, al porsi domande, a percepire la possibilità di una formazione permanente di ben altro livello, che le comunità invece sono in grado di creare.
Viviamo in un’epoca di produzione su larga scala anche relativamente alle competenze, tesa alla creazione di produttori e consumatori degli stessi prodotti, alla rincorsa costante degli aggiornamenti, perché la formazione permanente – ma, come per le merci, non durevole nel tempo, nonostante i buoni auspici socialdemocratici – rimane poco interessata alla competenze e all’interdisciplinarietà. Ciò che conta non è l’individuo, ma piuttosto il circolo “virtuoso” (per il mercato) di creazione di nuove identità (profiling) e bisogni, tanto per chi deve formarsi, quanto per i consumatori finali (3).
La formazione permanente, ai valori del mercato e della globalizzazione nelle sue accezioni più becere, è uno degli strumenti più sottili ed efficaci attraverso i quali le odierne società di massa producono l’atomizzazione e il silenzioso consenso per una gestione più comoda, ma democratica... della cosa nostra pubblica (4).
Le comunità digitali in questo senso sono un esempio di formazione permanente autorganizzata che si sostituisce in parte allo stato, al pubblico. Il concetto stesso di welfare, da lungo tempo ormai comatoso, non pare possa essere resuscitato da quelle componenti formative (le comunità, l’auto apprendimento scelto dal singolo), le quali però in pratica sono in grado di sostituirlo senza creare dipendenza da un organo istituzionale, che forma per produrre e al contempo esclude dalla libertà di cercare forme alternative. Né la socialdemocrazia, né tanto meno le prospettive liberali di promozione del terzo settore, del no profit, e di sviluppo di economie civili (5) offrono alternative soddisfacenti.
La direzione dell’educazione globalizzata produce atomizzazione e alienazione: è centrale la conoscenza privata nel mondo del lavoro, fatto di skills e forte verticalizzazione delle competenze, senza alcuna possibilità di condivisione; anzi, proprio l’esclusività delle conoscenze offre o preclude la possibilità di accedere al lavoro.
Formazione al sistema, da un lato; dall’altro, atomizzazione individuale. Gli individui sono guidati, attraverso consigli suadenti e luccicanti (pubblicità e advertising in genere), ma anche grazie a strumenti di coercizione e terrore piuttosto rozzi (lo spauracchio della disoccupazione, della povertà, della recessione e dell’esclusione), su un terreno di accettazione formale dello status quo. In questo modo, nessuno è spinto a mettere in dubbio i dogmi della produzione ad ogni costo. Eppure, più produciamo, meno abbondanza sembra esserci: stranamente, siamo sempre in una società della scarsità. Le specificità, irrigidite in compartimenti stagni, favoriscono una situazione di consapevole assenso a qualunque proposta. Va tutto bene, caro consumatore utente! Stai tranquillo!
Il consumatore consuma un prodotto. L’utente usa un servizio. Il servizio è fornito dallo stato, dalle istituzioni. Nel caso della rete di internet non solo consumatore è un termine inadatto, perché propriamente parlando non si consuma nulla, ma anche l’utente si relaziona con comunità, aziende e istituzioni più o meno strutturate e intrecciate fra loro.
La pericolosa scommessa della strategia Open Source è proprio questa: oscillare continuamente fra la rassicurante proposta di democrazia controllata della maggioranza e l’efficacia, rapida e adeguata, del modello aziendale.
L’Open Source infatti riesce a coniugare una concreta possibilità di scelta fra strumenti “aperti” e la “razionalità” economica classica. Nessuna contraddizione, nessuno scontro. L’esempio più chiaro è la strategia di Apple: offrire non solo prodotti tecnicamente all’avanguardia, ma anche altamente usabili dal grande pubblico, con uno studio ergonomico perfetto alle spalle, e la possibilità di personalizzare la propria macchina fin nei minimi dettagli, utilizzando addirittura software libero, come nella migliore tradizione hacker (6).
Come abbiamo anticipato nel capitolo precedente, in uno scenario desolante di “capitalismo dal volto umano”, una via di uscita sembra intravedersi: la scelta personale.

2. Origini: metodi e scelte

La formazione attuale si picca di istruire, ma certo non mette in discussione origini e modalità di trasmissione dei saperi: è molto concentrata sull’esito, poco sui metodi e processi.
L’hacker, nella rete priva di stato e organi istituzionali, trova nella comunità e nel concetto basilare di meritocrazia continui stimoli alla preparazione e alla formazione, sia sotto forma di aggiornamenti tecnici, ottenuti dalla condivisione (sharing) di competenze, sia sulla storia di cui fa parte, ovvero quella delle comunità hacker e delle sue caratteristiche etiche.
Idealizziamo la figura dell’hacker. Studio appassionato, scelte di autoformazione fuori dal mercato, curiosità e scambio con le comunità di riferimento, reti di relazioni ampie e variegate. L’hacker non si accontenta di racconti, veritieri o meno, ma ha bisogno di scorgere la fonte, di toccare con mano la sorgente, l’origine. Metterci sopra le mani.
Questo è lo spirito della formazione che ci piace: poter aprire, vedere dentro, quanto ci viene raccontato, con la possibilità di risalire alla fonte e poter reinterpretare quanto appena appreso, stratificare le conoscenze individuali e contribuire a quelle collettive.
La scelta di un utente nell’utilizzo di un software libero, rispetto a uno proprietario, va nella stessa direzione, quella di riappropriarsi dell’origine, del codice.

3. Auto–formazione

Si delinea un modello di formazione molto distante da quello proposto dalle élites tecnoburocratiche. Cerchiamo di scandirne i momenti: riappropriazione, rispecchiamento (modifica e personalizzazione), rappresentazione; nel complesso questo processo di formazione crea un equilibrio omeostatico (7) fra i singoli individui e le comunità a cui appartengono.
Lo scarto fondamentale rispetto alla formazione permanente globalizzata è la scelta. Restringiamo momentaneamente la prospettiva al coder puro, colui che scrive codice. Il coder sceglie di partecipare a un progetto, o di crearne uno nuovo, spinto essenzialmente dal proprio gusto personale, da un desiderio di creazione nel quale investe il proprio tempo e la propria intelligenza. Il primo passo è senz’altro “metterci sopra le mani”, in senso hacker: un movimento di riappropriazione, smontaggio e comprensione di un oggetto. L’individuo, in questo contesto, non è affatto una tabula rasa da formare secondo un paradigma calato dall’altro, ma si auto–forma sperimentando, ampliando in continuazione la propria “cassetta degli attrezzi”. Perciò è innegabile che un coder venga profondamente influenzato dallo stile di altri coder, dalle modalità di risolvere un dato problema, dalla struttura di alcuni algoritmi che trova particolarmente interessanti e funzionali.
In un secondo momento, lo stile personale che il coder sviluppa, che rispecchia la sua personalità, trova posto in un contesto di condivisione: il codice che crea entra in un circolo comunitario, viene condiviso e influenza a sua volta lo stile di altri coder. I codici rispecchiano gli individui che li creano, e informano di sé, modificandole, le comunità che implementano o anche semplicemente utilizzano quel codice.
Naturalmente le cose si fanno assai più complesse se consideriamo che i coder puri sono animali rari, come del resto la purezza in sé non è una caratteristica saliente di nessun individuo particolare (a meno che costui non l’abbia coscientemente scelta per autodefinirsi). È difficile che un coder scriva solo e sempre codice nella sua vita, cioè, estendendo il concetto, è quasi impossibile che un individuo possa essere descritto completamente da una sola qualificazione. Probabilmente farà anche altre cose, diverse in diversi momenti della sua vita, come ogni individuo è indescrivibile da un solo punto di vista: sarà situato fisicamente, sessualmente, linguisticamente, politicamente, storicamente, ecc.
Banalmente, mentre un atomo formato in permanenza a essere il più possibile intercambiabile con qualsiasi altro atomo deve sviluppare caratteristiche standard per essere appetibile (al mercato globale), un individuo sarà invece tanto più interessante per le comunità e per gli altri individui quanto più unico, dotato di caratteristiche particolari, miscela irripetibile di differenti ingredienti ed
esperienze. È probabile dunque che un individuo appartenga a diverse comunità contemporaneamente (culturali? politiche? tecniche?).
Appartenere a una comunità significa allora senz’altro sentirsi rappresentati da quella comunità, e non certo perché si ha diritto di veto o potere di voto, ma perché si influenza direttamente l’immagine della comunità stessa, si influenzano gli altri individui attraverso le proprie creazioni, e ci si fa influenzare da loro. Si cambia, e si inducono cambiamenti. Autoformazione significa farsi individui nel farsi comunità.
Nel momento in cui la comunità, per una serie di ragioni, non rispecchia più la propria individualità, le possibilità sono molte: creazione di una nuova comunità (forking) (8), introduzione di nuovo codice che ci rappresenti maggiormente, ecc. Si tratta in ogni caso di un equilibrio dinamico, di una omeostasi e rinegoziazione continua della propria individualità e della conformazione della comunità nel tempo.
Non si possono immaginare individui statici che intervengono in comunità perfettamente e compiutamente codificate, aderendo totalmente a un manifesto o a una dichiarazione d’intenti (o a una costituzione e relativo corpus di leggi, se ci forziamo a immaginare uno stato come una comunità), sottomettendosi al diktat della maggioranza o peggio a leggi teoricamente uguali per tutti, ma mai effettivamente negoziate dai soggetti. La formazione invece deve necessariamente investire l’individuo e la comunità, avere il coraggio di immaginare nuove vie di fuga, nuove possibilità di individuazione – poiché si cresce, si muta – che non siano flessibilità totale all’inflessibile mercato, ma operazioni di riappropriazione, rispecchiamento e dunque rappresentazione di sé in un contesto comunitario.

4. Scarti e vie di fuga: lo stile

Immaginare percorsi di autoformazione significa dunque operare scarti rispetto a una presunta norma. In ambito software, immediatamente, il pensiero va all’organizzazione di corsi a diversi livelli; alla scrittura di manuali, how–to, guide; all’utilizzo di strumenti di scrittura e creazione comunitari; a possibili laboratori ed esperimenti per risolvere problemi pratici o anche solo per giocare con una nuova tecnologia. L’idea che attraverso metodi condivisi sia possibile aumentare e stratificare il livello complessivo di competenze – ma soprattutto di piacere che una determinata attività crea – riposa sulla convinzione che le conoscenze possano e debbano essere il più possibile
diffuse e contaminate e non appannaggio di un’élite di tecnocrati. Se una conoscenza non è comunicabile, nella migliore delle ipotesi è un bel gioco solitario, nella peggiore è uno strumento di potere potenzialmente pericoloso e repressivo. La condivisione è la migliore garanzia che abbiamo.
Naturalmente, poichè non tutto si può dire con un codice qualsiasi, ma esistono codici più o meno appropriati a seconda del target che si vuole raggiungere, il “come” si comunica una conoscenza è fondamentale almeno quanto il “cosa” si comunica. O, per meglio dire, si tratta di due facce della stessa medaglia.
Questo “come”, cioè lo stile, il metodo, è il discrimine essenziale nell’utilizzo di un codice. Dal punto di vista dell’utente, che al di fuori dell’ambito informatico diventa il “ricevente” del messaggio, lo stile è la modalità con cui un contenuto gli viene passato. Nella realtà, spesso, il messaggio passa nei due sensi, ovvero accade che l’utente risponda al creatore del codice. Nell’ambito di mercato, si tratta del noto meccanismo per cui l’utente (consumer), specie se evoluto, debugga, avanza richieste di migliorie, ecc., insomma diventa anche produttore (productor), cioè prosumer. Spesso è difficile stabilire dove inizi il circolo fra proposta di un codice, accettazione e modifica, ritorno al creatore, e così via. È interessante notare che più lo stile cerca di facilitare l’utente, rendendo semplice e fruttuoso un suo feedback, più si creano dinamiche collaborative che migliorano il codice.
Dal punto di vista del coder, invece, lo stile è una specie di biglietto da visita che si trova inscritto in ogni riga del suo codice, disponibile per chiunque abbia le competenze tecniche per leggerlo e apprezzarlo.
Analizzando lo stile si possono identificare due estremi: un aspetto prettamente ergonomico, cioè come il programma si presenta e come interagisce con l’utente, e uno relativo al codice col quale è stato scritto.
Il primo aspetto definisce i canoni di una interazione utente–software, può presentarsi come la sintassi di un file di configurazione, una interfaccia testuale, un sistema di login o differenti approcci a seconda della funzionalità e del target degli utilizzatori.
Il secondo elemento, invece, riguarda il rapporto tra coder e software: il suo stile si manifesterà nell’indentazione, nella struttura delle routine, nella qualità dei commenti, nella pulizia complessiva del codice, ecc.
Si può dire quindi che lo stile risponda al complesso dei propri immaginari, al metodo di realizzazione concreta del desiderio di creazione di un oggetto.

5. Tracciare rotte, costruire ponti, declinare immaginari

Evidenziare l’importanza dello stile, cioè del “come” si fanno le cose, implica senz’altro una grande assunzione di responsabilità da parte dei singoli. Non è indifferente dire o fare in un modo piuttosto che in un altro. E non esistono certificazioni che garantiscano la “riuscita” di un codice. Se però osserviamo, come abbiamo cercato di fare finora, come si muove l’ambito informatico, notiamo una dinamica ricorrente.
Tendenzialmente gli informatici amano costruire ponti. Amano immaginarsi collegamenti inediti fra gli strumenti che usano e dai quali traggono piacere. Questi “ponti” normalmente servono per farci scorrere gente.
La gente siamo noi quando scopriamo che da oggi Open Office ha il supporto per il db mysql (ODBC) e permette di estrarre dati da tabelle di un database anche remoto. L’utilità è dettata dalle necessità che ogni utilizzatore riesce ad immaginarsi: stampare etichette di una rubrica, come gestire un layout grafico di documenti fiscali, ecc.. L’unione di due elementi apparentemente troppo distanti provoca uno stimolo a ricercare utilizzi di questa nuova tecnica.
Si possono immaginare un numero enorme di applicazioni di questi “ponti”: la curiosità, l’immaginazione sono sempre in primo piano.
Esistono poi ponti che la gente non percorre ma che i programmatori percorrono. Un ponte può unire al linguaggio di scripting PHP il supporto per le librerie grafiche GTK. PHP nasce come linguaggio per il web. Le librerie GTK servono per scrivere interfacce grafiche in C e C++. Grazie a questo ponte, altri programmatori potranno scrivere applicazioni grafiche, basta che conoscano il PHP: non è più necessario che conoscano a fondo linguaggi complessi come il C.
Poi, per ultimo, esistono ponti fatti per non essere percorsi. Costruiti forse solo per gioco, perché l’idea di un ponte, una volta immaginata, è piacevole da realizzare a prescindere dai possibili usi. Un esempio assurdo, inserire in brainfuck (9) la possibilità di usare le syscall di Linux. Ovvero poter utilizzare le chiamate proprie del kernel (connessioni a internet, gestione del filesystem, accesso a periferiche ed altro) in un linguaggio Turing–completo come brainfuck che ha solo otto istruzioni possibili e che per sua natura nasce come pippa mentale (da cui il nome).
La strategia del “ponte” è un modo di declinare la propria immaginazione e di collegarla agli altri. Quanti ponti si possono costruire, quanti codici si possono collegare?
Abbiamo molto da fare, molto da imparare, molti desideri da realizzare.

note:
1 . Manuel Castells, La città delle reti, Marsilio, Padova, 2004
2 . SITOGRAFIA: Modelli: Rete – Tela. Da Hakim Bey alla metafora del tessere nel discorso femminista contemporaneo.
3 . Il metodo di profilazione di nuove identità nel mondo del software è addirittura banale: campagne sulla proprietà del software, sul tempo che corre rapido e in cui è necessario essere aggiornati. Si va dalle nuove release dei software proprietari, nuovamente da imparare e conoscere, oltre che acquistare... fino ai nuovi virus da cui ci si deve proteggere, o al nuovo gadget tecnologico assolutamente irrinunciabile per essere “in time”. Pare sia necessario essere rapidi nel capire i tempi e, soprattutto, bisogna correre da soli: il mondo del lavoro è la giungla, l’oceano infestato dagli squali che bisogna saper azzannare con più ferocia per non soccombere. Sopravvivenza, è la parola d’ordine; la progettualità, la capacità d’immaginare e creare non ha spazio alcuno.
4 . SITOGRAFIA: Cristopher Lasch, da sorvegliare e punire al controllo morbido. Christopher Lasch (1932–1994) è stato professore di storia all’Università di Rochester. Nelle sue opere, in particolare L’io minimo – La mentalità della sopravvivenza in un’epoca di turbamenti, Feltrinelli, Milano, si delinea fra l’altro la tragicomica vicenda dell’io occidentale, l’ex homo faber del proprio destino: se la vita quotidiana diventa un esercizio di mera sopravvivenza, è necessaria la costruzione di una micro–identità (l’io minimo, appunto) funzionale alle difficoltà del presente e alla perpetuazione del sistema. Tragicommedia, perché le chiavi di lettura del mutamento approntate da Lasch si riferivano al desolante panorama del reganismo rampante, eppure si attagliano alla perfezione anche al panorama odierno, oltre vent’anni dopo. Le famiglie teledipendenti partecipano ai telequiz: se rientrano nella maggioranza, vengono fornite di servizi (gas, acqua, elettricità); se minoranza, i servizi vengono loro negati. Si tratta di una fiction romanzesca (Stefano Benni), ma in realtà il modello di democrazia standard permea anche la formazione informatica delle proprie caratteristiche escludenti.
5 . Si veda l’impostazione liberale ad esempio in Stefano Zamagni, Per un’economia civile nonostante Hobbes e Mandeville http://www.pust.edu/oikonomia/pages/2003/2003_ottobre/studi_2.htm (cache)
6 . La maggioranza che accetta gli standard – a proprie spese, ben inteso – è spinta a imparare la vulgata, duratura quanto la nuova release (gli artefatti digitali presentano un altissimo grado di depauperabilità) degli strumenti su cui si forma; chi si posiziona fuori da questo raggio è costretto a cercare altrove le proprie istanze formative.
7 . SITOGRAFIA: L’omeostasi. Il concetto di omeostasi, per indicare un equilibrio dinamico, viene utilizzato, al di là dell’ambito biologico che l’ha coniato, anche nella sistemica e nella cibernetica in particolare. Avendo a che fare con le relazioni fra macchine e esseri umani, non è un caso che la cibernetica si interessi altrettanto di “riflessività” (intesa come meccanismo di retroazione) e di “emergenza” (l’esplosione della complessità, dati elementi “semplici”). Tuttavia, dato l’evidente obiettivo e interesse militare di questi studi, si preferisce qui tralasciare ogni parallelo eccessivamente stringente. Più interessante potrebbe essere un riferimento al pensiero sulla tecnica e la modernità di Bruno Latour, ma soprattutto di Gilbert Simondon a proposito dei processi di individuazione e scambio individuo–comunità, al di fuori naturalmente dalle forzature postmarxiste a cui è già stato ampiamente sottoposto. Si vedano in particolare Gilbert Simondon, L’individuation psychique et collective, Paris, Aubier, 1989; Du mode d’existence des objets techniques, Paris, Aubier, 1989. Esempi di forzature improprie: http://multitudes.samizdat.net/article.php3?id_article=1563 (cache).
8 . SITOGRAFIA: Forking. A volte capita anche il contrario: una comunità che si divide perché parti di queste arrivano a tensioni non sanabili. Il forking si verifica appunto quando una parte di una comunità occupata in un progetto già avviato, si distacca dal nucleo di programmatori per creare una versione diversa del software. Il forking è successo a molti progetti conosciuti come Emacs, l’editor di Stallman, Xfree, il server grafico di Linux, The Gimp, software di manipolazione d’immagini. Le ragioni di questi scissioni sono varie: una parte della comunità di Xfree, ad esempio, si è staccata dal progetto padre per generare xorg, a causa di un cambio di licenza. Oppure, si veda il caso di The Gimp: da una versione di Gimp si è evoluto Cinepaint per problemi relazionali tra mantainer. Ora The Gimp è il programma più utilizzato dai grafici sotto GNU/Linux, mentre Cinepaint è il software di effetti su animazioni utilizzato a Hollywood.
9 . Brainfuck: http://en.wikipedia.org/wiki/Brainfuck; http://www.muppetlabs.com/~breadbox/bf/

APPENDICI
I – Appendice GLIBC

Per avere una panoramica delle tipologie di comunità, bisogna tornare al 1991, quando Linus Torvalds inizia il suo kernel e fonda la prima comunità basata sul concetto del “bazar”. Abbiamo visto che il metodo precedente a “cattedrale”, tipico della comunità GNU, muta rapidamente in questa nuova direzione.
Ancora oggi sussistono esempi sporadici di progetti strutturati a “cattedrale”; si tratta però di casi davvero rari e a volte folcloristici: citiamo il progetto qmail, un server di posta distribuibile solo in versione sorgente e modificabile solo dall’autore stesso, poiché in caso contrario occorrerebbe forkare (scindere) il progetto.
Il passaggio da “cattedrale” a “bazar” non è stato certo morbido ed indolore, come testimonia ad esempio la crisi sulle glibc (librerie di base che permettono ai programmi di interagire al più basso livello con il sistema) del 1991.
La GNU stava combattendo una guerra soprattutto politica e ogni rilascio di codice di un nuovo programma rappresentava la vittoria di un’altra battaglia verso il Free Software; la nascente comunità Linux, invece, era completamente concentrata sulla tecnica: stava scrivendo un kernel e il suo obiettivo era che questo fosse il più possibile completo, performante e fruibile.
La comunità Linux era molto attiva e in espansione vertiginosa; tra l’altro, continuava ad aggiungere chiamate di sistema al nuovo kernel, ma lo sviluppo delle glibc non riusciva a stare dietro allo sviluppo complessivo.
Dopo un paio d’anni, alcuni programmatori del kernel si spinsero dunque a ipotizzare un fork del progetto glibc, in modo da assumere questo progetto all’interno della nuova comunità.
Per comprendere l’estrema novità di una simile ipotesi, bisogna ricordare che in un sistema Posix i software comunicano col kernel grazie alle librerie base del sistema. Sul sistema GNU/Linux questo rapporto di comunicazione viene espletato da Linux e dalle glibc. Le glibc sono sviluppate dal gruppo della FSF, con lo scopo tecnico e politico di creare l’humus necessario al rapporto di interdipendenza e quindi di massima condivisione tra gli sviluppatori di sofware applicativo e quelli del kernel.
Nel 1993 la comunità delle glibc, strutturata ovviamente a “cattedrale”, non si aspettava che il progetto Linux sfornasse codice a tale velocità; poichè non riusciva a stare dietro agli aggiornamenti, i software esistenti si trovavano in difficoltà quando desideravano usare le nuove funzionalità via via proposte dal kernel.
Il fork poi non è avvenuto, e ora abbiamo un sistema operativo che funziona grazie a questi due elementi quasi in simbiosi con risultati più che discreti; però si può ben dire che c’è mancato poco e non era affatto scontato. È stata l’opera di diplomazia tecnico–politica delle due comunità e sicuramente dei due mantainer, Torvalds e Stallman, a evitare una spaccatura che non si sarebbe più potuta sanare.

II – Appendice “Le librerie QT”

Nel 1996 Matthias Ettrich avviò il progetto KDE basandolo sulle librerie grafiche QT.
All’epoca, non esisteva nessun framework per sviluppare un desktop in grande stile, fatta eccezione per le appena nate librerie GTK, immature e per questa ragione non ancora completamente affidabili. KDE scelse di usare alcune librerie commerciali totalmente compatibili per X, sviluppate close dalla TrollTech, assumendosene l’onere tecnico e politico.
Nonostante la KDE si fosse prodigata nel fondare la KDE–QT Free Foundation – che impegnava la TrollTech a rilasciare le QT sotto licenza BSD nel caso in cui lo sviluppo si fosse fermato –, parte del mondo libero e in particolare i più intransigenti della GNU, non videro di buon occhio questo progetto; tuttavia, già dalla versione 1.0 le QT si guadagnarono meriti tecnici.
All’uscita della nuova versione, infatti, Stallman attaccò ferocemente il progetto KDE, accusando il gruppo di avere illegalmente compilato codice libero a codice commerciale: questo di norma è permesso solo in relazione a librerie fondamentali di un sistema operativo.
L’obiezione fu subito: come è possibile decidere che cosa è fondamentale? Chi prende questa decisione? Il panorama dei framework grafici si stava evolvendo lentamente e la versione 1.0 delle GTK non era assolutamente paragonabile alle QT 2.0.
Inoltre a partire da questa versione la licenza close utilizzata da TrollTech passò a QPL che per quanto limitasse ancora molto i metodi sviluppo era compatibile con lo standard Open Source (ovvero approvata dalla OSI).
Intanto era nato il progetto Harmony o Free–QT dagli stessi sviluppatori KDE, un tentativo di recuperare lo strappo nei confronti della GNU attraverso l’ulteriore la scrittura di liberie compatibili con le QT e che svolgessero la stessa funzione.
Dopo pochi mesi la FSF si occupo’ in prima persona di portare avanti il progetto Harmony. A bloccare Harmony, facendo contemporaneamente decadere le nuove polemiche sorte intorno alla QPL, fu la stessa TrollTech, che dopo pochi mesi cambiò nuovamente licenza alle sue liberie portandole a GPL.
La risposta di Stallman fu chiedere al progetto KDE che facesse pubblica ammenda nei confronti dell’intero mondo Open Source, cosa che peraltro non avvenne mai. Si veda http://www.kde.org/announcements/announcement.php (cache)

OGGETTI GRAFICI

Gli oggetti grafici qui riprodotti sono mappe delle relazioni che abbiamo cercato di mettere in luce nel testo: rappresentano alcuni dei nodi problematici più interessanti, alcuni degli ingranaggi più significativi della gigantesche macchine che popolano i mondi digitali.
La forma degli oggetti non è casuale: sono reticolari se descrivono comunità aperte, più o meno orientate in maniera unidirezionale se si tratta di comunità maggiormente gerarchizzate.
La mappa sinottica vuole evidenziare le relazioni fra i molteplici attori in gioco. Una precisazione: la forma risultante ci sembra quella di un assedio. In effetti, la libertà del free software, come ogni libertà, e' frutto di continui mutamenti, aggiustamenti, contaminazioni e rinegoziazioni di senso, fra comunità e individui. Tuttavia, quando la contaminazione viene semplificata, i piani vengono schiacciati e ridotti all'unità, nello specifico l'unità dell'approccio mercantile, siamo di fronte a un tentativo di fusione, di normalizzazione (infatti si parla di primato dell'economia, ovvero della "norma, legge"), di riduzione: è il pensiero unico che chiama a sé. Per questa ragione, crediamo, ricomponendo le varie mappe, l'immagine complessiva e' quella di un assedio: l'assedio normalizzante, totalitario e banalizzante dell'economia sopra tutto e ad ogni costo, dell'ideologia del mercato, che media ogni cosa, e cerca di riassorbire in un'unica, noiosa direzione i movimenti delle tribù nomadi, desideranti e libere delle reti.

GLI AUTORI

Ippolita è un server e una comunità di "scriventi", un crocevia per condividere strumenti e competenze tra il linguaggio del digitale e il linguaggio della scrittura.
Come autrice di questo libro, è un nome collettivo che racchiude l'espressione delle competenze usate per la stesura del testo, della sitografia e delle mappe proposte. www.ippolita.net