Colonizzare la noosfera/Conflitti e risoluzioni: differenze tra le versioni

Da Wikisource.
Contenuto cancellato Contenuto aggiunto
m Porto il SAL a SAL 100%
Kronin (discussione | contributi)
Nessun oggetto della modifica
Riga 1: Riga 1:
{{Qualità|avz=100%|data=24 aprile 2008|arg=Open source}}{{open source
{{Qualità|avz=100%|data=20 luglio 2008|arg=Open Source}}{{Intestazione Open Source
|NomeCognome=Eric Steven Raymond
| Nome e cognome dell'autore = Eric Steven Raymond
|Titolo=Colonizzare la noosfera
| Titolo = Colonizzare la noosfera
| Iniziale del titolo = C
|NomePagina=Colonizzare la noosfera
| Nome della pagina principale = Colonizzare la noosfera
|Anno=
|TitoloSezione=Conflitti e risoluzioni
| Eventuale titolo della sezione o del capitolo = Conflitti e risoluzioni
| Anno di pubblicazione = 1998
}}
| Eventuale secondo anno di pubblicazione =
| Secolo di pubblicazione = XX secolo
| Il testo è una traduzione? = si
| Lingua originale del testo = inglese
| Nome e cognome del traduttore = Bernardo Parrella
| Anno di traduzione = 1999
| Secolo di traduzione = XX secolo
| Abbiamo la versione cartacea a fronte? =
| URL della versione cartacea a fronte =
}}
{{capitolo
{{capitolo
|CapitoloPrecedente=Struttura e proprietà di un progetto
|CapitoloPrecedente=Struttura e proprietà di un progetto

Versione delle 20:46, 20 lug 2008

Template:Intestazione Open Source

◄   Struttura e proprietà di un progetto Meccanismi d'acculturazione e connessioni con il mondo accademico   ►

Abbiamo visto come all'interno dei progetti, la crescente complessità dei ruoli venga espressa tramite la distribuzione dell'autorità per il design e dei parziali diritti di proprietà. Mentre ciò appare un modo efficace per la circolazione degli incentivi, al contempo provoca la diluizione dell'autorità del leader – fatto ancor più importante, tende a stemperare la sua autorità nei frangenti relativi al blocco di potenziali conflitti.

Pur se le questioni tecniche relative al design sembrano costituire i maggiori rischi per conflittualità interne, raramente questi casi portano a seri litigi. In genere vengono facilmente risolti seguendo la regola territoriale per cui l'autorità fa seguito alla responsabilità.

Un altro modo di risoluzione dei conflitti è per anzianità – nel caso di disputa obiettivamente irrisolvibile tra due collaboratori o gruppi di collaboratori, dove nessuno dei due sia proprietario del territorio in cui essa avviene, vince la parte che ha dedicato maggior tempo e lavoro al progetto nel suo insieme (ovvero, la parte che detiene più diritti di proprietà nell'intero progetto).

In genere queste regole risultano sufficienti per risolvere la maggior parte delle dispute relative a un progetto. Quando ciò non sia possibile, normalmente è l'autorità del leader a risolvere la questione. Sono assai rari i conflitti che sopravvivono a entrambi questi filtri.

Normalmente i conflitti non divengono faccenda seria a meno che questi due criteri (“l'autorità fa seguito alla responsabilità” e “vince il più anziano”) tendano verso direzioni opposte, mentre l'autorità del leader risulta debole o assente. Il caso più comune in cui ciò può verificarsi è una disputa per la successione che insorge a seguito della scomparsa del leader del progetto. Mi è capitato di trovarmi coinvolto in un litigio di questo tipo. È stato qualcosa di amaro, penoso, interminabile, risoltosi soltanto quando tutte le parti coinvolte furono talmente esauste da decidere di passare volentieri il controllo a una persona esterna. Spero devotamente di non dovermi mai più trovare in qualcosa di simile.

In conclusione, tutti questi meccanismi per la risoluzione dei conflitti poggiano sulla volontà di applicarli da parte della comunità hacker nel suo insieme. Gli unici meccanismi a disposizione per imporli sono le “flame” e l'allontanamento – condanne pubbliche di quanti hanno infranto le convenzioni, e successivo rifiuto a cooperare ulteriormente con loro.

◄   Struttura e proprietà di un progetto Meccanismi d'acculturazione e connessioni con il mondo accademico   ►