Colonizzare la noosfera/Cause di conflitto
 |
Questo testo è completo. | |
Traduzione dall'inglese di Bernardo Parrella (1999)
| ◄ | Proprietà noosferica e etologia del territorio | Struttura e proprietà di un progetto | ► |
Sono riconducibili a quattro le maggiori aree di conflitto all’interno del software open source:
- Chi prende le decisioni vincolanti su un progetto?
- A chi addossare meriti e demeriti per cosa?
- Come ridurre la duplicazione degli sforzi ed evitare che versioni volanti complichino la ricerca dei bug?
- Tecnicamente parlando, qual è la giusta cosa da fare?
Se diamo per un momento un’occhiata all’ultima questione, tuttavia, essa tende a sparire. Come premessa, occorre stabilire l’esistenza, o meno, di un modo oggettivo di decidere se questa giusta cosa venga accettata da tutte le entità coinvolte. Qualora ciò non sia possibile, la domanda si riduce a “chi decide?”
Di conseguenza, le tre possibili cause di conflitti da risolvere riguardo un progetto sono: (A) dove ci si ferma per le decisioni relative al design, (B) in che modo decidere quali collaboratori prenderanno il merito e secondo quali modalità, (C) come far sì che il gruppo e il prodotto non si scompongano in più diramazioni.
Nella risoluzione dei punti (A) e (C) appare evidente il ruolo delle consuetudini in tema di proprietà. Le usanze sostengono che tocca ai proprietari del progetto prendere le decisioni vincolanti. Abbiamo già osservato come tali usanze esercitino forti pressioni contro lo stemperamento della proprietà tramite la scissione dei progetti.
È interessante notare l’appropriatezza di tali convenzioni anche se qualcuno dovesse dimenticare il gioco della reputazione, riesaminandole all’interno del modello puramente “artigianale” della cultura hacker. In questo caso, le consuetudini hanno meno a che fare con la diluizione degli incentivi per la reputazione e sono invece più tese a proteggere il diritto dell’artigiano di portare a termine la sua visione secondo le proprie modalità operative.
Tuttavia, il modello artigianale non è di per sé sufficiente a spiegare le convenzioni hacker riguardo il punto (B), chi prende il merito e per cosa (perché un artigiano puro, disinteressato al gioco della reputazione, non avrebbe motivo di preoccuparsene). Per analizzare la questione, dobbiamo portare un passo più avanti la teoria di Locke, passando in esame i conflitti e le operazioni relative ai diritti di proprietà sia all’interno dei progetti stessi sia tra di loro.