Una delle più interessanti trasformazioni socioeconomiche in corso è l’Open content, ossia il ripensamento del diritto d’autore concernente sia le opere d’arte sia le opere dell’ingegno economicamente utili, come ad esempio i brevetti.

Sono già stati introdotti tipi innovativi di licenze, come quelle Open Source e quelle Creative Commons, che consentono di copiare e modificare liberamente le opere, pur riconoscendo all’autore originario sia la titolarità morale sia il compenso economico.

Si tratta di licenze più sofisticate del semplice copyright oggi in vigore, che attenuano il potere dell’editore e lasciano più gradi di libertà all’autore nel definire le forme di riutilizzabilità della propria opera. Per esempio: ci sono forme di licenze Creative Commons tali da consentire che un libro sia riutilizzabile per produrne un altro (di cui esso diventerebbe dunque una parte); altre forme, invece, lo vietano.

Il movimento Open content è nato da quello Open source, sviluppatosi a partire dagli anni ’80 e concernente il mondo del software (del quale ha innovato la filiera produttiva). E’ un piccolo grande orgoglio della comunità informatica, l’avere dato la stura a una riflessione e un trasformazione così profonda come l’open content.

Tuttavia, come ho avuto già modo di dire altrove, intorno a open source circolano un paio di fanfaluche.

pulcinellaUna è che le licenze d’uso open source implichino o invochino la gratuità del software. In realtà quasi nessuna delle licenze Open presuppone o prescrive la gratuità dell’opera: a indurre in alcuni questa miscredenza è l’ambiguità dell’aggettivo “free”, che in inglese può significare libero ma anche gratis.

L’altra fanfaluca è che open source sia una manifestazione di intelligenza collettiva, ossia di emergenza dal basso di competenze un tempo solo appannaggio delle organizzazioni strutturate.

Secondo questa visione, il software open source dimostrerebbe che nugoli di umani senza alcun coordinamento possono auto-organizzarsi per produrre manufatti di grande complessità, come Linux o OpenOffice. Nessuno dirige o coordina i lavori.

Questa credenza è alimentata da autori (giuristi, economisti, giornalisti, politici) che non conoscono le sottigliezze del processo di produzione del software e dunque non lo comprendono.

E’ vero, infatti, che alla fabbricazione del software open source partecipano tantissimi programmatori free-lance, ma è falso che essi operino senza coordinamento top-down.

In realtà, i prodotti open source di più grande diffusione, successo commerciale e complessità (come Linux, OpenOffice, Apache Server o certi ERP) sono stati progettati e realizzati da organizzazioni aziendali ordinarie (come Sun, Red Hat, IBM, OpenBravo, Compiere, ecc ecc).

linuxEsse si sono avvalse, è vero, in parte di programmatori sparsi per il mondo e spesso non remunerati se non con l’apposizione dei loro nomi tra i credits, ma costoro sono stati e sono orchestrati da esperti di sviluppo del software e industrializzazione di prodotto.

Anche i progetti open source non controllati da aziende, prevedono tutti un Project leader che coordina gli indirizzi, stabilisce le priorità e così via.

Insomma, la partecipazione è spesso volontaria e spontanea. Ma l’0rganizzazione del lavoro è di tipo top-down. I lavoratori dell’open source, quando non sono veri e propri dipendenti di aziende del ramo, assomigliano ai terzisti che lavorano in outsourcing per le imprese manifatturiere: quando Zara o Tods ordinano delle lavorazioni a terzi, prescrivono dei precisi capitolati d’opera, anziché aspettare che ai loro cancelli si presentino prodotti o semilavorati prodotti per “spontaneamente” e per “auto-organizzazione”.

Andate su openoffice.org o su sourceforge.net, e vi troverete le regole comportamentali e collaborative per contribuire a progetti open source, nonché l’elenco dei task che possono essere svolti da qualunque volontario.

Chi ha promulgato quelle regole? Chi mantiene quella lista di task, preoccupandosi delle relative priorità e dei mutui collegamenti, senza i quali nessun software emergerebbe?

Non l’Intelligenza Collettiva di un Organismo Auto-organizzato, ma delle persone concrete, spesso con tanto di stipendio e company car. (A volte, questo stipendio è provvisto da aziende o enti pubblici ignari che i loro dipendenti fungono, per una buona parte del proprio tempo, anche lavorativo, da project leader per progetti open source).

commenti
  1. acravera scrive:

    Paolo,
    in questo e in un precedente commento mi hai convinto che oggi l’open source, per come è concepito e realizzato, si avvale di un coordinamento formale di tipo gerarchico per funzionare. Però il tema dell’intelligenza collettiva e dell’auto-organizzazione mi è troppo caro per riuscire a liquidarlo così velocemente. Se guardiamo alla storia dell’open source la faccenda era ben diversa. Per come lo ricordo io, Linux è nato, quasi per gioco, come una versione gratuita di Unix per mano di uno studente finlandese. Torvalds, anzichè “proteggere” il suo lavoro, ai tempi ne ha fatto menzione su un newsgroup con migliaia di utenti e questo ha fatto guadagnare alla prima versione di Linux uno spazio nel server dell’University of Tecnology di Helsinki, consentendo a chiunque di scaricare i programmi. Da lì nasce l’idea del contributo allargato a migliaia di programmatori sparsi nel mondo. Tutti potevano lavorare su qualsiasi caratteristica o miglioramento del sistema, anche se, effettivamente, le nuove codifiche dovevano essere sottomesse a Torvalds che poteva decidere se accettarla o richiedere delle modifiche prima di aggiungerla a Linux.
    Il fatto che Torvalds avesse l’ultima parola rende il suo coordinamento gerarchico e top down? A mio avviso no. La forma che prende Linux non dipende da specifiche costruite in modo top down, bensì emerge dal lavoro esteso di molti programmatori che, giorno dopo giorno, ne plasmano le caratteristiche (passando da Torvalds. Già questo, per me, è sufficiente per non poter liquidare l’open source (almeno il primo open source) alla stregua dei tanti progetti coordinati gerarchicamente che presenti in tutte le imprese: si può ravvedere nel progetto Linux una forma di auto-organizzazione.
    L’altro aspetto da sottolineare è che internet, di fatto, ha reso possibili nuove forme di intelligenza collettiva, altrimenti difficilmente realizzabili. Ci sono molti casi, che tu conosci molto meglio di me. Ne cito uno a titolo di esempio: Marketocracy sfrutta l’intelligenza collettiva della comunità finanziaria assoldando migliaia di trader affinché gestiscano portafogli di azioni virtuali all’interno di una gara in cui chi vince diventa il miglior investitore. La società indicizza i 100 top performers e le loro strategie di trading vengono emulate nella gestione di un fondo comune. In questo caso non possiamo parlare di auto-organizzazione, così come nel caso di Innocentive, tuttavia, perlomeno di intelligenza collettiva si.

  2. Paolo Magrassi scrive:

    Ale,

    in nessun punto il mio post è “contro” l’intelligenza collettiva (né a favore).

    Il post serve a far vedere che open source non è una manifestazione di auto-organizzazione ed emergenza, ergo intelligenza collettiva nel senso che dài tu al termine. (E che invece, se lo fosse, allora lo sarebbero anche quasi tutti i progetti di sviluppo software oggi in corso).

    Inoltre, né il mio post né questo mio commento debbono suonare come diminutivi dell’opera di personaggi meritori come Torvalds, Tanenbaum o Stallman, per i quali nutro la massima ammirazione.


    I fatti salienti dietro la storia di Linux sono open content , contributi spontanei e collaborazione.

    Sui primi due credo ci intendiamo. Quanto al terzo, esso costituisce un fenomeno di formidabile progresso nella storia dell’organizzazione del lavoro, reso possibile da due innovazioni: il Web e l’avvento di metodologie object-oriented nello sviluppo del software.

    Il Web consente, com’è ovvio, a me di postare un software da me sviluppato e con ciò di renderlo disponibile a tutti. L’object orientation consente di modularizzare lo sviluppo e quindi di attuare una divisione del lavoro che, nel campo del software, prima degli anni ’90 non era sostanzialmente possibile.

    Ergo, quando io posto un brano di codice da me sviluppato in stile modulare, un altro programmatore potrà incorporarlo, appiccicarlo al software suo con pochissime lavorazioni (sebbene non zero). Ciò rende effettivamente possibile che molti addetti, anche geograficamente distribuiti, possano collaborare alla messa a punto di un prodotto finale comune.

    Ciò, bada bene, non avviene solo in open source. Avviene anche nel caso di moltissimi software proprietari: web e collaborazione sono disponibili anche a Sap, Oracle, Microsoft et al., e certo non solo alla comunità open source. Solo, è stata questa a dar la più grande e spettacolare dimostrazione delle nuove capacità.


    Il termine comunità, sommato a una serie di classici malintesi intorno al processo di sviluppo del software (che solo gli addetti ai lavori comprendono), ha portato, nella mente dei guru della wikinomics e in generale di coloro che riempiono libri, alla nascita del mito dell’opes source come esempio di intelligenza collettiva per antonomasia.

    Si tratta, tuttavia, di un volo pindarico. Mille programmatori possono certamente scrivere ciascuno un moduletto software ma, object-oriented o no, alla fine il “maxiprodotto” non funzionerebbe se non fosse orchestrato da poche persone esperte di software design.


    Ai tempi eroici in cui gente come Tanenmbaum e Torvalds erano praticamente i soli a lavorarvi, il Linux Kernel constava di poche migliaia di righe di codice (circa 10mila LOC nel 1991). Poi è cresciuto in modo impetuoso, e oggi le righe di codice sono una decina di milioni.

    Nessun softwarista crederà mai che un insieme di 11.637.000 LOC (Linux Kernel 2.6.30) possano dar vita a un prodotto che funziona, senza alcun coordinamento.

    Secondo uno studio recente, sono circa 3500 i programmatori che dal 2005 al 2008 hanno contribuito (non tutti contemporaneamente) al Linux kernel, e siccome questi numeri sono esplosivi (raddoppiano ogni anno), vedi facilmente, e facilmente puoi congetturare, che ai tempi eroici di Torvalds i programmatori che avevano qualcosa di utile da dire sul kernel di Linux erano centinaia, anzi, più probabilmente decine. (Io stimo che fossero poche decine).


    Ebbene, è ancora così! Anche oggi, secondo quello stesso studio (sposorizzato dalla Linux Foundation), i top 10 developers (Viro, Miller, Bunk, Baechle, Morton, Kleene, Iwai, Heo, King, Torvalds) producono il 15% del lavoro e i top 30 developers il 30% percento.

    E questo riguarda solo la quantità del lavoro. Se guardiamo all’importanza delle righe di codice prodotte, puoi star certo che l’accentramento in quelle poche teste sia molto, molto maggiore.

    Non solo: la produzione di righe di codice, quale ne sia l’importanza, è spesso meno importante delle decisioni progettuali (design), che sono conditio sine qua non perché il codice venga prodotto, e che non possono avvenire se non in coordinamento e con un livello decisionale superiore (di solito un comitato) che operi scelte e stabilisca priorità.

    Né ai tempi eroici dei quattro gatti, né tantomeno oggi, Linus Torvalds esaminava accuratamente i blocchi di codice inviatigli da cani e porci. Torvalds riceveva delle proposte di massima. Ne vagliava alcune e, se gli sembravano carine, promulgava il task da svolgere. Ancora oggi, open source funziona così.

    Se vuoi verificare di persona, mettiti nei panni di un free-lance che voglia collaborare ai progetti; visita le comunità online, e poi mi saprai dire come funziona.

    (Allo sviluppo dello Unix Kernel 2005-2007 hanno partecipato per l’86% delle aziende per il 14% dei free-lance. Cfr. Kroah-Hartman, Corbet, McPherson, “Linux Kernel Development: How Fast it is Going, Who is Doing It, What They are Doing, and Who is Sponsoring It”, aprile 2008).


    Se è “intelligenza collettiva” Linux, allora lo sono anche SAP o Windows, perché anche in quei casi ci sono pochi project leader che [non si limitano a emettere circolari dispositive ma] ascoltano e vagliano le idee e le proposte di tante persone.

    E qui si arriverebbe al discorso serio sull’intelligenza collettiva, che adesso non facciamo, ma che, se inizia con la storiella di Linus Torvalds, raramente mi convince.

    [NB: Queste righe sono parte del mio nuovo libro. Per favore non copiatele altrove. Grazie!]

  3. […] Il complessivo pessimismo che aleggia in questo blog intorno alle fantasie dell’intelligenza collettiva non mi impedisce di discernere il potenziale della collaborazione, dell’eterarchia, del […]

Lascia un commento

Effettua il login con uno di questi metodi per inviare il tuo commento:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...