L’allontanamento volontario di Linus dalla guida del progetto ha creato un terremoto organizzativo – pienamente prevedibile -, insieme alla necessità di nuove soluzioni; molti attriti tra sviluppatori potevano essere risolti sul nascere grazie alla sola presenza del dittatore benevolo: decide lui, punto.
L’introduzione, come ultimo atto, di un CoC (Codice di Condotta) è sembrata a molti un’imposizione, il tracciamento di un perimetro troppo stretto. Va detto che l’oganizzazione piramidale (praticamente il re coi valvassori del medioevo) di cui era vertice Linus non era più sostenibile senza il vertice, e quindi un’alternativa era necessaria; il CoC sembrava un buon punto di partenza.

E forse lo è per davvero, con le discussioni per alcune limature avviate dal giorno dopo. Non solo critiche, ma vere e proprie proposte di modifica, nello stesso stile tipico delle discussioni tecniche per il software opensource. Tanto simile, che la prima proposta ufficiale di modifica è stata fatta nella mailing list dello sviluppo del kernel, nella forma di una patch:

In order to move the debate on, I’m presenting two patches, one to fix the email problem Mauro identified and the other to strip the enforcement section pending community discussion as Shuah suggested.

Per permettere alla discussione di andare avanti, presento due patch, uno per correggere il problema delle email identificato da Mauro, l’altro per rimuovere la sezione di controllo delle discussioni della community, come suggerito da Shuah.

Le due questioni rigurdano due aspetti molto lontani tra loro, tanto che è James Bottomley stesso, l’autore, a dire di poter essere separate in due patch specifiche. In particolare:

• il problema delle email
  Questo è un problema più formale che sostanziale: nel codice attuale si vieta la pubblicazione di informazioni personali, indirizzi email compresi; ma quegli indirizzi fanno parte integrante del processo di sviluppo (per esempio, identificano gli autori dei contributi al kernel). Viene proposta l’aggiunta di un’eccezione per questi casi, ovvero si mantiene il divieto per indirizzi non collezionati normalmente dal progetto (not ordinarily collected by the project).
• rimuovere la sezione di controllo delle discussioni della community
  Qui il problema, pur sembrando solo formale, è più sostanziale. Il codice prevede che, in caso di violazione dello stesso in una discussione, sia il TAB (Technical Advisory Board – organo di consiglio tecnico), previo avviso, a dover dirimere la questione e decidere. L’obiezione è che semplicemente questo organo non nasce come moderatore interno, né ne ha mai svolto il ruolo, ma solo come interlocutore per la Linux Foundation, e sempre per dirimere questioni prettamente tecniche. La proposta è semplicemente omettere la questione, in attesa di identificare o costituire un organo più appropriato, evitando di legarsi a qualcosa di sbagliato.

L’uso della mailing list del kernel sembra anche appropriata: pur non essendo questioni tecniche, con fix di vecchie funzioni o proposte di nuove integrazioni, il CoC è parte del kernel, come – per esempio – la licenza GPL.
L’esempio dell’invio di patch è già stato seguito da un’altra proposta, e siamo sicuri ne seguiranno molte altre. Insomma, le prime prove di democrazia sono incoraggianti!

Marco Bonfiglio

Ho coltivato la mia passione per l’informatica fin da bambino, coi primi programmi BASIC. In età adulta mi sono avvicinato a Linux ed alla programmazione C, per poi interessarmi di reti. Infine, il mio hobby è diventato anche il mio lavoro.
Per me il modo migliore di imparare è fare, e per questo devo utilizzare le tecnologie che ritengo interessanti; a questo scopo, il mondo opensource offre gli strumenti perfetti.