Il sociologo, la sociologia e il software libero: open source tra società e comunità/Allegati/1
 |
Questo testo è completo. | |
| ◄ | Allegati | Allegati - 2 | ► |
Nato a Bologna, il 16 marzo 1979, Debian Project Leader, Ricercatore Laboratoire PPS, Université Paris Diderot.
Premessa:
Io e Stefano Zacchiroli avevamo già intrattenuto degli scambi via posta elettronica per concordare questa intervista. Ci eravamo già presentati. L'intervista inizia con Zacchiroli che pone a me delle domande. È necessario tenere presente che Stefano Zacchiroli è uno scienziato, un ricercatore universitario, quindi implicitamente assume un ruolo che va oltre il fatto di fornire delle informazioni. È probabilmente una sua prerogativa quella di entrare nel merito della questione e di conseguenza negoziare la definizione della situazione in un ambito scientifico. Da parte mia si è ritenuto metodologicamente corretto questo approccio per tre motivi:
Ha fornito direttamente delle notizie e delle chiavi di lettura che hanno confermato o meno le mie ipotesi di fondo e che, in ogni caso, hanno avuto la necessità di essere contestualizzate in una prospettiva sociologica.
Sono comunque emersi atteggiamenti di fondo utili ai fini dell'indagine.
In questo modo emerge in buona misura la mia personale funzione al valore relativa al campo di indagine.
Intervista:
I = IO, stefano De Boni laureando in scienze sociologiche a Padova
Z = Stefano Zacchiroli
Z: Mi scrivevi che sei stato volontario stato in Africa?
I: Sierra Leone vicino alla Liberia, Africa Occidentale. La mia intenzione era appunto di trovare un posto pubblico in modo da tornare a fare il volontario con la cooperazione internazionale, così una volta che mi fossi stancato sarei potuto tornare e quindi avere un posto. Poi ho trovato mia moglie, mi sono sposato, poi nel pubblico ho fatto carriera, carriera per modo di dire, sono entrato come impiegato amministrativo e poi sono diventato informatico attraverso corsi di formazione e esperienza lavorativa. Quindi ora sono inquadrato come analista programmatore.
Z: E sei riuscito a lavorare sul software libero a Padova?
I: io studio a Padova ma vivo e lavoro Vicenza. La cosa che mi ha fatto cambiare abbastanza idea è stato che seguendo dei progetti GIS ho provato a scaricare delle cose...
Z: Era tutto chiuso [pensa che stia parlando di software proprietario]
I: No, intendo Mapserver, Openlayer, questo tipo di cose [software libero], e ho visto che riuscivo molto meglio...
Z: ah, addiruttura qualità del software libero migliore di quello proprietario?
I: Dal punto di vista dei GIS si!
Z: So che il GIS è una cosa che ha convertito molti, ma soprattutto per via dei formati proprietari, in quanto dicevano: “ma no deve essere roba che deve essere accessibile pubblicamente”. Molte persone mi hanno detto che questo è stato il motivo iniziale per interessarsi al software libero...
I: No la causa scatenante da parte mia è stata che ... a parte che io faccio sviluppo WEB e quindi mi occupo dei GIS dal punto di vista WEB... [interruzione perché manovro con il microfono per assicurarmi che sia in funzione]...si mi occupo di sviluppo WEB, dal punto di vista sistemistico non me ne sono mai occupato più di tanto. Dal punto di vista WEB posso dire che la cosa rispetto ad Intergraph, non ho mai usato ESRI, se non i Map-objects che si usavano molti anni fa, è notevolmente migliore. Ma anche per il semplice fatto delle specifiche e la documentazione che trovi su internet. Su intergraph hai delle difficoltà proprio a ricevere le informazioni su come far funzionare le cose. Devi avere dei canali istituzionali, è tutto mediato attraverso figure commerciali e via dicendo. Se devi mettere su qualcosa in quattro e quattr'otto non c'è paragone. Poi ho cominciato ad interessarmi a sta cosa qua e la cosa che io ho colto dal punto di vista sociologico, a parte che io mi sono occupato di sociologia anche per motivi organizzativi, perché per me nel pubblico la patologia organizzativa e diffusa...
Z: Non pensavo che la scala fosse abbastanza grande per applicarvi i metodi della sociologia...
I: Al di la degli sfoghi ho deciso di cercare di comprendere da un punto di vista più scientifico...
Z: Quindi hai preso un part-time?
I: No io lavoro a tempo pieno.
Z:Ok. Complimenti. E questa laurea qua è triennale o specialistica?
I: Triennale e comunque farò anche la specialistica.
Z: Va bene dai, dimmi tutto.
I: Allora...
Z: Ammetto che non ho fatto molti compiti...
I: Ma no, le cose migliori sono quelle che nascono spontaneamente. Le domande che ti avevo mandato erano queste (gli porgo un foglio con quattro domande:
1) racconti come È andata la debconv di NYC;
2) vorrei che comentassi questa frase di Eric Steven Raymond:
[...] Gli hacker sono anti-autoritari per natura. Chiunque possa darti degli ordini, puo' fermati dal risolvere problemi dai quali sei affascinato - e, visto il modo con cui le menti autoritarie funzionano, tali ordini generalmente saranno motivati da ragioni orribilmente stupide. Così, l'atteggiamento autoritario deve essere combattuto ovunque si trovi, affinché non soffochi te e gli altri hacker . (How To Become A Hacker, rev. 1.15, October 03, 2002)..."
3) vorrei raccontassi episodi significativi della esperienza professionale o meno legati al softaware libero
4) vorrei dessi degli spunti o contributi che ritieni utili per la tesi (se vuoi ti faccio avere il semi-elaborato prima)
Z: Si ma dimmi cosa vuoi sapere di Debconf, nel senso che la domanda è molto aperta, e come ti ho già segnalato, c'è un sacco di gente che ha già studiato come funzionano questi eventi quindi... mi dici più in specifico cosa vuoi sapere, cioè che tipo di feedback vuoi?
I: Questa volta sono io che non ho studiato...
Z: nel senso che raccontare due settimane di eventi potrebbe prendere una settimana di tempo...
I: Quello che a me interessa sapere, per restringere di più il campo ... io ti scrivevo che rispetto alla Coleman ho un punto di vista un po' diverso, più una sfumatura diversa più che un punto di vista diverso, nel senso che io sono convinto che, diversamente da quello che lei dice che la Debconf serve a costruire il “selves”, che questo “selves” in qualche modo sia costruito già prima, cioè...
Z: in rete intendi?
I: in rete sì!
Z: Nel caso di Debian è un caso diverso dai LUG (Linux Users Groups), se non altro per un motivo di scala, i LUG sono formati da gente che già si conosce, se qualcuno si approccia a Linux si iscrive alla mailing list, si fa conoscere, il mese dopo o relativamente poco dopo partecipa alle riunioni locali, e quindi conosce subito le persone fisicamente, quindi non c'è quello che spesso è un problema in Debian ed il fatto che essendo un progetto su scala internazionale, c'è gente che lavora senza mai né essersi vista, né conosciuta. Allora questo, siamo molti a pensarlo in Debian, contribuisce nel momento in cui ci sono dei conflitti tecnici a peggiorare le situazioni, nel senso che è molto più facile avere una battaglia, un flame [conflitto sulle discussione on-line] con qualcuno che non hai mai visto di persona piuttosto che con qualcuno che hai visto di persona, conosciuto di persona, con il quale hai condiviso delle esperienze emotivamente forti, perché eventi come debconf sono indubbiamente eventi emotivamente molti forti. Quindi il motivo principale per cui molti di noi pensano che Debconf sia fondamentale in un progetto come Debian è abbattere questa barriera, abbattere la barriera del non ci siamo visti, conosciuti e questa barriera contribuisce ad esacerbare i conflitti. Quindi il motivo principale, sono d'accordo con la Coleman, che sia un po' sul ridurre questi attriti che si possono verificare nella vita normale del progetto. Noi una cosa che diciamo spesso è “vai ad un a Debconf, ti incontri con qualcuno, ti ubriachi, ci passi due settimane, ed il giorno dopo quando sarai a casa a e interagirai con questa persona remotamente, la tua interazione con lui, o con lei, sarà molto migliore e questo è a mio avviso uno dei motivi fondamentali per andare ad una debconf che è migliorare i rapporti all'interno della comunità. Secondo, è molto diverso da quello che può esserci in un LUG, perché il LUG è un'iniziativa forzatamente locale, cioè basata sul territorio. Il LUG serve proprio per raccogliere assieme tutti i linuxiani [coloro che usano Linux e si riferisce all'insieme delle subculture che fanno riferimento alle diverse versioni, le così dette distribuzioni o distro, di Linux] o quello che è di un certo territorio. Quindi è forzatamente, geograficamente molto locato e localizzato. Un progetto come Debian no, è assolutamente world wide, e quindi non ha questo tipo di garanzia di incontrarsi periodicamente. Questo è un motivo. Altre persone dicono che vanno o non vanno a Debconf per motivi diversi. C'è chi semplicemente dice che ci va per i cosiddetti sprint. Cioè per incontrarsi e lavorare assieme su un certo progetto. E li è risaputo che lavorare di persona in un lasso di tempo limitato con delle persone che collaborano su uno stesso progetto ha un'efficienza ed un'efficacia molto superiore che il lavoro remoto, perché si è concentrati perché la cosiddetta banda passante della comunicazione è molto più alta e via dicendo. Questo è un altro motivo per andarci. Ritengo per molti sviluppatori Debian non sia il motivo principale e per chi come me ci va da tanti anni è perché li hai tanti amici, si sono formate delle relazioni in 10, 11 anni di Debconf e andarci e un modo per ritrovarsi. Quindi questi sono per me i tre motivi principali per cui si va a Debconf e come Debian project leader ho invitato molta gente a partecipare sul primo motivo [i conflitti]. Spesso diciamo che abbiamo dei conflitti all'interno della comunità. Le persone che partecipano a questi conflitti se vanno alla Debconf saranno meno disposti a creare conflitti in futuro con le persone con cui hanno condiviso un'esperienza così forte. Abbiamo addirittura avuto un programma apposta in cui si invitava la gente che non era mai andata a Debconf, quindi o novellini di Debian, o gente che negli ultimi cinque anni non è mai andata a Debconf, ad andarci proprio su questa base. Se tu non ci sei mai andato, beh allora sei un target ideale per andarci perché la tua percezione sulla comunità Debian ha buone possibilità di cambiare significativamente.
I: Ma secondo te è importante andarci almeno una volta...
Z: Diciamo che cercavo il punto...
I: perché è importante? Cioè è importante andarci almeno una volta o è importante andarci frequentemente?
Z: Capisco perfettamente la domanda. Io cercavo il punto del peccato originale, nel senso che credo faccia molto di più il “andarci la prima volta senza esserci mai andato” che il “tornarvi se ci sei già stato”. Entrambe le cose sono importanti nel senso che cose come “il senso di comunità...
I: cambia il significato?
Z: cioè, io la vedo nell'ottica manageriale, quindi c'è una comunità Debian che ogni tanto ha degli attriti. Quindi: cosa possiamo fare per migliorare questa situazione? Allora trovo che andarci per la prima volta senza esserci mai andato serva tantissimo a migliorare la situazione. Tornarci se ci sei già andato contribuisce ma non così tanto come la prima volta. Questo se vogliamo dargli un'ottica più manageriale dell'utilità di partecipare a questi eventi. Poi c'è che non è che Debconf sia speciale. Cioè Debconf è l'unico evento annuale che abbiamo in cui tutti gli sviluppatori sono interessati a partecipare, che gira per il mondo così almeno periodicamente ti capiti che è abbastanza vicino a te, ma se ci fossero altri eventi in cui ci si incontra con tutta la comunità andrebbero altrettanto bene. Semplicemente l'unico evento che oggi abbiamo di questo tipo è Debconf. Ci sono altri eventi nei quali ci incontriamo. C'è Fosdem, che è la più grossa conferenza di software libero europea che si tiene in febbraio a Bruxelles tutti gli anni, ma necessariamente è una cosa più specifica per gli europei. C'è Linux Conference Australia che è un altro evento grosso dove c'è tantissima gente Debian che va. Però l'unico evento mondiale che attira tutti della comunità Debian è Debconf. Non c'è un ruolo speciale in un evento che si chiama Debconf, c'è un ruolo speciale in un evento che riesce ad attirare sviluppatori Debian da tutto il mondo per incontrarsi di persona.
I: Dal punto di vista del coordinamento...
Z: dell'organizzazione?
I: Sì lo tiro fuori perché un po' l'hai citato, ci sei passato vicino a questo aspetto, quindi al coordinamento delle attività e del progetto. Cioè tu dici che il fatto di trovarsi fisicamente migliora poi per prosieguo del progetto il coordinamento tra le persone. Dal punto di vista del coordinamento a me interessava sapere, misurare quanto è il coordinamento pianificato da un qualche organo, da una qualche struttura formalizzata all'interno della community Debian, o piuttosto quanto è l'auto-coordinamento, o quanto viene prima l'uno e quanto viene dopo l'altro. Se è già previsto l'auto-coordinamento a livello di pianificazione, oppure se il coordinamento, la pianificazione avviene cercando di pianificare quello che è già un assetto organizzativo che si è già instaurato. Quindi riuscire a misurare queste cose e capire in che rapporto stanno tra loro.
Z: Ok, ma Debian fin dalle origine è un progetto senza troppe gerarchie, nel senso che una distribuzione linux ha nativamente una divisione di compiti attorno ai pacchetti software che si rilasciano. Inizialmente Debian non era così, Debian era proprio “tutti possono lavorare su tutto”, poi ad un certo punto nella storia del progetto si è introdotto il ruolo di mantainer di un pacchetto, quindi una persona che aveva una specifica responsabilità su un certo pacchetto, e poi in un'altra evoluzione storica del progetto questo pacchetto, che tutt'ora esiste, è stato generalizzato di fatto, nel senso che ora abbiamo molti team di persone che collettivamente si occupano di un certo numero di pacchetti. Quindi c'è una granularità implicita in un progetto come Debian che è quella del pacchetto, ok? Attorno a questo granularità si sono sviluppati nei ricorsi e concorsi storici dei gruppi di mantenimento di questi pacchetti. Quindi questa è la struttura di base che esiste in Debian possiamo dire che ad oggi abbiamo tanti gruppi di persone che lavorano assieme a mantenere gruppi di pacchetti. Questa è la struttura di base che fa la maggior parte del lavoro in Debian. Al di sopra di questo abbiamo delle strutture prescritte dalla costituzione Debian che hanno dei ruoli un po' più infrastrutturali se non politici. Quindi ci sono tutti gli strumenti per far funzionare la costituzione Debian. C'è il project leader, ci sono i suoi delegati. Il segretario e tutti i macchinari che servono per fare andare avanti i meccanismi di voto. C'è il comitato tecnico, nel caso ci siano conflitti di natura tecnica tra persone all'interno del progetto. È una specie di, come dire, “tribunale” a cui ci si può appellare per risolvere conflitti di natura tecnica. Ci sono quelli che chiamiamo core teams, che hanno dei ruoli specifici e che sono delegati del proprio project leader, ma che hanno dei ruoli politici abbastanza importanti anche se vuoi di “divisione dei poteri”. C'è il cosiddetto DAM, Debian Account Manager, che sono un gruppo di persone che decide chi può diventare sviluppatore Debian e chi no. C'è il gruppo di DSA, Debbian System Administrator, che sono quelli che mantengono tutte le macchine, tutti i server del progetto Debian in giro per il mondo, ed in generale tutta la infrastruttura tecnica. C'è un gruppo chiamato FTP masters, che sono quelli responsabili su cosa entra nell'archivio software Debian e cosa no, e che hanno un potere molto significativo, nel senso che sono quelli che decidono al momento quali sono le licenza che sono accettabili nell'archivio Debian, decidono quando un pacchetto non raggiunge i criteri minimi di qualità per entrare nell'archivio e tutte 'ste cose. Poi c'è un gruppo di Keyring Manegers che sono quelli che gestiscono il gruppo di chiavi e di firme digitali che servono a firmare i pacchetti che possono entrare nell'archivio. Quindi questi sono i gruppi di potere principali. All'interno di questi gruppi, la vita tecnica del progetto è principalmente aut-organizzata. Cioè ogni gruppo ha una sua agenda che va avanti a seconda della disponibilità di tempo delle varie persone, e funziona tutto senza un coordinamento centrale. Quindi storicamente ruoli come il mio, di Debian Project leader, non è che abbia avuto un'agenda da seguire per organizzare la vita del progetto. Dimenticavo, c'è ovviamente il release [rilascio di una versione] Team che è un gruppo di persone responsabili di valutare il programma verso una release [rilascio di una versione] Debian che è l'outcome principale di un progetto come Debian: fare una nuova release [rilascio di una versione]. C'è questo gruppo di persone che si preoccupa di coordinare le release [rilascio di una versione]. Quindi attorno a tutti questi teams ognuno ha una sua agenda, ed in particolar modo il release [rilascio di una versione] Team ha un'agenda per capire quando faremo una prossima versione Debian e la vita del progetto gira un po' attorno a queste agende auto-organizzate. Prendiamo ad esempio un'agenda di un team che gestisce un pacchetto relativo ad un certo argomento, per esempio GNOME, l'evoluzione classica è che c'è una “shedule” [cronogramma] per fare una release [rilascio di una versione], il team GNOME decide quanto può fare all'interno di questo schedule, lavora e cerca di finalizzare il suo lavoro in modo che sia pronto nel momento in cui si decide che ci sarà una release [rilascio di una versione].
I: Queste agende possono somigliare a dei diagrammi Gannt?
Z: No! Io sono particolarmente allergico ai diagrammi Gannt perché c'ho avuto a che fare per progetti di ricerca europei e trovo che siamo, come dire …. , un po' troppo constraining, cioè come dire che mettano troppi paletti per riuscire a rappresentare cosa accade realmente nella realtà. Penso, questa è l'idea di base, poi ci sono le eccezioni, e il diagramma non è bravo per niente a rappresentare le eccezioni. Un esempio tecnico calzante è che per arrivare ad una release [rilascio di una versione] ad un certo punto decidiamo che c'è una “freeze” [congelamento], cioè il momento in cui nuove modifiche nel software non avvengono più, cioè si fissano, si mettono a posto i problemi con il software che che si ha ma non si introducono cambiamenti radicali e quindi si tende a compattare il lavoro in vista di una release [rilascio di una versione]. A questa policy [politica] generale abbiamo le eccezioni, perché non è sempre applicabile, ci sono dei casi in cui bisogna derogare a questa policy. Quindi secondo me no, non è lo strumento che si possa usare per modellare queste agende, poi credo che nessuno ci abbia mai provato. Nessuno in Debian accetterebbe mai l'idea di essere vincolato ad un Gannt per sapere in quale direzione andare, però magari a posteriori è possibile riconoscere un'evoluzione di queste cose con uno strumento del genere.
I: Si potrebbero fare dei Gannt a posteriori?
Z: Forse si, non lo so, non so se nessuno ci ha mai provato, né tanto meno quando dico che ci sono delle agende di ogni team non so siano mai sempre formalizzate. Magari ci sono dei team dove dicono: “Ok, questa è la lista delle cose che vogliamo fare prima della prossima release [rilascio di una versione]”, e dei teams in cui il lavoro si sviluppa naturalmente senza che nessuno abbia nemmeno fatto una lista di cose da fare. Quindi c'è molta eterogeneità in Debian, ci sono dei trend generali che si possono riconoscere. Ma c'è molta eterogeneità. Per concludere la cosa sulla tua domanda quindi direi, se dovessi valutare dov'è, è molto più sull'auto-organizzazione e non sull'organizzazione centrale, con il difetto che alcuni cambiamenti, diciamo grossi, alcuni cambiamenti importanti, filosofici o politici nel progetto non hanno nessun responsabile che se ne occupi. Quindi il Debian Project Leader dovrebbe preoccuparsi di accorgersi di queste necessità di cambiamento e guidare un po' la comunità prendendo una decisione in un verso piuttosto che in un altro. E questa è una cosa che nella costituzione Debian c'è. Nella costituzione debian c'è scritto che il project leader è colui che guida le discussioni, io direi che è quello che tiene d'occhio l'agenda del progetto. Però quando dico agenda del progetto è più su meta-cambiamenti, vogliamo chiamarli, che non su la naturale evoluzione del software che funziona già benissimo così com'è in Debian.
I: Ho capito, benissimo. Poi io ti avevo proposto un'interpretazione di questa frase di Eric Steven Raymond.
Z: La leggo a me stesso: “Gli hacker sono anti-autoritari di natura, chiunque può darti degli ordini può fermarti dal risolvere problemi dai quali sei affascinato, e, visto il modo in cui le menti autoritarie funzionano, tali ordini saranno generalmente motivati da ragioni orribilmente stupide. Così l'atteggiamento autoritario deve essere combattuto ovunque si trovi affinché non soffochi te e gli altri hacker.” Dunque si, questa è una visione forse non so, naive o un po' vecchia di come funzionano queste cose, nel senso che, insomma Eric Steven Raymond ha molto in testa la visione dell'hacker che da solo può cambiare tutto, che si applica bene quando si lavora da soli, in pratica un po' meno bene quando si lavora in gruppo. Cioè fare una release [rilascio di una versione] di una distribuzione Linux che ormai conta quasi quarantamila pacchetti ha necessariamente una dose di coordinamento al suo interno. Cioè l'anarchia totale nel fare un prodotto così grande è impensabile. Quindi anche se noi abbiamo aree di responsabilità specifiche c'è bisogno di un certo coordinamento e il coordinamento necessita di un minimo di autorità. Quindi la release [rilascio di una versione] team che c'è in Debian se vogliamo è autoritario se vogliamo nei cambiamenti che lui fa al software. Nel senso che ha un potere di dire: “basta adesso non facciamo più cambiamenti di un certo tipo ma ci occupiamo solo di risolvere i problemi che ci impediscono di fare una release [rilascio di una versione].” Quindi in questo senso, questo tipo di autorità nel progetto Debian è accettato, ma è accettata nel senso che l'anarchia totale semplicemente non funziona in questa scala così grande. Di contro direi che negli anni abbiamo costruito un pò troppi paletti alle contribuzioni. Cioè questo fatto di avere i mantainer associati ad ogni singolo pacchetto, ha fatto si che abbiamo una procedura che spiega quando un altro mantainer ha fatto un upload di un pacchetto non suo che si chiama no-mantainer upload, e negli anni abbiamo avuto la percezione che fosse qualcosa di non desiderato, come una specie di onta, ad esempio: io ho fatto l'upload di un tuo pacchetto? è un'onta! Anche se il tuo pacchetto era mantenuto male, era in pessime condizioni e cose di questo tipo. È una cosa su cui ho lavorato molto e ho trovato molta accettazione da parte della comunità ed è come dire: siamo un po più liberali su queste cose. Cioè di permettere, di invogliare, di accettare un po di più il fatto che altri possano lavorare sui tuoi pacchetti, Magari come back-up, magari perché non hai tempo. Quindi in un certo senso questo trend spinge un po più verso l'anarchia, un po meno verso la coordinazione, però, secondo me, questo tipo di visione funziona in progetti relativamente piccoli che non hanno bisogno di coordinamento.
I: ho capito.
Z: Poi è senz'altro vero che un modo fantastico di vedere i propri cambiamenti accettati da altri è quello che si chiama “show me the code”, cioè si fa vedere che un cambiamento di cui si sta discutendo da secoli è possibile, una volta che c'è l'evidenza in termini di codice che il cambiamento è possibile è più facile che collettivamente si decida che quella è la via giusta. Quindi diciamo: coordinamento non vuol dire discussione perenne su tutto, coordinamento vuol dire che ci sono delle responsabilità, che si possono prendere delle decisioni collettivamente ma c'è un primato che dice che le cose si possono fare in un modo soltanto; che è uno strumento fortissimo per convincere di una certa posizione.
I: Ok, però senti una cosa, a me questa frase Eric Steven Raymond sembrava mettesse in evidenza il fatto che c'è qualcuno che può impedirti di risolvere dei problemi, o che può impedirti di fare delle cose. Questo io non l'avevo letto all'interno di un progetto o di una community, ma l'avevo letto come tensioni nei confronti del mondo, poi tu avevi colto l'anno abbastanza pionieristico …
Z: ma ti ho sottolineato l'anno perché ho l'impressioni che ci siano visioni di come funzionano nel mondo dei geek diverse. Diciamo una visione preliminare. Molto hacker, molto “one man show”, “che belle queste comunità che non si incontrano mai di persona”. Mentre adesso stiamo realizzando che molte cose non erano come le immaginavamo all'inizio. Quindi coordinamento, quindi andare ai meeting di persona. Ho l'impressione che le visioni stiano un po' cambiando. Probabilmente è legato al fatto che il free software si sta diffondendo, sta aumentando tantissimo la scala nella quale si sa cos'è il software libero, nella quale si sa come si sviluppa software libero e quindi bisogna anche un po' adattare il modo in cui si lavora per restare e raggiungere questa nuova scala.
I: È cambiata questa tensione nei confronti del mondo? Comunque lui vuole ostentare questa tensione tra il mondo hacker ed il resto del mondo.
Z: È che ci sono molte visioni che si mescolano nel software libero: C'è questa visione hacker, un po' anarchica, anti-autoritaria, del potere di fare quello che si vuole col codice; c'è la visione open source che ha una visione molto pragmatica in cui si dice: “ok, il software libero ci piace perché queste licenze ci danno gli strumenti per cambiare le cose, per essere di nuovo padroni delle cose che usiamo; e c'è quella del software libero, che è quella dei diritti degli utenti e quindi la possibilità di modificare il software, distribuirlo eccetera. Tradizionalmente Debian nasce dalla visione software libero. Nella visione software libero non è cambiato molto, la visione del mondo è sempre quella, la visione del mondo e: “gli utenti devono essere messi nelle condizioni di vedere, toccare, modificare, redistribuire il software che usa”, ok? Questa visione è tuttora più che moderna e non è cambiata per niente. Questa visione però non ti dice come si ottiene il risultato di portare il software libero a tutti, in tutto il mondo. Quella che i geek chiamano la “total world mination” del software libero. Questa visione ti dice semplicemente qual è lo scopo e quali sono i motivi per cui si fa questo. I modi in cui si lavora per raggiungere quello scopo non è descritto nella visione di Eric Steven Raymond, secondo me è quello che è un po' cambiato. Cioè Eric Steven Raymond stesso, il progetto per cui è famoso è Fetchmail, credo che sia un progetto in cui c'è una sola persona che tiene le fila, certo ci sono patch, contributi da tutti quanti, però controversa. Un progetto in cui c'è una persona con un ruolo chiave. Poi altri possono “forkare” [derivare altri progetti indipendenti dall'originale] il codice e tutte e via dicendo. Ma tutti oggi siamo in una visione del software libero un po' più organizzato secondo me. Perché per stare dietro alla scala che abbiamo raggiunto adesso serve un peletto in più di organizzazione. Poi non è vero dappertutto, tieni presente che la mia visione è quella di Debian che è un progetto immenso, è uno dei più grandi che c'è in termini di numero di sviluppatori, in termini di software che viene distribuito alla gente, quindi è possibile che io sia un po' “biased” [di parte] orientato verso questo contesto, e quindi l'organizzazione serve, non c'è niente da fare. Poi all'interno delle nostre scatolette di responsabilità noi abbiamo tutta la libertà. Nel senso che uno può lavorare come vuole sulla sua parte di progetto, una delle cose fondamentali, che la costituzione Debian dice, è che ognuno è libero di prendere tutte le decisioni che vuole, tecniche o non tecniche, all'interno della sua aree di responsabilità, però c'è sempre questo limite esterno della tua responsabilità.
I: Ok, poi questa domanda …
Z: Cos'è?
I: Episodi significativi della esperienza professionale, però si potrebbe ricollegare anche a questo, cioè, almeno io l'avevo vista così, nel senso che …
Z: Aspetta, cos'è questo technitai descritto da Gian Antonio Gilli? [legge dal foglio della traccia che mi ero predisposto].
I: È un sociologo, tra l'altro quello che io sto facendo nella tesi è quello di cercare di applicare le teorie della sociologia al fenomeno open source e Gian Antonio Gilli descrive partendo dall'antica Grecia la figura del technitai che è un personaggi abbastanza diffuso, che in termini generali lo si può riconoscere nell'artista, nell'artigiano, nelle persone creative in genere e descrive come, partendo dall'antica Grecia all'età moderna ci siano delle costanti nei confronti di queste persone per cui la società ha sempre avuto il problema in qualche maniera di controllarli.
Z: Ok.
I: Quindi in qualche maniera di metterli sotto controllo. Poi Gian Antonio Gilli porta l'esempio di come nell'antica Grecia le persone che noi oggi chiameremmo “skillate” [dotate] dovevano assolutamente essere sottomesse e nella condizione di schiavi e da qui la figura dello schiavo intellettuale dell'antica Grecia. Poi lui porta tutta una serie di esempi passando per il Medio-Evo fino ad arrivare ai giorni nostri in cui evidenzia come la società abbia sempre avuto il problema di controllare, istituzionalizzare, e in qualche maniera anche tenerle isolate, controllate alla fine. La frase che sintetizza questo è: “preghiamo i nostri dei di fronte alle opere d'arte ma disprezziamo chi le ha fatte”. Sintetizza l'idea di questo technitai utile per la società ma da un altro punto di vista anche pericolosa, perché imprevedibile. Potrei dire nel caso, dell'open source, il mio problema dal punto di vista industriale è sapere che tipo di struttura dargli, che ruolo dargli all'interno della nostra società dove vige l'economia di scala, dove vige il lavoro parcellizzato, dove vige la funzione della domanda e dell'offerta, dove vige il discorso che le risorse devono essere scarse perché altrimenti non funziona più il grafico della domanda e dell'offerta. Quindi mi pone il problema di sapere cos'è 'sta cosa è e come posso controllarla.
Z: Ma guarda, i geek, come li conosco, del software libero non hanno tanti problemi di gabbie sociali nelle quali vengono messi per impedirgli di esprimersi. Le gabbie contro le quali i geek si ribellano sono le gabbie tecniche. Sono il fatto che tu mi possa dare del software proprietario sul quale io non posso fare nulla o che ho difficoltà a modificare perché non ho un codice sorgente. Quindi adesso non so bene se il technitai avesse coscienza o meno di questa gabbia sociale nel quale può essere messo. I geek come li conosco non hanno problemi di accettazione sociale, anche perché non gliene frega nulla del riconoscimento sociale. Vogliono essere messi in condizioni di possedere e usare tutta la tecnologia software o altro che gli viene messa a disposizione. Quindi la pulsione è nel “io voglio poter fare tutto ciò che voglio con questo software e arrivare fin dove le mie capacità mi permettono” e il software libero, le licenze del software libero sono l'elemento essenziale che permette e che da questa possibilità. Quindi anche la visione hacker se vuoi e del software libero è principalmente “non incatenatemi con meccanismi tecnici che mi impediscono di fare ciò che voglio”, che mi impediscono di divertirmi come piace a me, mi impediscono di mettere in uso le mie skills [capacità – competenze] al meglio. Quindi vi è più una battaglia contro queste costrizioni tecniche. La visione del software libero è un po' più politica e dice non solo gli hacker vogliono questa cosa qua, ma è un dovere morale della società tecnica di oggi di dare a tutti gli utenti questa possibilità, anche se non se lo possono permettere, anche se non lo sanno fare, questo valore politico di libertà che devono dare a tutti gli utenti di software. Io personalmente la vedo un po' più sulle barriere tecniche che non sulle gabbie sociali. Anche perché la maggior parte del lavoro viene fatto … ma in Debian siamo tutti volontari. C'è qualcuno che è pagato per lavorare su qualche aspetto certamente, ma il progetto è un progetto su base assolutamente volontaria. Quindi qualunque gabbia sociale tu voglia mettere agli individui è gente che è libera di farlo nel proprio tempo libero, salvo che non capiti di avere firmato delle clausole assurde in qualche contratto come capita a qualche americano. La mia visione è più sulle gabbie tecniche che non su quelle sociali.
I: Comunque una rivendicazione di spazio, è comunque difficile dire dove finisce la gabbia tecnica e dove invece rivendico uno spazio che sia virtuale o fisico e dove comunque io possa esprimermi. Tu prima hai usato il termine divertirmi, però divertirmi può anche voler dire auto-realizzarmi.
Z: Hai ragione, la differenza è sul fatto che con le barriere tecniche che ci sono con il software proprietario, magari per te sono degli ostacoli sociali, per me no, per me semplicemente è un'idea sbagliata di come si fa economia col software e che è arrivata prima di tutti noi purtroppo, è riuscita ad imporsi sul mercato come cosa giusta, cosa che io ritengo non sia giusta per niente e per questo l'obiettivo principale è liberarsi di questi blocchi, poi se tu ci vedi un disegno dietro o un ruolo sociale questo è possibile chiaramente. Non so se è un disegno ma se riesci a verificarla come vincolo sociale, beh è possibilissimo.
I: Beh, adesso posso anche dirlo perché siamo alla fine di 'sto percorso. Quello che in qualche modo io sto cercando di dimostrare con questo, lo dico adesso …
Z: Così non mi hai influenzato …
I: … è di, partendo da questa rivendicazione di questo spazio, poi tu hai usato anche termini come “non è giusto” che presuppongono un giudizio morale …
Z: Di valore …
I: si, di valore che prescinde dagli aspetti tecnici, tu parli di spazi tecnici, però dici ad un certo punto non è giusto, a questo punto siamo legittimati a parlare di rivendicazione di uno spazio, chiamalo tecnico, di auto-realizzazione o professionale. Ci sarà l'individuo che sarà più interessato a fare business e quello che sarà più interessato a divertirsi. Le motivazioni saranno miscelate diversamente all'interno degli individui. Però quello che io sto cercando di …
Z: Aspetta, giusto una chiarificazione su questo punto. Abbiamo parlato di visioni diverse del fenomeno che tu chiami open source ma che è un po più vasto. La visione del divertirsi è prettamente quella hacker e open source se vogliamo. Il giusto non giusto viene chiaramente dalla visione software libero, free software in inglese, che è una visione prettamente politica, politica in senso lato ovviamente, ed è una visione dove la libertà del software è un valore morale come giustamente hai detto tu e denota tutto un insieme di valori che, io personalmente, ma molta gente in Debian usa per valutare se qualcosa è giusto o no. Quindi in molte comunità del software libero troverai gente che ha questo tipo di valori morali, perché veramente pensiamo che il software proprietario sia un'ingiustizia sociale. Per tornare al tuo principio dell'economia del dove li metto in un contesto economico. Secondo me l'errore di fondo è che sia stato accettato che l'economia del software proprietario funziona facendo pagare il costo di una copia che al produttore non costa nulla, ok? Cioè non è come quando c'è un bene fisico, un'auto o qualsiasi altra cosa che c'è nella nostra società in cui c'è tutta una parte di ricerca e sviluppo a priori, poi c'è la costruzione di un bene fisico che costa qualcosa a chi la produce e che costa qualcosa a chi la compra e in mezzo c'è il guadagno di chi la produce. Nel software l'ottica di vendere il software copia per copia facendo pagare la singola copia è un'ingiustizia nel senso che il produttore non ha alcun costo nel produrre una copia oltre alla prima.
I: Chris DiBona usa il termine “stampare moneta”.
Z: Ecco si, non lo sapevo però esattamente. Cioè, se io di la ho una copia di Ms Windows, o qualsiasi altro software proprietari chi lo produce non ha nessun tipo di costo nel vendere una copia a me e poi vendere una copia a te. Quindi perché deve essere accettabile che ci sia un'economia che di fatto ha accomunato questa tipo di vendita alla vendita di un bene fisico. Anche l'idea che la pirateria è furto è radicata nell'idea sottostante che se io pirato [faccio una copia illegale] il software ti ho rubato il software. Ma se io ti rubo l'auto tu non hai più l'auto e io si, se io ti rubo il software nel senso che lo pirato, tu ce l'hai ancora quel software, quindi l'analogia da qualche parte non funziona. E io personalmente credo che l'ingiustizia del software proprietario venga da lì, venga da questa analogia. Sono stati bravi quelli che hanno portato l'economia del software proprietario ad imporlo alla società, ma quello è l'errore di base secondo me. È invece giustissimo pagare per lo sviluppo di un software! Perché quello costa un sacco di soldi a chi lo fa che ha tutto un risvolto economico, ma che deve essere un costo di sviluppo del software non un prezzo. Non deve essere a posteriori un privilegio del vendere copie del software che sono tutte indistinguibili l'una dall'altra e che non costa niente produrre. Quindi personalmente penso che questa è la radice del valore morale che associato è al software libero. E quando dico è “giusto o non è giusto” lo dico spesso con questo pensiero in back ground.
I: Non l'abbiamo nominato ma sotto c'è il problema del monopolio dei sistemi operativi poi alla fine, no? O meglio, quello che meglio esprime questo problema è questo aspetto. Il fatto sostanzialmente, di questo sistema operativo che ha il monopolio, che lo ha avuto fino adesso e che forse in qualche maniera adesso è minacciato però sostanzialmente ha fornito uno schema di senso al mondo intero e il mondo intero in qualche maniera gli è andato dietro.
Z: secondo me non è solo uno schema di senso di sistemi operativi, ma è uno schema di come si fanno i soldi nel mercato del software. Quindi Microsoft è riuscita a convincere il mondo che i soldi si fanno.
I: Da parte di Microsoft, da parte di chi lo utilizza ha rappresentato uno schema di senso.
Z: Dici interfaccia, sistema di riferimento, mi sfugge il significato di “schema di senso”.
I: L'immagine che io mi faccio di una determinata realtà, i paletti che metto per identificare quella determinata realtà, quella determinata complessità o quella determinata tecnologia che mi sta entrando violentemente nel mio ufficio, nella mia vita e via dicendo. Potrei sintetizzarlo così: ha fornito, in una situazione se vuoi di Babele in cui ognuno parla la sua lingua, lui è arrivato e ha presentato questo modo per parlarsi …
Z: Questo secondo me non è un grosso problema.
I: No no, in effetti non paghiamo le royalties a Dante Alghieri ogni volta che scriviamo un libro o che comunichiamo. Cioè per dire lo schema di senso è la lingua, la scrittura cioè il medium che usi per fare delle cose, come il sistema operativo è un medium tra te e la macchina, tra te e altre persone, tra te e la rete. Tra te e il mondo tecnologico. È un medium comunicativo monopolizzato su cui paghiamo delle royalties.
Z: Mi hai stimolato vari commenti, ma non capisco come tu veda così pervasivo questo schema di senso che ci è venuto dai sistemi Microsoft? Se lo vedi come il fatto che è difficile cambiare, non lo vedo come un problema.
I: No, no la mia è solo una analisi a posteriori di quello che è successo.
Z: loro sono quelli che lo hanno popolarizzato di più, questo è fuori di dubbio, negli anni '90 i personal computers avevano sopra windows e basta, sono quelli che li hanno resi più popolari di tutti indubbiamente, ma sia i sistemi operativi che le interfacce esistevano da ben prima, le metafore per l'interazione con le macchine esistevano da ben prima e sono sostanzialmente le stesse che ci sono tuttora oggi, oggi c'è stata un po di più evoluzione ma questo è un altro discorso. Ora non so come si definisca lo schema di senso, se si intende in termini di diffusione o se si riferisce in termini “da dove viene l'idea”, perché se il punto è l'idea, beh quella non l'hanno certo inventata loro.
I: no, in effetti, ma questo a maggior ragione rende l'idea. Sono convinto anch'io che non sia stato Dante Alghieri ad inventare la lingua italiana, caso mai l'avrà sistematizzata, forse nel caso dei sistemi operativi non è successo neanche quello. Al di la del fatto che se li sia fatti, che se li sia comprati, che se ne sia appropriato è successo e che questo abbia i giorni contati oppure no è irrilevante, io sto descrivendo quel sistema li che può finire domani mattina …
Z: può durare altri cinquant'anni …
I: La sociologia non fa previsione cerca solo di comprendere.
Commiato.