# Colonizzare la noosfera/Proprietà e open source

../Teoria promiscua, pratica puritana ../Locke e la proprietà terriera IncludiIntestazione 8 settembre 2014 75% Open Source
Colonizzare la noosfera Eric Steven Raymond 1998 CC BY-SA 3.0 GFDL //it.wikisource.org/w/index.php?title=Colonizzare_la_noosfera/Propriet%C3%A0_e_open_source&oldid=- 20140908154134 //it.wikisource.org/w/index.php?title=Colonizzare_la_noosfera/Propriet%C3%A0_e_open_source&oldid=- 20140908154134
Cosa s’intende con “proprietà” quando questa è replicabile all’infinito, altamente malleabile, e la cultura circostante non è dotata né di relazioni di potere coercitivo né dell’economia derivante dalla penuria di materiali?
In realtà, nel caso della cultura open source si tratta di una domanda dalla risposta facile. Soltanto il proprietario (o i proprietari) di un progetto detiene il diritto esclusivo, riconosciutogli dall’intera comunità, di ridistribuire le versioni modificate.
(Nella discussione sulla “proprietà” in questo capitolo, userò il singolare, come se ogni progetto fosse di proprietà di un solo individuo. È tuttavia ovvio che potrebbe anche trattarsi di gruppi di persone. Le dinamiche interne di tali gruppi verranno esaminate più avanti).
Secondo le licenze standard open source, tutte le entità coinvolte rivestono il medesimo ruolo nel gioco evolutivo. In pratica esiste però una distinzione molto ben riconosciuta tra gli aggiustamenti “ufficiali” – approvati e integrati nel software in evoluzione da parte di quanti, pubblicamente riconosciuti, si occupano della sua gestione – e quelli “volanti” realizzati da terze parti. In genere questi sono rari, e non riscuotono molta fiducia.
È facile comprendere perché la ridistribuzione pubblica si riveli una questione fondamentale. La convenzione incoraggia la gente a farsi le proprie “patch” per uso personale ogni volta che sia necessario. Le consuetudini mostrano indifferenza nei confronti di quanti ridistribuiscono versioni modificate all’interno di un gruppo chiuso di utenti o di sviluppatori. La proprietà diviene invece questione centrale soltanto quando le modifiche, in competizione con la versione originale, vengono diffuse nell’intera comunità open source.
In generale ci sono tre modi per acquisire la proprietà di un progetto open source. Uno, il più ovvio, è avviare la nascita del progetto. Se fin dall’inizio esso è stato mantenuto da una sola persona e questi è ancora attivo, la consuetudini non permettono neppure di chiedere a chi appartenga la proprietà del progetto.
La seconda maniera è ottenere la proprietà del progetto dal proprietario precedente (anche noto come “il passaggio del testimone”). È ben chiaro alla comunità che i proprietari hanno il dovere di passare i progetti a successori competenti, quando non possono o non vogliono più investire il tempo necessario nel lavoro di sviluppo o di mantenimento.
Risulta significativo che nel caso di grossi progetti, tali trasferimenti del controllo normalmente vengono annunciati con una certa enfasi. Mentre non sono noti casi di interferenza da parte della comunità open source sui successori scelti dai proprietari, la pratica convenzionale incorpora chiaramente la legittimazione pubblica come fatto importante.
Per progetti minori, generalmente è sufficiente includere il cambio di proprietà nella storia dei cambiamenti inclusa in calce a ogni progetto. Chiaramente si presume che se l’ex-proprietario non abbia passato il controllo volontariamente, lo riassuma con l’apporto della comunità dopo aver esposto le obiezioni in pubblico entro un ragionevole periodo di tempo.
Il terzo modo per acquisire la proprietà di un progetto è far presente che questo ha bisogno di lavori e il proprietario è scomparso o ha perso interesse. Chi volesse procedere, ha prima la responsabilità di cercare il proprietario. Se ciò risulta impossibile, allora va annunciato in un luogo ben visibile (tipo, il newsgroup di Usenet dedicato all’area di quell’applicazione) che il progetto sembra esser orfano, e che si vorrebbe assumerne la responsabilità.
Secondo la convenzione, occorre far trascorrere un certo periodo di tempo prima di procedere con l’auto-dichiarazione di essere il nuovo proprietario. In questo intervallo, se qualcun altro annuncia di aver lavorato al progetto, tocca prima a lui. È considerata buona educazione rendere note pubblicamente e più volte le proprie intenzioni. Come pure farlo in molti forum rilevanti (newsgroup e mailing list attinenti). Ancor meglio se si dimostra pazienza in attesa di risposte. In generale, più sono visibili gli sforzi per consentire all’ex-proprietario di farsi avanti, e più l’acquisizione risulterà comprovata.
Una volta seguito questo iter in mancanza di obiezioni, sarà possibile dichiararsi proprietari del progetto orfano e annotare ciò nelle note. Tale processo risulta però meno sicuro del passaggio del testimone, e non ci si potrà considerare pienamente legittimati fino a quando non si siano apportati miglioramenti sostanziali per l’intera comunità.
Per vent’anni ho osservato il dipanarsi di queste consuetudini in azione, fin dall’epoca dell’antica storia pre-FSF del software open source. Vale la pena sottolinearne alcuni tratti caratteristici. Il più interessante è il fatto che la maggior parte degli hacker ha seguito tale processo senza rendersene granché conto. Non a caso quanto enunciato sopra potrebbe rivelarsi il primo tentativo cosciente e ragionevolmente completo di elaborarne un riassunto scritto.
Altro tratto degno di nota è il fatto che queste convenzioni inconsce sono state seguite con una coerenza notevole e perfino incredibile. Ho osservato personalmente l’evoluzione di, letteralmente, centinaia di progetti open source, e posso contare sulle dita le violazioni significative viste o riportate all’iter descritto sopra.
Terza caratteristica interessante è l’evoluzione di tali consuetudini nel corso del tempo, spostatesi sempre verso un’unica direzione. Ovvero quella di stimolare maggior responsabilità pubblica, maggior attenzione collettiva e maggior cura nel preservare i nomi dei partecipanti e le cronologie delle modifiche in ogni progetto, così da stabilire, tra l’altro, la legittimità dei proprietari correnti.
Queste caratteristiche sono la testimonianza della non casualità delle abitudini in uso, rivelandosi anzi queste il risultato di un qualche tipo di una pianificazione implicita o di un percorso generativo sviluppatosi all’interno della cultura open source che risulta assolutamente fondamentale alle modalità in cui si esprime.
Uno dei primi commenti ricevuti sottolineava come il contrasto tra la cultura hacker su Internet e quella dei cracker/pirati (il “warez d00dz” centrato sul gioco del “cracking” e le bulletin-board pirate) chiariva abbastanza bene i percorsi generativi di entrambe. Torneremo al “d00dz” come contrasto più avanti in questo saggio.