Colonizzare la noosfera/Struttura e proprietà di un progetto
 |
Questo testo è completo. | |
Traduzione dall'inglese di Bernardo Parrella (1999)
| ◄ | Cause di conflitto | Conflitti e risoluzioni | ► |
Il caso più ovvio è quando esiste un’unica persona che ha la proprietà o il mantenimento del progetto. È costui che prende ogni decisione e gestisce meriti e demeriti. Gli unici conflitti possibili nascono dalle questioni sulla successione – chi sarà il nuovo proprietario se il vecchio sparisce o non ha più interesse. Occorre tener conto anche della necessità della comunità, secondo il punto (C), nel prevenire potenziali biforcazioni del progetto. Interessi espressi nella norma culturale per cui chi ne è proprietario/mantenitore, nel caso non possa più seguire il progetto, dovrebbe passarne pubblicamente la qualifica a qualcuno che ritenga adatto.
Il caso più semplice delle situazioni meno ovvie è quando un progetto ha diverse persone che si occupano del mantenimento, i quali lavorano alle direttive di un “dittatore amichevole” che è proprietario del progetto. Le consuetudini favoriscono tali circostanze per progetti ampi come il kernel di Linux o Emacs, e risolvono il problema del “chi decide” in maniera nient’affatto peggiore di ogni altra possibile alternativa.
Tipicamente è un’organizzazione a dittatura amichevole quella che emerge quando il fondatore attira dei collaboratori. Pur restando una sorta di dittatore, il proprietario introduce un nuovo livello di possibili dispute sulla scelta di chi deve avere il merito e per quale parte del progetto.
In questa situazione, le usanze impongono al proprietario/dittatore l’obbligo di assegnare correttamente i meriti (per esempio, tramite le appropriate menzioni nel file contenente la cronologia delle versioni o nel README). Secondo il modello di proprietà di Locke, ciò significa che contribuendo a un progetto, in cambio ci si merita parte della reputazione complessiva (positiva o negativa).
Seguendo questa logica, vediamo che in realtà il dittatore amichevole non detiene l’intero progetto senza essere in possesso delle necessarie qualifiche. Pur avendo il diritto di prendere le decisioni vincolanti, in effetti egli commercia varie parti della reputazione complessiva in cambio del lavoro altrui. L’analogia con la condivisione del raccolto in un podere è quasi irresistibile, ad eccezione del fatto che il nome del collaboratore rimane nei “credit” e continua a “guadagnare” qualcosa anche quando non svolge più alcuna parte attiva nel progetto.
Quando nuovi partecipanti si aggiungono ai progetti gestiti da dittatori amichevoli, questi ultimi tendono a dividere in due filoni i collaboratori: quelli ordinari e i co-sviluppatori. Il percorso tipico per divenire co-sviluppatore è assumere la responsabilità di un sottosistema importante del progetto. Un altro è assumere il ruolo del “grande sistematore”, ovvero di chi mette a fuoco e sistema i vari bug. In un modo o nell’altro, i co-sviluppatori sono coloro che investono del tempo nel progetto in maniera sostanziale e continuata.
Il ruolo del proprietario di sottosistema è particolarmente importante per la nostra analisi e merita ulteriori approfondimenti. Agli hacker piace dire che “l’autorità fa seguito alla responsabilità”. Un co-sviluppatore che accetta la responsabilità per la gestione di un certo sottosistema generalmente arriva a controllare sia l’implementazione di quest’ultimo sia l’interfaccia con il resto del progetto, soggetto soltanto a correzioni da parte del leader (che agisce a mo’ di architetto). È il caso di notare come questa regola in pratica produca una serie di proprietà chiuse all’interno di un progetto, secondo il modello di Locke, e svolga esattamente la medesima funzione di prevenzione dei conflitti ricoperta da altri tipi di confini a difesa della proprietà.
Secondo le convenzioni, ci si aspetterebbe che il “dittatore” o il leader in un progetto cui collaborano altre persone, le consulti in occasione di decisioni chiave. Ciò soprattutto quando la decisione riguarda un sottosistema di “proprietà” di un co-sviluppatore (il quale, per meglio dire, vi ha investito tempo e ne ha assunto la responsabilità). Un leader sapiente, riconoscendo la funzione dei confini per le proprietà interne del progetto, non interferirà minimamente né modificherà le decisioni prese dai proprietari di sottosistemi.
Alcuni progetti molto ampi non consentono piena aderenza al modello del “dittatore amichevole”. Un modo di superarlo è trasformare i co-sviluppatori in un comitato votante (è il caso di Apache). Un altro è la rotazione della funzione di leader, dove il controllo viene occasionalmente trasferito da un membro all’altro all’interno della cerchia dei co-sviluppatori anziani (gli sviluppatori Perl si organizzano così).
Queste complicate aggregazioni vengono considerate del tutto instabili e difficili. Chiaramente si tratta di una difficoltà che per lo più fa parte dei noti pericoli insiti nell’organizzazione di un “comitato di design”, oltre che nei comitati in quanto tali; si tratta di problemi che la cultura hacker comprende in piena coscienza. Credo tuttavia che parte del viscerale sconforto che gli hacker provano rispetto ai comitati o alla rotazione dei leader, derivi dal fatto che questi casi entrino con difficoltà in quel modello di Locke utilizzato inconsciamente dagli hacker per risolvere le questioni più semplici. Quando le organizzazioni si fanno così complesse, risulta problematico verificare le funzionalità della proprietà sia nel senso del controllo sia del ritorno di reputazione. È difficile vedere con esattezza la posizione dei confini interni, e quindi altrettanto difficile evitare i conflitti, a meno che il gruppo non goda di un livello eccezionalmente alto di armonia e fiducia reciproca.