ippolita.net // The Dark Side of Google // Capitolo 3

III. Google Open Source: teoria e pratiche

Open non è Free

Free Software[1] (Sofware Libero) e Open Source[2] (Sorgente Aperto) sono sintagmi usati spesso come sinonimi per indicare codici o porzioni di codici informatici; tuttavia, per quanto descrivano oggetti spesso identici, rispecchiano prospettive radicalmente differenti. Free Software è un termine nato agli inizi degli anni Ottanta per iniziativa di Richard Stallman: si riferisce alla libertà dell’utente di usare e migliorare il software. Più precisamente, può essere riassunto in quattro libertà fondamentali:

1) Libertà di eseguire il programma, per qualsiasi scopo.

2) Libertà di modificare il programma secondo i propri bisogni (perché questa libertà abbia qualche effetto in pratica è necessario avere accesso al codice sorgente del programma, poiché apportare modifiche a un programma senza disporre del codice sorgente è estremamente difficile).

3) Libertà di distribuire copie del programma gratuitamente o dietro compenso.

4) Libertà di distribuire versioni modificate del programma, così che la comunità possa fruire dei miglioramenti apportati.

L’espressione Open Source, invece, nasce alla fine degli anni Novanta, per iniziativa in particolare di Bruce Perens e Eric S. Raymond, che nel 1998 fondano la Open Source Initiative[3] (OSI); si riferisce alla Open Source Definition, a sua volta derivata dalle Debian Free Software Guidelines, ovvero una serie di 10 punti pratici che definiscono quali criteri legali debba soddisfare una licenza per essere considerata effettivamente “libera”: o meglio, con il nuovo termine, Open Source.

È evidente quindi che da una parte il Free Software pone l’accento sulla libertà: come sottolineato nella definizione, “il Software libero è una questione di libertà, non di prezzo”[4]. Dall’altra parte, l’Open Source si occupa esclusivamente di definire, in una prospettiva totalmente interna alle logiche di mercato, quali siano le modalità migliori per diffondere un prodotto secondo criteri open, cioè aperti. Il Free Software ha un senso che va ben oltre il mercato, pur non escludendolo a priori; l’Open Source esiste, come specificato dai suoi stessi promotori, per adattare un modello preesistente (quello “free” nel senso di “libero”) al mercato.

Gli hackers di Stanford

Ormai da alcuni anni il software Open Source viene considerato comunemente affidabile, capace di prestazioni elevate e a costi sostenibili; in pratica è oggi spesso considerato migliore rispetto ai software proprietari, proprio perché in grado di aumentare l’affidabilità di un prodotto soprattutto in virtù di una metodologia differente di sviluppo, aperta e sottoposta a un meccanismo molto ampio di revisione.

Grazie alla realizzazione di software stabili e funzionali come browser, programmi per ufficio, editor e interi sistemi operativi (GNU/Linux), quasi ogni utente si è accorto o ha sentito parlare dell’esistenza dei programmi detti genericamente copyleft o Open Source.

Open Source era il termine adatto, e necessario, per sostituire la dicitura Free Software. In inglese infatti la parola Free ha il duplice significato di Libero e di Gratuito: questa ambiguità linguistica rendeva il prodotto poco appetibile dal punto di vista economico. La sostituzione con Open fu un modo strategicamente vincente per mantenere le caratteristiche di cooperazione libera senza rinunciare alla possibilità di un uso più strettamente commerciale dei software.

All’epoca, in realtà, si stava assistendo a un cambiamento radicale nell’assetto delle comunità digitali spontanee, cioè quelle comunità a cui si sentono legati tutti coloro che danno una definizione positiva di hacking.

Questi aggregati erano (e lo sono ancora) estremamente compositi. Ci riferiamo a un interstizio culturale fluido nel quale si formano e collaborano studenti, professori, ricercatori, liberi professionisti, polizia e criminali, programmatori stipendiati da società di sviluppo, appassionati e molte altre tipologie di hacker.

Il movimento del Free Software stava cominciando un confronto serrato con l’economia di mercato.  La battaglia della Free Software Foundation verteva sulla diffusione della licenza GPL (General Public License), creata dal fondatore della FSF Richard Stallman[5]; tale licenza vincola l’artefatto in modo “virale” alle quattro libertà sopra elencate. In sostanza ogni modifica apportata a codice sotto licenza GPL deve mantenere la stessa licenza d’uso, rendendo impossibile la chiusura del codice; questo meccanismo è noto come “permesso d’autore” (copyleft, gioco di parole su copyright). Nascevano e si diffondevano allora le prime distribuzioni del sistema operativo GNU/Linux.

La commistione tra metodo di sviluppo libero e net-economy avrebbe determinato negli anni successivi al 2000 l’esplosione dei prodotti Open Source e allo scatenarsi del dibattito politico circa la brevettabilità del software, il copyright e alla gestione etico-politica di tutto ciò che attualmente definiamo opera d’ingegno umano.

L’azienda Google, per quanto non sia direttamente un produttore di software, non è rimasta ai margini dello scossone Open Source: come altre aziende dinamiche e innovative, Google ne ha cooptato le metodologie e le ha poste al servizio della sua “missione”.

La contiguità fra Google e Open Source è spaziale e temporale: nel 1998 a Stanford, proprio mentre Brin e Page mettevano a punto la prima versione del loro motore di ricerca, stavano emergendo alcuni importanti progetti Free Software; ricordiamo ad esempio SND e Protegè che, in campi molto differenti, ovvero l’audio e il web semantico, avrebbero riscosso grande successo sulla scena digitale.

A Stanford la cultura hacker, da cui deriva in ultima analisi l’Open Source, si respira come un’aria di famiglia: non è dunque un caso che il nostro duo formatosi in quegli anni abbia sempre manifestato una certa predilezione per lo sviluppo su piattaforma GNU/Linux.

Se esistono differenze sostanziali tra Open Source e Free Software, vi sono però anche elementi in comune e continuità di vedute. Per semplicità e correttezza parleremo perciò di “metodologie e pratiche aperte”, in breve di Open Source, per indicare il fenomeno che interseca Free Software, Open Source e competizione di mercato nel mondo dell’IT.

La prima caratteristica di una comunità Open (ma in questo senso anche Free) è quella di mettere in pratica un metodo di lavoro aperto alla collaborazione di tutti, capace cioè di accettare suggerimenti e interazioni spontanee da ogni tipologia di soggetto coinvolto nella costruzione dell’artefatto informatico: programmatore, traduttore, o anche semplice utente. Questo procedimento è stato definito nel gergo hacker metodo a “bazar” e la sua applicazione su vasta scala si deve allo sviluppo del Kernel Linux nei primi anni Novanta, un progetto nato per iniziativa di Linus Torvalds e base di tutte le distribuzioni GNU/Linux[6].

La nuova tecnica cooperativa proposta dall’underground digitale ha rovesciato la legge di Brooks[7] che regolava le comunità di sviluppo dei progetti informatici fino a quel momento. Secondo la legge di Brooks, con il crescere della complessità aumentano esponenzialmente gli errori e quindi un progetto a cui contribuiscono migliaia di sviluppatori avrebbe dovuto essere un’accozzaglia di codice instabile e pieno di bug. Invece, attraverso la resa pubblica dei codici sorgenti, la circolazione libera su internet della documentazione, la cooperazione e il feedback spontaneo di un numero sempre più elevato di soggetti in gioco, le comunità libere hanno dimostrato come fosse possibile un enorme miglioramento nella costruzione di artefatti digitali, sia dal punto di vista del risultato, sia del processo. I software realizzati in questo modo vengono generalmente resi pubblici sotto la licenza GPL, che come abbiamo visto diffonde in maniera virale materiali copyleft.

La licenza GPL non prevede quindi restrizioni dal punto di vista commerciale; tuttavia, esattamente come il termine Free Software risultava eccessivamente radicale nel porre le libertà al primo posto, così anche la GPL è stata sostituita da licenze edulcorate rispetto al portato etico e politico che il movimento originario voleva esprimere. È il caso di licenze come la BSD (Berkeley Software Distribution), che non implica alcuna restrizione rispetto alla chiusura dei codici e quindi inibisce la viralità, perché porzioni di codice non libero possono essere integrate nel codice libero. Dunque una creazione libera può diventare proprietaria. Oppure la MPL (Mozilla Public Licence) e altre licenze sviluppate su misura per i nuovi prodotti Open Source.

L’economia di mercato diventa così sviluppo sostenibile e la Community degli sviluppatori il nucleo di una vera e propria Open Society[8], la chimerica Società Aperta. Questo immaginario è determinato non solo dall’adesione morale che suscita la pratica di uno sviluppo comunitario, ma soprattutto dalla qualità superiore degli applicativi, in apparente contraddizione con  la gratuità delle competenze messe in gioco.

L’era dell’Open Source economy: concorrenza e bontà d’animo

L’ingresso dell’Open Source nel mercato è, secondo alcuni osservatori, una delle conseguenze della cosiddetta «convergenza tecnologica», uno slogan ormai divenuto quasi un paradigma dell’era informazionale: l’avvicinamento e sinergia di varie tecnologie, precedentemente ritenute estranee, studiate e sviluppate in ambiti separati.

Dinanzi a queste trasformazioni spesso estremamente rapide, la creazione di standard aperti ha creato un varco nella “guerra di tutti contro tutti” del cosiddetto “libero mercato”: “cooperate on standards, compete on solution”, è il motto della Ibm, una delle principali imprese coinvolte. Se anche Big Blue decide di cooperare, significa che il gioco vale la candela...

Per molte aziende l’Open Source è infatti una delle poche possibilità per contrastare monopoli e oligopoli ormai consolidati, per sfuggire a dinamiche di competizione classiche senza investimenti enormi, per limitare i costi di sviluppo e quindi diminuire “il prezzo” dei propri servizi .

Le imprese conoscono da tempo e apprezzano il valore di una dinamica reticolare di sviluppo e di alleanze: è ben noto che il valore di una rete è proporzionale al quadrato delle persone/nodi che collega[9]. Una rete sempre più ampia corrisponde dunque a profitti esponenzialmente maggiori.

L’Open Source sembra offrire alcune garanzie rilevanti nello sviluppo di reti ad alto valore aggiunto: da una parte consente al software di rimanere in qualche modo un bene «pubblico» (adotta lo sviluppo aperto e si avvale di comunità di supporto); dall’altra mantiene molto bassi i costi di passaggio da un sistema all’altro (i cosiddetti switching costs), in particolare dai modelli proprietari a quelli aperti, anche e soprattutto nel caso dei sistemi legacy, cioè obsoleti. I costi maggiori nell’adozione di nuove tecnologie sono dovuti alla formazione degli utenti, non all’investimento per l’acquisizione della tecnologia stessa; a maggior ragione se si tratta di software eccellente dal costo risibile.

Ma il risultato più importante, il cui prezzo è difficilmente calcolabile, è la creazione di un’immagine completamente nuova: per la propria azienda e per i propri prodotti.

Il successo delle logiche del software libero ha prodotto diversi tentativi di applicazione delle medesime pratiche in altri settori. Sono stati inevitabilmente coniate nuove espressioni e formulati auspici spesso esagerati: Open Laws, Open Science, persino Open Society sembrano a portata di mano. Oggi infatti l’idea di società Open Source è divenuto quasi un paradigma della nuova era volta alla ricerca di uno strumento comune per una prospettiva politica “possibile”. Per società Open Source si intende infatti una società il cui codice sia aperto e al cui miglioramento possano partecipare tutti liberamente. Messa in questi termini non si può che essere d’accordo. Sorprende però la leggerezza con cui si mutua un termine da un percorso particolare, tecnico e informatico, per renderlo generale, applicandolo a teorie filosofiche, economiche, sociologiche, senza considerare le possibilità di modificare quel concetto o quantomeno utilizzarlo con le dovute precisazioni.

Open Source infatti, nel campo del software in cui è nato il termine, significa anche concorrenza, gare per accaparrarsi i cervelli migliori al minor prezzo, finanziamenti di capitale di rischio, operazioni miliardarie di acquisto e vendita, un grande business orientato a una forma più “democratica” e morbida di capitalismo. Questa dinamica mira non più ad asservire la forza lavoro, bensì a cooptarla nella realizzazione della missione dell’azienda, che si identifica sempre più con la realizzazione dei propri desideri individuali[10].

Tra le tante società che oggi sfruttano quest’onda per ottenere i più diversi vantaggi c’è anche Google che, d’altronde, è buono per motto: perciò, Don’t be Evil, usa il software libero, è gratuito, è migliore di quello proprietario, gli sviluppatori sono fieri di collaborare. La visita a Googleplex ha mostrato chiaramente come a Mountain View questa strategia di penetrazione nelle vite delle persone sia stata affinata al massimo grado: lavoratori gratificati, incoraggiati a essere creativi e felici producono meglio e di più rispetto a lavoratori frustrati e oppressi.

Sedurre gli hackers: autonomia, soldi facili, strumenti gratuiti

Lo sfruttamento dell’Open Source da parte di Google raggiunge l’apice intorno al 2005, quando la sua immagine è stata appannata dalle azioni dei concorrenti e da vicende giudiziarie non cristalline[11].

Per quanto il progetto fosse notoriamente radicato nella cultura informatica e nella pratica dell’eccellenza accademica, non era sufficiente usare il sistema operativo GNU/Linux per far funzionare il datacenter di Google: occorreva esplicitare la fiducia verso l’Open Source con un’iniziativa forte, che richiamasse l’attenzione nel magma delle reti a produzione libera.

Non era più sufficiente offrire il supporto per la lingua h4x0r, il linguaggio dei “veri” hackers, (o per il klingoniano di Star Trek), per accattivarsi le simpatie degli sviluppatori. Inoltre l’atteggiamento elitario da cervelloni universitari cominciava a spazientire gli investitori.

Arroganza e culto meritocratico di derivazione accademica, anche se supportati da risultati sempre ottimali, hanno poco riscontro presso gli investitori che reclamano sostanziosi dividendi. Era inevitabile che si chiudesse la fase in cui i due potevano permettersi scherzosamente di quotare in borsa il titolo ipotizzando azioni per un valore di 2.718.281.828 dollari, un numero che ricalca la costante matematica “e” (la base della funzione logaritmo naturale); o anche uscite balzane come l’annuncio dell’agosto 2005, quando dichiarano che avrebbero venduto 14.159.265 azioni per raccogliere 4 miliardi di dollari di liquidità, senza far parola con gli investitori dell’uso che avrebbero fatto di quel denaro.

Per sostenere concretamente il proprio desiderio di investire in ricerca, per dimostrare come attraverso una simile strategia si possa non solo competere, ma eccellere sul mercato, era necessaria una mossa strategica rivolta non tanto agli utenti “normali”, ma piuttosto ai giovani cervelli, al futuro, all’innovazione; tradotto operativamente questo significa creare comunità, offrire strumenti di sviluppo, stipulare accordi con altre società del settore. Ovvero, corteggiare il mondo dell’Open Source.

Google comincia a investire nella creazione di comunità nell’Ottobre 2005, quando finanzia con 350.000 dollari l’Oregon State University e la Portland State University per migliorare la qualità dei progetti Open Source, favorendo la nascita di nuovi software. Successivamente viene avviato in pompa magna il programma mirato del Giugno 2005: Summer Of Code, cioè “L’estate del codice”, promosso direttamente su una pagina del sito di Google, e ora reperibile su http://code.google.com/summerofcode05.html.

Lo stile comunicativo è chiaro: offrire opportunità ai migliori. Ogni programmatore che avesse creato un progetto Open Source nuovo o apportato una miglioria degna di nota a un progetto già esistente entro l’arco dell’estate, avrebbe avuto un premio di 4500 dollari. L’operazione mirava evidentemente a presentarsi come un’esplicita dichiarazione d’amore verso l’Open Source, ovvero a rimarcare che l’ Open Source era il terreno strategico sul quale coltivare l’innovazione. In secondo luogo, puntava ad attirare le simpatie dei giovani sviluppatori con un’iniziativa di sostegno finanziario concreto al loro lavoro. Infine, cercava di creare una vera e propria comunità nello stile “aperto”, quantomeno relativamente alla sponsorizzazione.

I programmatori premiati, perlopiù studenti, sono stati oltre quattrocento; per la maggiore hanno apportato modifiche e introdotto novità su progetti già esistenti, piuttosto che far conoscere i loro nuovi software, aggiungendo caratteristiche a programmi come Apache, Fedora, Gaim, lo stesso Google, Inkscape, Jabber, KDE, Mozilla, OpenOffice.org, Python, Samba, Gnome, Mono, Ubuntu.  Un bel guadagno per tutti, specialmente per le società che stanno dietro a questi progetti: tra le principali, ricordiamo IBM, RedHat, LinSpire, Novell, Mozilla.com, Sun, HP, Ubuntu[12].

Alcuni di questi progetti, insieme a quelli sviluppati nel famigerato 20% di tempo libero dai dipendenti di Google, hanno permesso il raggiungimento del secondo obiettivo nel percorso di avvicinamento all’Open Source: offrire strumenti di sviluppo. Già dal 2002 Google offriva strumenti di sviluppo scaricabili gratuitamente dal sito code.google.com. Adesso questa pagina contiene i progetti proprietari creati dai team di sviluppo di Google e insieme i progetti vincenti di Summer of Code che sono in qualche modo legati ai suoi servizi.

La sezione “Code” del sito propone alcuni progetti dedicati ai creatori di software nei più diversi linguaggi di programmazione (Java, C++, Python, etc.). Offrire strumenti di sviluppo è un elemento essenziale per chiunque voglia permettere la creazione di software e comunità, perché si investe proprio sui mezzi di lavoro necessari per la loro creazione. I progetti concepiti dai programmatori di Google come strumenti di sviluppo prendono il nome di Google API, librerie proprietarie per interfacciarsi e utilizzare i principali servizi del colosso di Mountain View.

Una libreria è un’insieme di funzioni condivise: si tratta di porzioni di codice compilate che forniscono strumenti ad altri programmi che abbiano la necessità di funzioni semplificate. Un esempio molto intuitivo è costituito dalle librerie grafiche GTK, QT e FLTK, che implementano gli elementi standard di un’applicazione visuale (pulsanti, menù, icone...), semplificando il lavoro dei programmatori: questi ultimi, appoggiandosi alla libreria preferita, scriveranno solo le funzioni reali del programma. Saranno infatti le librerie a disegnare i pulsanti, a gestire i click del mouse, a tracciare le ombre e molto di tutto ciò che siamo abituati a vedere come utenti. Il tempo e le capacità dei programmatori vengono così ottimizzate; poiché chi scrive codice difficilmente sarà entusiasta di creare i bottoncini delle sue applicazioni, le librerie grafiche rivestono un ruolo essenziale di collante fra i vari progetti. Da una parte, le applicazioni risulteranno relativamente omogenee dal punto di vista grafico; dall’altra, i programmatori potranno concentrarsi sul loro lavoro, senza perdere troppo tempo nell’implementazione della interfacce. 

Vi sono comunità di sviluppo che si occupano delle librerie per fornire strumenti generici e trasversali per la risoluzione di 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 quanti più sviluppatori possibile.

Le librerie quindi permettono ai programmatori di creare i propri software partendo da un set di elementi messi in condivisione, veri e propri standard de facto della programmazione. Appoggiarsi alle librerie significa implementare il lavoro avvalendosi di una base di partenza anche molto ampia e complessa, che utilizza al meglio il codice già disponibile e stratifica le competenze. Le librerie hanno quindi un valore strategico sia nelle dinamica di cooperazione spontanea del FS sia nell’economia relazionale dell’OS.

Le librerie di Google, cioè le Google API, sono pubblicate con licenza proprietaria, cioè nascondono al programmatore il meccanismo del loro funzionamento. Ma non è tutto: è presente anche un particolare dispositivo di controllo, infatti lo sviluppatore che scarica gratuitamente le librerie deve autenticarsi attraverso un codice. Questo sistema permette a Google di tracciare in maniera pervasiva tutti i movimenti e le modifiche che derivano dall’uso delle sue API. I programmatori che usano queste librerie hanno l’opportunità di inserire la ricerca di Google nel proprio sito o conoscere in tempo reale il proprio PageRank. Inoltre possono realizzare software capaci di gestire campagne pubblicitarie attraverso AdWords, generare mappe dinamiche dei loro dati con l’interfaccia di Google Maps o anche implementare client VoIP per la telefonia on-line compatibili con GTalk. In breve, possono sviluppare i servizi di Google come meglio credono, nel linguaggio di programmazione a loro più congeniale, sotto l’attenta supervisione di Mountain View.

L’enorme diffusione dei servizi di Google si coniuga con la possibilità di personalizzazione nei minimi dettagli: infatti, mediante la scrittura di appositi documenti XML[13], è possibile creare “ponti” di collegamento fra i diversi servizi di Google; per esempio programmando pezzo per pezzo l’homepage di Google come se fosse un vero e proprio applicativo, rendendola in questo modo del tutto adeguata alle proprie esigenze. Qualcosa di molto simile si può fare con Google Earth: è possibile costruire particolari navigazioni in 3D sulle foto satellitari, evidenziando graficamente sui computer degli utenti ulteriori zone geografiche, edifici, dati climatici, ecc.

Tutti questi strumenti predisposti per chi sa scrivere codice (in almeno un linguaggio) sono essenziali per trovare nuove combinazioni o semplicemente usare ciò che Google rende pubblico, almeno in parte, all’interno di propri applicativi[14]. Esiste addirittura un portale, googleearthhacks.com, dove si possono trovare moltissimi trucchi e hack per utilizzare nei modi più impensati questo servizio, incrociando le mappe satellitari con qualsiasi altro database.

Tutte le possibilità che le API di Google ci offrono implicano il rispetto di due precise regole: la registrazione e la licenza. Per attivare funzioni di Google API infatti è necessario richiedere una chiave, cioè un codice di accesso e comunicare esattamente dove le si vuole impiegare. Le API si attivano solo dopo aver effettuato questa registrazione. Il secondo punto è la licenza. Non avendo una licenza copyleft, queste API si possono utilizzare soltanto nel rispetto di alcune limitazioni:  ad esempio, è necessario avere un account Google, perché l’accumulo di informazioni non si arresta mai; inoltre, le mappe sono di proprietà esclusiva di Google (o di terze parti) e non possono essere modificate in alcun modo. Naturalmente, per usi commerciali è necessario stipulare un contratto. Il codice di attivazione permette a Google di mantenere sempre il controllo totale sui nuovi programmi generati sulle sue API: può bloccare a piacimento gli applicativi o semplicemente controllare sia il modo in cui accedono ai servizi, sia l’uso che ne viene fatto. Tutto questo è possibile perché il codice sorgente non è pubblico e libero e risulta quindi impossibile comprendere il funzionamento interno delle librerie.

Oltre a far sviluppare gratuitamente e a monitorare lo sviluppo dei propri servizi, un altro motivo per cui Google sta creando comunità con questa strana formulazione che potremmo definire pseudo-Open è quello di ottenere un database sul quale fare ricerca e vendita di statistiche.

Ospitare gratuitamente i progetti dei singoli programmatori significa ottenere la loro fiducia. Permettere a chiunque di effettuare ricerche sul database dei progetti ospitati attiva una solida catena di utenti. Una simile incubatrice gratuita di giovani talenti garantisce inoltre la disponibilità di materiale umano fortemente motivato e la cui formazione, ovvero il costo principale nel settore dell’IT, è già stata compiuta in maniera autonoma e del tutto conforme allo stile dell’azienda.

L’offerta di strumenti di sviluppo è un meccanismo di talent-scouting noto da tempo e in particolare è il cavallo di battaglia di alcune solide aziende come la Va Software Corporation, che mette a disposizione gratuita del mondo dell’Open Source computer estremamente potenti e banda larga, spazio disco e assistenza non alla portata di tutti. Due paradisi digitali possono vantare una fama mondiale e un numero di progetti ospitati superiore a ogni altro concorrente: sourceforge.net e freshmeat.net, entrambi di proprietà della Va Software. 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. Tutti i progetti in seno a code.google.com hanno una loro pagina relativa su freshmeat.net e/o sourceforge.net.

In questo modo gli applicativi possono al contempo godere della visibilità di Google e di tutti i servizi messi da disposizione dal colosso Va Software: mailing list, computer dedicati per la soluzione degli errori di programmazione (debug), per sistemi di controllo delle versioni, delle revisioni e dei cambiamenti del codice (ad esempio cvs, Concurrent Versioning System), forum di discussione, ecc.

È semplice immaginare come, con un database utilizzato gratuitamente da migliaia di coder, la Va  Software può garantire un ottimo servizio di business to business per aziende legate al mondo Open Source e non solo. Un data mining di particolare interesse per affari miliardari. Tra gli sponsor e inserzionisti di sourceforge.net e freshmeat.net troviamo Red Hat, Microsoft e molti altri.

Vi sono molti modi per mettere in collegamento gli sviluppatori con le aziende Open Source. In Italia, SUN Microsystem offre la possibilità di pubblicare il proprio curriculum su una mappa di Google (utilizzando le Google API), attraverso il portale javaopenbusiness.it. Sono gli sviluppatori stessi a segnalare il proprio profilo, creando così una mappa delle competenze Open Source in Italia attraverso gli strumenti resi disponibili da SUN e da Google.

Google può quindi contare sull’implementazione praticamente gratuita dei propri prodotti da parte di centinaia di utenti; a questo si aggiunte l’investimento mirato di gare come Summer of Code, festival dedicati alla promozione e sviluppo dei propri servizi e, ultimo ma non meno importante, sistemi di reclutamento eccezionalmente dinamici. Tra questi, si trova anche il video-reclutamento, direttamente sulle pagine di video.google.com, con interviste a dipendenti entusiasti e a Sergey Brin in persona, tutti concordi nell’illustrare i privilegi del lavoro a Mountain View[15].

Ambienti ibridi fra università e azienda

Date queste premesse, l’avvicinamento di Google all’Open Source appare quanto mai strategico e interessato, per quanto senz’altro originato da un comune sentire rispetto alle dinamiche cooperative tipiche delle comunità di sviluppo Free Software, nate nell’humus accademico. La strategia dell’accumulo evidenziata in precedenza è all’opera anche in questo ambito: infatti Google si comporta come una sorta di buco nero che usa codici aperti, o addirittura ne favorisce la stesura e li attira, per poi immetterli nel proprio circuito. Ad esempio, nessuna delle modifiche che i programmatori di Google hanno apportato agli strumenti aperti usati è mai stata resa pubblica. In particolare il loro Google Web Server (GWS) è una versione modificata di una versione di Apache, il server web Open Source più diffuso nella Rete. Questo significa senz’altro sfruttare le potenzialità e le realizzazioni del metodo di sviluppo aperto, senza però condividere le proprie implementazioni e miglioramenti.

Un fattore di primaria importanza a proposito delle relazioni con il mondo Open Source è che Google nasce a Stanford, un’università nota per la sua capacità di generare start-up aggressive e competitive basandosi su ricerche di elevato profilo. Per quanto Stanford fosse, e continui a essere, un ambiente favorevole allo sviluppo di progetti Open Source, il legame a doppio filo con il capitale di rischio rende difficile e anzi impossibile proseguire sulla strada dell’eccellenza accademica una volta usciti dal campus.

Un breve accenno alla ricerca accademica americana è necessario per comprendere le origini di Google, tra l’Open Source e la ricerca orientata al profitto. Infatti a livello più generale va sottolineato il carattere accentratore dell’università statunitense a proposito di creazione intellettuale: tutti i progetti sviluppati in campo accademico sono tendenzialmente copyright dell’università che ha ospitato il gruppo di ricerca. Stanford non fa eccezione: del resto, negli Stati Uniti le accademie sono storicamente legate al mondo degli affari, e spesso sono vere e proprie imprese. I brevetti universitari sulle invenzioni dei ricercatori fruttano royalties di tutto rispetto; inoltre conferiscono prestigio ai centri di ricerca e agli studenti/ricercatori/imprenditori.

Le università sono ambienti ibridi, tra il pubblico e il privato. Negli USA fino al 2002, almeno in teoria, i luoghi di ricerca pubblici non potevano brevettare le loro invenzioni; lo stesso si dica  per i laboratori privati ma finanziati con fondi pubblici (quindi spesso anche le università). Infatti il pagamento dei dazi ostacola la libera circolazione dei saperi nella ricerca scientifica, la possibilità di riprodurre, verificare o falsificare i risultati sperimentali. Questo in base all’Experimental Use Defense, “protezione dell’uso sperimentale”, un principio che autorizza l’uso gratuito di tecnologie brevettate nell’ambito della ricerca, introdotto nel 1813, e abolito appunto nel 2002 con la sentenza a favore del ricercatore John Madey. Madey ha citato in giudizio la Duke University, per cui lavorava, perché usava un’apparecchiatura da lui brevettata per ricerche laser su elettroni liberi. La Corte ha ritenuto che l’Experimental Use Defense fosse stato concepito per proteggere lo scienziato dedito alla ricerca disinteressata e libera, ma evidentemente nelle università questa attività non è più così innocente e, anche nel caso non sia direttamente commerciale, può essere considerata un “affare lecito” (legitimate business), poiché procura finanziamenti e necessita di forza lavoro e di personale in formazione (studenti). Cade così ogni distinzione fra la ricerca privata e quella pubblica[16].

Naturalmente, tutti i progetti nati a Stanford sono sottoposti a brevetto da parte dell’università, e questa commistione fra incentivo ai progetti Open Source da una parte, e brevettabilità selvaggia dall’altra, non giova certo all’ideale, né tanto meno alla pratica, della “ricerca” in sé, tanto sbandierata come punto d’orgoglio e di forza di Google.

La questione del brevetto si fa ancora più interessante se ricordiamo che il successo di Google si basa su un algoritmo ideato da Larry Page, a partire dalla collaborazione con Sergey Brin, quando erano ricercatori alla facoltà di Scienze Informatiche presso Stanford. L’algoritmo che ha rivoluzionato l’indicizzazione della Rete è quindi è di proprietà di Stanford, sottoposto a regolare brevetto. Andiamo a scoprire nel dettaglio come funziona questo prodigio, come riesce a fornire risultati in tempi più rapidi di qualsiasi concorrente, quasi che davvero potesse dare a ogni utente “ciò che vuole”.

Ippolita - copyleft 2006-2007 - Creative Commons 2.0 by-nc-sa