Colonizzare la noosfera/Proprietà e open source: differenze tra le versioni

{{Qualità|avz=100%|data=20 luglio 2008|arg=Open Source}}{{IncludiIntestazione|sottotitolo=Proprietà e open source|prec=../Teoria promiscua, pratica puritana|succ=../Locke e la proprietà terriera }}

È 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'internoall’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'interanell’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'iniziodall’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.

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'exl’ex-proprietario non abbia passato il controllo volontariamente, lo riassuma con l'apportol’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'areaall’area di quell'applicazionequell’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'autol’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'exall’ex-proprietario di farsi avanti, e più l'acquisizionel’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'interal’intera comunità.

Per vent'annivent’anni ho osservato il dipanarsi di queste consuetudini in azione, fin dall'epocadall’epoca dell'anticadell’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'evoluzionel’evoluzione di, letteralmente, centinaia di progetti open source, e posso contare sulle dita le violazioni significative viste o riportate all'iterall’iter descritto sopra.

Terza caratteristica interessante è l'evoluzionel’evoluzione di tali consuetudini nel corso del tempo, spostatesi sempre verso un'unicaun’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'altrol’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'internoall’interno della cultura open source che risulta assolutamente fondamentale alle modalità in cui si esprime.