Come conseguenza del fatto che l'industria maturava avvennero molti cambiamenti. La grande varietà del software prodotto diede strada ai pochi chiari vincitori—vincitori per la tecnologia superiore, per una organizzazione commerciale superiore, o una combinazione delle due cose. Allo stesso tempo, e non completamente in simultaneità, lo sviluppo dei cosiddetti linguaggi di “alto livello” volle dire che uno avrebbe potuto scrivere un programma una volta sola in un unico linguaggio e ottenere che esso fosse tradotto (“compilato”) in modo da poter girare su differenti tipi di computer. Le implicazioni di ciò non furono perse dai costruttori di hardware. Il cliente così poteva dedicarsi a un impegno maggiore nello sviluppo del software senza necessariamente limitarsi a farlo in relazione a una specifica architettura. Quando ciò si combinò con una graduale diminuzione delle differenze di prestazione dei vari computers man mano che i progetti meno efficienti furono fatti fuori un costruttore che considerasse il suo hardware come sua unica risorsa poteva prevedere un futuro di margini di guadagno in diminuzione. Da sola la potenza di calcolo stava diventando un bene commerciale e il software faceva la differenza. Vendere software o almeno trattarlo come parte della vendita di hardware cominciò a sembrare una buona strategia.

Ciò significò che i costruttori dovettero incominciare a rafforzare i diritti d'autore sul loro codice in maniera più rigorosa. Se gli utilizzatori avessero continuato a scambiarsi il codice e a condividene i cambiamenti liberamente, essi avrebbero potuto reimplementare alcuni dei miglioramenti ora venduti come “valore aggiunto” dal fornitore. Peggio, il codice condiviso avrebbe potuto finire nella mani dei concorrenti. L'ironia è che questo stava succedendo nel tempo che Internet stava emergendo. Proprio quando il software veramente non impedito stava finalmente diventando tecnicamente possibile, i cambiamenti nell'affare dei computers lo rendeva indesiderabile almeno dal punto di vista di ogni singola compagnia. I fornitori misero un freno sia negando l'accesso agli utilizzatori al codice che girava sulle proprie macchine sia insistendo su un accordo di non apertura che rende il codice condivisibile.

Senza enumerare ogni progetto e ogni licenza si può dire di sicuro che dagli ultimi '80 ci fu molto software libero disponibile sotto una grande varietà di licenze. La diversità delle licenze rifletteva la diversità delle motivazioni. Anche alcuni dei programmatori che avevano scelto la GNU GPL erano molto meno spinti da motivi ideologici di quanto lo fosse il GNU project. Anche se erano contenti di lavorare al software libero molti sviluppatori non consideravano il software proprietario un male sociale. Ci fu gente che sentì l'impulso morale di liberare il mondo del "software hoarding" (termine di Stallman per software non libero) ma altri erano motivati più da sollecitazioni tecniche o dal piacere di lavorare con collaboratori della stessa opinione o persino da un un semplice umano desiderio di gloria. Eppure tutto sommato queste disparate motivazioni non interagirono in modo distruttivo. Ciò è dovuto in parte al fatto che il software, a differenza della altre forme creative come la prosa o le arti visive, deve superare dei tests per metà oggettivi per essere considerato di successo. Ciò dà a tutti i partecipanti a un progetto una specie di automatica base comune, una ragione e una struttura per lavorare insieme senza tanta preoccupazione di qualificazioni oltre quella tecnica.

Gli sviluppatori ebbero un'altra ragione per unirsi. Risultò che il mondo del software libero stava producendo qualche codice di alta qualità. In alcuni casi esso era in modo dimostrabile tecnicamente superiore all'alternativa non libera. In altri esso era almeno comparabile e certamente costava meno. Mentre solo alcuni erano motivati a far girare sul computer il software libero per motivi strettamente filosofici, una grande quantità di persone era contenta di farlo perchè svolgeva meglio un compito. E quelli che lo usavano erano spesso intenzionati a spendere tempo e mettere a disposizione capacità per rendersi utili a svolgere compiti di manutenzione e miglioramento del software.

Questa tendenza a produrre buon codice non era universale ma si stava affermando con crescente frequenza in progetti di software libero in giro per il mondo. Imprese che trattavano principalmente software incominciarono gradualmente ad averne notizia. Molte di esse scoprirono che stavano già usando software libero nelle operazioni giornaliere solo che semplicemente non lo avevano saputo (la parte superiore dell'organizzazione spesso non è a conoscenza di ciò che il dipartimento IT fa). Le grandi imprese incominciarono ad assumere un ruolo sempre più attivo nei progetti di software libero, contribuendo con tempo e mezzi e a volte persino finanziando lo sviluppo di programmi liberi. Tali investimenti nel migliore degli scenari avrebbero potuto ripagarli molte volte di seguito. Lo sponsor paga solo un piccolo numero di programmatori esperti affinchè essi si dedichino al progetto a tempo pieno ma raccoglie i benefici del contributo di ognuno incluso il lavoro non pagato dei volontari e dei programmatori pagati da altre grandi imprese.

Nella misura in cui le grosse imprese guardavano con sempre più attenzione al software libero i programmatori erano messi di fronte ai nuovi problemi della presentazione. Uno era la parola “free” in se stessa. In un primo momento nell'ascoltare la parola “free” molta gente pensava erroneamente che questa significava semplicemente software a "costo zero". E' vero che tutto il software libero è a costo zero, ma non tutto il software a costo zero è libero.^[7] Per esempio, durante la battaglia dei browsers negli anni '90 sia Microsoft che Netscape diedero via i propri browsers in competizione gratis, nella zuffa per accaparrarsi un fetta di mercato. Nessuno dei due browsers era libero nel senso di “software libero”. Non si poteva ottenere il codice sorgente e anche si si fosse potuto ottenere non si aveva il diritto di modificarlo e redistribuirlo. ^[8] L'unica cosa che si poteva fare era scaricare un eseguibile e farlo girare sul computer. I browsers erano non più liberi di un software incartato comprato in un negozio. Essi avevano soltanto un prezzo abbastanza basso.

Questa confusione sulla parola “free” è dovuta a una sfortunata ambiguità nella lingua inglese. Molte altre lingue distinguono fra prezzi bassi e libertà (la distinzione fra gratis e libre è chiara immediatamente a coloro che parlano una lingua neolatina, per esempio. Ma a causa della posizione della lingua inglese come lingua ponte di fatto di Internet, un problema con la lingua inglese è in una certa misura un problema per chiunque. L'incomprensione sulla parola “free” era così prevalente che i programmatori di software libero alla fine elaborarono una formula standard nella risposta: “E' libero nel senso di in in regime di libertà—il pensiero libertà di parola, non il pensiero birra gratis." Comunque doverlo spiegare ancora e ancora è stancante. Molti programmatori ebbero la sensazione, non ingiustificata, che l'ambiguità della parola “free” stava ostacolando la comprensione di questo software.

Ma il problema diventò più profondo di così. La parola “free” portò con sè una inevitabile connotazione morale. Se in effetti la libertà era un fine, non era importante il fatto che che potesse succedere che il software libero fosse migliore oppure più profittevole per certi affari in certe circostanze. Quelli erano graditi effetti secondari di una causa che non era in fondo né tecnica né mercantile, ma morale. Inoltre la collocazione di “libero nel senso di in libertà” evidenziò una chiara incoerenza delle grosse imprese che da un lato dei propri affari volevano supportare particolari programmi liberi mentre dall'altro continuavano a commerciare software proprietario.

Sopraggiunsero questi dilemmi per una comunità che si trovava già in sospeso per una crisi di identità. I programmatori che realmente scrivevano software libero non erano stati mai unanimi su tutti gli obiettivi, se ce n'erano, del movimento del software libero. Persino dire che che le opinioni vanno da un estremo all'altro sarebbe fuorviante, giacchè ciò farebbe erroneamente pensare che esso sia in una zona lineare invece che in una dispersione multidimensionale. Comunque si possono distinguere due categorie di pensiero, se vogliamo ignorare le sottigliezze per il momento. Un gruppo fa proprie le vedute di Stallman che la libertà di condividere e modificare è la cosa più importante e che quindi se si finisce di parlare di libertà si perde il cuore della questione. Altri sentono che il software è l'argomento più importante in favore del software stesso e trovano scomodo proclamare che il software proprietario è cattivo per il fatto di essere software proprietario. Alcuni, ma non tutti i programmatori pensano che l'autore (e chi lo impiega, nel caso di lavoro pagato) dovrebbe avere il diritto di controllare termini della distribuzione e che non c'è bisogno di dare nessun giudizio morale sulla scelta dei particolari termini.

Per lungo tempo non ebbero bisogno di essere esaminate e coordinate ma il nascente successo del software libero nel mondo del business rese il problema ineludibile. Nel 1998 il termine open source fu creato in alternativa a “libero” da una colizione si programmatori che alla fine diventarono l' Open Source Initiative (OSI).^[9] L'OSI si convinse non solo che il “software libero” era potenzialmente portatore di confusione ma che la parola “libero” era appunto un sintomo di un problema generale: che il movimento aveva bisogno di un programma di marketing per agganciarsi al mondo delle grandi imprese, e che il discorso della morale e di benefici sociali non avrebbe mai preso il volo al tavolo dei consigli di amministrazione. Nelle loro parole:

Le punte dei molti icebergs della controversia sono visibili in questo testo. Esso si riferisce alle “nostre convinzioni” ma evita abilmente di parlare di cosa esattamente siano le nostre convinzioni. Per qualcuno potrebbe essere la convinzione che il codice sviluppato in accordo con un processo aperto sarà un codice migliore; per altri potrebbe essere la convinzione che tutte le informazioni debbano essere condivise. C'è l'uso della parola “furto” per riferirsi (presumibilmente) alla copia illegale. Uso su cui molti hanno da ridire, sulla base del fatto che non è furto se tuttavia il possessore ne ha la notizia dopo. C'è il fatto che è allettante lasciar credere che il movimento del software libero potrebbe erroneamente essere accusato di anti comercialismo, ma si lascia non attentamente esaminata la questione se una tale accusa abbia di fatto una base.

Nessuna delle quali cose voleva dire che il sito dell'OSI era incoerente o ingannevole. Piuttosto era un esempio di quello che esattamente l'OSI dichiarava essere stato perso dal movimento del software libero: il “buon marketing” dove “buon” sta per “attuabile ne mondo degli affari”. L'Open Source Initiative diade a tanta gente esattamente quello di cui erano andati in cerca: un vocabolario per parlare del software libero come metodologia di sviluppo del software e di strategia di affari, non come una crociata morale.

Mettetevi nei panni di qualcuno che ha appena saputo del vostro progetto, forse per essersi imbattuto in esso alla ricerca di un software che risolvesse il suo problema. La prima cosa che egli incontra è il nome del progetto.

Un bel nome non renderà il vostro progetto un progetto di successo e un brutto nome non lo rovinerà;—beh, un nome veramente brutto potrebbe farlo, ma noi partiamo dall'ipotesi che nessuno stia cercando di far fallire il proprio progetto. Comunque, un brutto nome può rallentare l'adozione di un progetto, sia perchè la gente non lo prende seriamente, sia perchè semplicemente ha difficoltà a ricordarlo.

Un nome bello:

Una volta che avete trovato il sito web del progetto, la cosa successiva che la gente cercherà è una breve ma veloce descrizione, una dichiarazione di intenti in modo da poter decidere (in 30 secondi) se è interessata a saperne di più. Questa deve essere messa in evidenza in prima pagina, preferibilmente sotto al nome del progetto.

La dichiarazione di intenti deve essere concreta, limitativa, e soprattutto breve. Qui c'è n'è un esempio di una buona, da http://www.openoffice.org/:

Giusto in poche parole, essi hanno centrato tutti i punti principali prendendo largamente ispirazione dalla conoscenza precedente dei lettori. Dicendo "come comunità", essi segnalano che nessuna grossa impresa dominerà lo sviluppo; "internazionale" significa che il software permetterà alla gente di lavorare in molti lingue e luoghi; "Tutte le principali piattaforme" significa che esso sarà trasportabile su Unix, Macintosh, e Windows. Il resto segnala che le interfacce aperte e i formati facilmente comprensibili sono una parte importante dell' obiettivo. Essi non vengono direttamente allo scoperto e dicono che stanno cercando di essere una alternativa libera all'Office della Microsoft, ma molta gente può verosimilmente leggere tra le righe. Sebbene questa dichiarazione di intenti sembri ampia ad una prima occhiata, nei fatti è piuttosto circoscritta: le parole "swite per ufficio" hanno il significato di qualcosa di molto concreto a quelli che sono familiari con questo software .Inoltre la presunta precedente conoscenza del lettore (in questo caso probabilmente di Office della Microsoft) è usata per mantenere concisa la dichiarazione di intenti.

La natura di una dichiarazione di intenti dipende in parte da chi la sta scrivendo, non dal software che descrive. Per esempio per Openoffice.org ha senso usare le parole "come una comunità", perchè il progetto fu avviato ed è ancora sponsorizzato da Sun Microsystems. Includendo quelle parole Sun manifesta la sua sensibilità alle preoccupazioni circa il fatto che essa potrebbe dominare il processo di sviluppo. Con una cosa di questo tipo, dimostrando unicamente la consapevolezza del potenziale per un problema va lontano nell'evitare del tutto il problema. D'altra parte i progetti che non sono sponsorizzati da una singola grande impresa non hanno bisogno probabilmente di un simile linguaggio; dopotutto lo sviluppo da parte di una comunità è la norma, sicchè non ci sarebbe ragione di metterlo in lista come parte degli intenti.

Quelli che restano interessati dopo aver letto la dichiarazione di intenti vorranno poi vedere più dettagli, forse qualche documentazione utente o sviluppatore e eventualmente vorranno scaricare qualcosa. Ma prima di ognuna di queste cose essi vorranno essere sicuri che è open source.

La pagina principale deve rendere inequivocabilmente chiaro che quel progetto è open source. Ciò può sembrare ovvio, ma sareste sorpresi dal fatto di quanti progetti dimenticano di farlo. Ho visto tanti siti di progetti di software libero dove la pagina principale non solo non diceva sotto quale licenza particolare il software era distribuito, ma nemmeno specificava chiaramente che il software era libero. A volte il dato fondamentale informativo era relegato nella pagina dei downloads, o nella pagina degli sviluppatori, o in qualche altro posto che richiedeva un ulteriore clic del mouse per arrivarvi. In casi estremi la licenza non era inserita affatto nel sito web e l'unico modo per vederla era quello di scaricare il software e di guardarvi dentro.

Non fate questo errore. Tale omissione può far perdere molti potenziali sviluppatori e utilizzatori. Specificate in modo aperto, giusto sotto la dichiarazione di intenti che il progetto e “software libero” e “open source” e fornite la licenza esatta. Una guida rapida alla scelta della licenza è data in sezione chiamata «Scegliere una Licenza e Applicarla» più in là in questo capitolo , e le questioni sulle licenze sono discusse in dettaglio in Capitolo 9, Licenze, Diritti d'Autore e Brevetti.

A questo punto i nostri ipotetici visitatori hanno deciso—probabilmente in un minuto o meno—che sono interessati a spendere, per esempio, almeno cinque ulteriori minuti nell' esaminare questo progetto. Le prossime sezioni descrivono ciò che essi potrebbero incontrare in quei cinque minuti.

Ci potrebbe essere una lista delle funzionalità del software (se qualcosa non è ancora completa potete ugualmente metterla in lista ma mettete "pianificato" o "in corso" vicino ad essa), e il tipo di ambiente di elaborazione richiesto dal software. Pensate alla lista di funzionalità/requisiti come a qualcosa che dareste a uno che chiedesse un sommario veloce del software. E' spesso giusto una logica espansione della dichiarazione di intenti. Per esempio la dichiarazione di intenti potrebbe dire:

L'elenco delle caratteristiche e dei requisiti darebbe i dettagli, chiarendo la portata della dichiarazione di intenti :

Con queste informazioni i lettori possono velocemente farsi un'idea di quanto questo software abbia speranza di funzionare per loro e possono pensare di farsi coinvolgere anche come sviluppatori.

La gente vuole sempre sapere quanto il progetto sta facendo. Per i nuovi progetti, essi vogliono sapere il ritardo fra le promesse del progetto e la corrente realtà. Per i progetti maturi vogliono sapere quanto è attiva è la sua manutenzione, quanto spesso escono le nuove releases, come probabilmente si reagisce ai rapporti dei bugs, ecc..

Per rispondere a queste domande dovreste metter su una pagina dello stato dello sviluppo con l'elenco degli obiettivi a breve termine del progetto e delle sue necessità (per esempio, si potrebbe essere alla ricerca di sviluppatori con una particolare esperienza). La pagina può anche fornire una storia della passate releases, con gli elenchi delle caratteristiche, cosicchè i visitatori possano farsi un'idea di come il progetto definisce l'“avanzamento” e di quanto velocemente avanza in accordo con tale definizione.

Non vi spaventate se vi vedete impreparati, e non siate tentati di esagerare sullo stato di sviluppo. Chiunque sa che il software si evolve per stadi; non c'è da vergognarsi a dire “Questo è il software alfa con bugs noti. Esso gira, e funziona almeno per qualche tempo, ma lo usate a vostro rischio” Un tale linguaggio non farà fuggire per lo spavento il tipo di sviluppatori di cui voi avete bisogno in quello stadio. Per quanto riguarda gli utilizzatori, una delle peggiori cose che un progetto può fare è attrarre utilizzatori prima che sia finito. Una reputazione per l'instabilità o per gli errori è difficile da scrollarsela di dosso, una volta che se la si è fatta. La prudenza paga a lungo andare. E' sempre meglio che il software sia più stabile di quanto gli utilizzatori si aspettino che meno stabile, e le sorprese piacevoli producono il più bel tipo di voci.

Il software dovrebbe essere scaricabile come codice sorgente in formato standard. Quando il progetto sta inizialmente prendendo avvio il pacchetto binario (eseguibile) non è necessario, amenochè il software abbia i requisiti di costruzione o aspetti annessi talmente complicati che il semplice prelevarlo per farlo girare sarebbe un gran lavoro per molta gente. (Ma in questo caso il progetto è in un brutto periodo per attrarre sviluppatori comunque!)

Il meccanismo di distribuzione dovrebbe essere agevole, standardizzato e il meno astratto possibile. Se steste cercando di sradicare un male, non distribuireste la medicina in modo tale che essa richieda una grandezza della siringa non standard per somministrarla. Allo stesso modo il software doverebbe conformarsi a metodi standard di costruzione e di installazione; più esso devia dagli standards più i potenziali utilizzatori e sviluppatori abbandoneranno e andranno via confusi.

Il che suona ovvio, ma molti progetti non si infastidiscono a standardizzare le loro procedure di installazione prima che sia molto tardi nel gioco, dicendo che possono farlo in qualsiasi momento: "Sistemeremo tutte quelle cose quando il codice sarà più vicino ad essere pronto." Ciò di cui non si rendono conto è che rimandando il lavoro noioso di portare a termine le procedure di costruzione e di installazione, in realtà stanno facendo in modo che il codice tardi ulteriormente ad essere pronto—perchè scoraggiano gli sviluppatori che altrimenti avrebbero contribuito al codice. Molto insidiosamente, essi non sanno che stanno perdendo tutti quegli sviluppatori, perchè il processo è accumulazione di non eventi: qualcuno visita il sito, scarica il software, cerca di svilupparlo, fallisce, abbandona e va via. Chi mai saprà che ciò è accaduto, al di fuori delle stesse persone? Nessuno di quelli che lavorano al progetto si renderà conto che che l'interesse e la buona volontà di qualcuno è stata dissipata.

Un lavoro noioso con un'alta ricompensa dovrebbe essere fatto all'inizio e abbassando significativamente l'ostacolo di presentare un progetto con una buona confezione porta una ricompensa molto alta.

Quando rilasciate un pacchetto scaricabile è di vitale importanza che voi diate un numero univoco di versione alla release, così la gente può confrontare due release e sapere quale sostituisce l'altra. Una trattazione dettagliata sulla numerazione delle versioni può essere trovata in sezione chiamata «Numerazione delle Releases», e i dettagli sulle procedure di standardizzazione della costruzione e dell'installazione sono contemplate in sezione chiamata «Impacchettamento» , e anche in Capitolo 7, Confezione, Rilascio, e Sviluppo Quotidiano .

Lo scaricamento dei pacchetti sorgente è piacevole per coloro che vogliono giusto installare e usare il programma, ma non è abbastanza per coloro che vogliono correggerne i bug e aggiungere nuove qualità. Istantanee notturne del sorgente possono aiutare, ma non c'è ancora una struttura sufficientemente a grani piccoli per una comunità che sta crescendo. La gente vuole un accesso in tempo reale agli ultimi codici sorgente e il modo per darglielo è usare un sistema di controllo versione. La presenza di versione dei sorgenti anonimamente controllate di è un segno a utilizzatori e sviluppatori—cioè questo progetto sta facendo uno sforzo per dare alla gente quello di cui ha bisogno per partecipare. Se voi non potete dare un controllo di versione subito, allora date un segno che intendete darlo presto. Della infrastruttura del controllo di versione si parla in dettaglio in sezione chiamata «Controllo di versione» in Capitolo 3, L'Infrastruttura Tecnica .

La stessa cosa per il tracciamento bug del progetto. L'importanza di un sistema di tracciamento bug sta non solo nella sua utilità per gli sviluppatori ma in quello che significa per chi osserva il progetto. Per molta gente una database accessibile dei bug è un fortissimo segnale che il progetto dovrebbe essere preso seriamente. Inoltre, più alto è il numero di bugs nel database, più il progetto sembra migliore. Ciò potrebbe sembrare contrario alla logica, ma ricordate che il numero dei bugs registrati in realtà dipende da tre cose: il numero in assoluto presente nel software, il numero di utilizzatori che usano quel software, e la comodità con cui questi utilizzatori possono registrare nuovi bugs. Di questi tre fattori gli ultimi due sono più significativi del primo. Un software di sufficiente complessità e grandezza ha essenzialmente un numero arbitrario di bugs che devono essere scoperti. La vera domanda è, quanto il progetto fa per registrare e elencare in ordine di priorità questi bugs? Un progetto con un grosso e ben mantenuto database dei bugs (i bugs significativi ricevono una risposta prontamente, i bugs duplicati vengono unificati, ecc..) quindi dà una impressione migliore di un progetto senza una database dei bugs o di un database quasi vuoto.

Certo, se il vostro progetto sta giusto partendo, il database dei bugs conterrà assai pochi bugs, e non c'è molto che voi possiate fare su questo. Ma se la pagina dello stato mette in evidenza la giovinezza del progetto e se la gente guardando il database può vedere che molte archiviazioni sono avvenute di recente, può dedurre da ciò che il progetto ha ancora una salutare velocità di archiviazioni, e non sarà ingiustamente allarmata dal basso numero di bugs registrati.

Notare che i tracciatori di bug sono spesso usati per tracciare non solo i bug di software, ma anche richieste di crescita, cambiamenti di documentazione di, operazioni pendenti, e altro. I dettagli di un tracciatore di bugs in funzione sono visibili in sezione chiamata «Tracciamento dei bug» in Capitolo 3, L'Infrastruttura Tecnica , così io non entrerò in essi qui. La cosa importante dal punto di vista di una presentazione è giusto avere un tracciamento dei bugs e assicurarsi del fatto che sia visibile nella pagina principale.

I visitatori di solito vogliono sapere come raggiungere le persone coinvolte nel progetto. Fornite gli indirizzi delle mailing lists, delle chat, dei canali IRC e dei forums dove le altre persone interessate al software possano essere raggiunte. Rendete chiaro che voi e gli altri autori del progetto siete iscritti a queste mailing lists cosicchè la gente possa vedere che c'è un modo per far sapere che raggiungeranno gli sviluppatori. La vostra presenza nelle liste non implica un impegno a rispondere a tutte le domande o a implementare tutte le funzionalità future. Alla fine molti utilizzatori probabilmente non si uniranno mai ai forum comunque, ma saranno confortati dal fatto di sapere che potrebbero unirsi se caso mai ne avessero bisogno.

Nei primi stadi del progetto non c'è bisogno di avere forums separati per utilizzatori e sviluppatori. E' molto meglio che tutti siano spinti a parlare del software fra loro in un'unica “stanza”. Fra i primi arrivati la distinzione fra utilizzatori e sviluppatori è spesso sfocata. Nell'ambito in cui la distinzione può essere fatta il rapporto sviluppatori/utilizzatori è di solito molto più alto nei primi giorni del progetto che non in seguito. Mentre si può supporre che ognuno dei primi che aderiscono sia un programmatore che vuole cimentarsi col software, allo stesso tempo si può supporre che egli sia almeno interessato alle successive discussioni sullo sviluppo e a cogliere il senso degli indirizzi del progetto.

Sebbene questo capitolo parli solo della partenza di un progetto, è solo sufficiente dire che c'è bisogno questi forums di comunicazione esistano. Più in là, in sezione chiamata «Gestire la Crescita» in Capitolo 6, Comunicazione , esamineremo come e dove metter su tali forums i modi in cui essi potrebbero aver bisogno di moderazione o di altra amministrazione e come separare i forums per utilizzatori dai forums per sviluppatori, quando viene il momento, senza creare un abisso insuperabile.

Se qualcuno sta pensando di contribuire al progetto egli cercherà le linee guida per gli sviluppatori. Le linee non sono tanto tecniche quanto sociali: esse spiegano come gli sviluppatori interagiscono fra di loro e con gli utilizzatori e infine come si portano a termine le cose.

Questo argomento è trattato in dettaglio in sezione chiamata «Metter Giù Tutto Per Iscritto» in Capitolo 4, L'Infrastruttura Sociale e Politica , ma gli elemento base delle linee guida sono:

Il termine “dittatura” non è inteso in senso peggiorativo, per inciso. E' un perfetto okay al realizzarsi di una tirannia dove un particolare sviluppatore ha il potere di veto su tutti i cambiamenti. Molti progetti di successo funzionano in questo modo. L'importante è che il progetto venga fuori e si fa per dire così. Una tirannia che pretenda di essere una democrazia disgusterà la gente. Una tirannia che dice di essere una tirannia andrà bene finchè il tiranno è competente e fidato.

Vedere http://subversion.apache.org/docs/community-guide/ per un esempio completo di linee guida, o http://www.openoffice.org/dev_docs/guidelines.html per linee guida che mettono a fuoco più l'amministrazione e lo spirito di partecipazione e meno le questioni tecniche.

Il problema separato di fornire al programmatore una introduzione al software è trattato in sezione chiamata «La documentazione sviluppatore» più in là in questo capitolo .

La documentazione è fondamentale. Bisogna che la gente abbia qualcosa da leggere, anche se questo qualcosa è rudimentale è incompleto. Ciò cade in pieno nella categoria “sgobbata” cui si è fatto riferimento prima ed è spesso la prima zona dove un nuovo progetto open source fallisce. Venir fuori con una dichiarazione di intenti, e con un elenco delle caratteristiche, scegliere una licenza, fare il punto sullo stato dello sviluppo—questi sono compiti relativamente piccoli che possono essere completati definitivamente e in genere non c'è bisogno di ritornarci su. La documentazione, invece, non è mai realmente finita, il che può essere un motivo per cui la gente a volte tarda proprio a iniziarla.

La cosa più insidiosa è che l'utilità della documentazione per quelli che la scrivono è inversamente proporzionale a quella di coloro che la leggeranno. La più importante documentazione per gli utilizzatori iniziali sono le basi: come installare velocemente il software, una panoramica su come funziona, magari qualche guida per eseguire alcune operazioni. Queste sono esattamente le cose che coloro che scrivono la documentazione conoscono troppo bene— così bene che può essere difficile per loro vedere le cose dal punto di vista del lettore e parlare con impegno dei passi che (a coloro che la scrivono) sembrano ovvi e non meritevoli di menzione.

Non esiste una soluzione magica a questo problema. Qualcuno giusto ha bisogno di sedersi e scrivere la materia, e poi farla funzionare da parte degli utilizzatori tipici per verificare la sua qualità. Usate un formato facile per le modifiche come l'html, il testo semplice, il Textinfo o qualche variante dell'XML—qualcosa che sia adatto per facilità, veloci miglioramenti a botta calda. Questo solo per rimuovere una qualsiasi cosa all'inizio che potrebbe impedire a coloro che originariamente hanno scritto la documentazione di apportare successivi miglioramenti, ma anche a coloro che si aggregano dopo al progetto e che vogliono lavorare alla documentazione.

Una maniera per assicurarsi che una documentazione di base iniziale sia portata a termine è limitare la sua portata in precedenza. In quel modo lo scriverla almeno non sembrerà come un compito indeterminato. Una buona regola pratica è quella che soddisferà i seguenti criteri:

L'ultimo punto è di grande importanza, davvero, è può essere applicato all'intero progetto, non esattamente alla documentazione. Un accurato rendere conto delle manchevolezze note è la norma nel mondo dell'open source. Non dovete amplificare le manchevolezze del progetto, giusto identificatele scrupolosamente e spassionatamente quando il contesto lo richiede (nella documentazione, nel database del tracciamento dei bugs, o nelle discussioni nelle mailing lists). Nessuno prenderà ciò per disfattismo sulla parte di progetto, nè come un ordine di risolvere i problemi entro una determinata data, a meno che il progetto dia questo ordine esplicitamente. Siccome chiunque usa il software scoprirà le manchevolezze da sé, è molto meglio che sia psicologicamente preparato—allora sembrerà come se il progetto abbia una solida consapevolezza di come sta andando.

Se il progetto comporta una interfaccia utente grafica, o se produce uscite grafiche o diversamente risultati particolari, mettetene qualche esempio sul sito. Nel caso dell'interfaccia, ciò significa screenshoots; nel caso di un risultato potrebbero essere screenshoots oppure veri e propri files. Ambedue le soluzioni fornirebbero alla gente una gratificazione istantanea: un singolo screenshoot può essere più convincente che paragrafi di testo descrittivo e di chiacchiere in mailing lists, perchè uno screenshot è una prova inconfutabile che il software funzionaPuò essere pazzo, può essere difficile da montare, può essere documentato in modo incompleto, ma questo screenshot è tuttavia una prova che se uno ci mette impegno, può ottenere che il software funzioni.

Ci sono pochi siti che offrono un hosting gratis e una infrastruttura per i progetti open source: un'area web, il controllo di versione, un tracciatore di bugs, un'area di download, un foro di dibattito, backups regolari, ecc. I dettagli variano da sito a sito, ma vengono forniti gli stessi servizi base da tutti questi. Se usate uno di questi siti, avete molto gratis; ciò che cedete, ovviamente, è un controllo raffinato sull'esperienza degli utilizzatori. Il sevizio di hosting decide il software che gira sul sito, è può controllare o almeno influenzare l'aspetto e la percezione delle pagine web.

Vedere sezione chiamata «Canned Hosting» in Capitolo 3, L'Infrastruttura Tecnica per una più dettagliata discussione e per i vantaggi e svantaggi degli hosting in scatola e per un elenco di siti che lo offrono.

Se vi fa comodo che il vostro progetto possa essere potenzialmente usato in programmi proprietari allora usate una licenza MIT/X-style. E' la più semplice delle licenze minimali che fanno poco più che affermare un diritto di copyright (senza nei fatti limitare la copia) e specifica che il codice arriva senza garanzia. Vedere sezione chiamata «La licenza MIT / X Window System » per i dettagli.

Se non volete che il vostro codice sia usato in software proprietari usate la GNU General Public License (http://www.gnu.org/licenses/gpl.html). La GPL è probabilmente la più largamente apprezzata licenza nel modo oggi. Questo è già in se stesso un grosso vantaggio, perchè molti utilizzatori e collaboratori saranno già familiari con essa e quindi non avranno a spendere un tempo extra per comprendere la vostra licenza. Vedere sezione chiamata «La GNU General Public License» in Capitolo 9, Licenze, Diritti d'Autore e Brevetti per i dettagli.

Dopo aver scelto una licenza dovreste dichiararla nel pagina principale del progetto. Non c'è bisogno che includiate il vero testo della licenza lì; date solo il nome della licenza e create un link che porti al testo intero della licenza in un'altra pagina.

Questo dice al pubblico sotto quale licenza volete che il software sia rilasciato, ma non è sufficiente ai fini legali. Per questo il software stesso deve contenere la licenza. Il classico modo di fare ciò è quello di mettere la intera licenza in un file chiamato COPYING (o LICENSE), e poi mettere una piccola nota in testa ad ogni file sorgente indicante la data del copyright, il proprietario, e la licenza e indicante dove trovare il testo intero della licenza.

Ci sono molte varianti a questo percorso, sicchè voi vedrete giusto un esempio qui. La GNU GPL dice di mettere una nota come questa in testa ad ogni file sorgente:

Copyright (C) <anno>  <nome dell'autore>
Il programma è un software libero; potete redistribuirlo e/o secondo i termini della come pubblicato 
dalla Free Software Foundation; sia la versione 2, 
sia (a vostra scelta) ogni versione successiva.

Questo programma è distribuito nella speranza che sia utile 
ma SENZA ALCUNA GARANZIA; senza anche l'implicita garanzia di 
POTER ESSERE VENDUTO o di IDONEITA' A UN PROPOSITO PARTICOLARE. 
Vedere la GNU General Public License per ulteriori dettagli.

Dovreste aver ricevuto una copia della GNU General Public License
in questo programma; se non l'avete ricevuta, scrivete alla Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
      

Non si dice specificatamente che la copia della licenza che avete ricevuto col programma è nel file COPYING ma che è messa usualmente lì. (Potete cambiare la nota precedente per stabilire ciò completamente.) Questo modello dà anche un indirizzo geografico dal quale richiedere una copia della licenza Un altro sistema comune è quello di dare il link alla pagina in cui si trova la licenza. Usate il vostro giudizio e puntate dove voi credete sia aggiornata la copia più stabile della licenza. Che potrebbe essere semplicemente da qualche parte del sito del progetto. In generale la nota che mettete in ogni file sorgente non deve apparire esattamente come quella di sopra, a condizione che inizi con la nota del detentore del copyright e della data, stabilisca il nome della licenza, e chiarisca dove poter vedere l'intera licenza.

Anche dopo che avrete reso pubblico il progetto voi e gli altri fondatori vi troverete spesso desiderosi di sistemare difficili questioni con comunicazioni private in un ambiente più ristretto. Ciò è specialmente vero nei primi giorni del progetto quando ci sono tante decisioni da prendere, e, usualmente, pochi volontari qualificati per prenderle. Tutti gli ovvi svantaggi delle discussioni in liste pubbliche appariranno palpabili davanti a voi. Il ritardo connesso con le conversazioni per email, il bisogno di avere sufficiente tempo perchè si formi il consenso, il fastidio della negoziazione con volontari sprovveduti che ritengono di capire tutti i problemi, ma in realtà non lo fanno (ogni progetto li ha; a volte essi sono collaboratori protagonisti dell'anno prossimo, a volte restano sprovveduti per sempre), le persone che non riescono a capire che voi volete solo risolvere il problema X anche se questo è ovviamente un aspetto del problema più generale. E così via. La tentazione di prendere decisioni a porte chiuse e di presentarle a loro come a fatti compiuti, o almeno come i fermi consigli di un blocco votante unito e influente, sarà grande indubbiamente.

Non fatelo.

Per quanto lente e scomode possano essere le discussioni pubbliche, esse sono quasi sempre preferibili a lungo andare. Rendere private importanti discussioni è come dipingere il collaboratore come repellente per il vostro progetto. Nessun serio volontario resterebbe a lungo nei paraggi di un ambiente in cui tutte le grosse decisioni vengono prese in un consiglio segreto. Inoltre le discussioni pubbliche hanno il benefico effetto secondario che sopravviveranno per quanto effimera fosse la la questione tecnica in discussione:

Infine, c'è la possibilità che qualcuno nella lista possa dare un reale contributo alla conversazione col far sorgere un'idea che voi non vi sareste mai aspettati. E' difficile dire quanto questo sia possibile. Dipende dalla difficoltà del codice e dal grado specializzazione richiesta. Ma se è permessa una evidenza annedotica, io azzarderei che questo è più probabile di quanto uno si aspetterebbe intuitivamente. Nel progetto di Subversion, noi (i fondatori) eravamo di fronte a una profonda e complessa serie di problemi ai quali stavamo pensando con difficoltà per molti mesi e francamente dubitavamo che ognuno sulla mailing list da poco creata potesse dare un contributo effettivo alla discussione. Così prendemmo pigramente la via e incominciammo a battere su idee tecniche avanti e indietro in emails private finchè uno che osservava il progetto^[10] ebbe il sentore di quello che stava avvenendo e chiese che la discussione fosse spostata su una mailing list pubblica. Roteando un poco gli occhi, lo facemmo e fummo stupiti dai commenti perspicaci e dai suggerimenti che presto ne vennero. In molti casi le persone fornirono idee che non ci erano mai venute in mente. Ciò dimostrò che c'erano persone molto acute nella mailing list. Esse stavano solo aspettando si essere correttamente allettate. E' vero che le discussioni che ne vennero fuori furono più lunghe di quanto lo sarebbero state se la conversazione fosse stata tenuta privata, ma esse furono talmente molto più costruttive che fu un valore il tempo in più.

Senza scendere in generalizzazioni tipo “il gruppo è sempre più acuto dell'individuo” agitando le mani (noi tutti abbiamo incontrato abbastanza i gruppi per saperlo piuttosto bene), deve darsi per acquisito che ci sono certe attività in cui il gruppo eccelle. La valutazione professionale del lavoro dei colleghi è una di queste; la produzione veloce di un gran numero di idee è un'altra. La qualità delle idee dipende dalla quantità del pensare che è entrato in esse, certo, ma voi non saprete che genere di pensatori è sbocciato lì finchè non li stimolerete con un problema impegnativo.

Naturalmente ci sono discussioni che devono avvenire in privato. In questo libro ne vedrete esempi. Ma la guida dovrebbe essere sempre: Se non c'è ragione perchè esse siano essere private, dovrebbero essere pubbliche.

Far si che questo accada richiede un'azione. Non c'è solo da assicurarsi che i vostri posts vadano nella lista pubblica. Dovete anche richiamare l'attenzione della altre persone sul fatto che inutili conversazione private vadano anche sulla lista. Se qualcuno tenta di avviare una conversazione privata, e non c'è ragione perchè essa sia privata, allora il vostro compito è quello di aprire immediatamente la relativa discussione pubblica appropriata. E anche non commentate sull'argomento originale finchè o avete condotto la conversazione in un alveo pubblico, o avete accertato che la privacy era necessaria. Se fate ciò con coerenza, le persone afferreranno abbastanza velocemente e incominceranno ad usare i forums per abitudine.

Stroncate sul nascere la scortesia. Dall'inizio dell'esistenza del vostro progetto dovreste mantenere una politica di tolleranza-zero verso comportamenti scortesi o offensivi nei suoi forums. Tolleranza-zero non significa forzatura tecnica di per se. Non dovete rimuovere le persone dalla mailing list quando offendono un altro iscritto o impedire loro la possibilità di inserire messaggi perchè hanno fatto commenti sprezzanti. (In teoria potreste alla fine far ricorso a tale azione, ma solo dopo che le altre vie hanno fallito—cosa che, per definizione non è il caso dell'avvio del progetto.) Tolleranza-zero semplicemente significa non permettere che cattivi comportamenti passino inosservati. Per esempio quando qualcuno posta un commento tecnico insieme ad un attacco personale a qualche altro sviluppatore nel progetto, è imperativo che voi rispondiate a questo attacco personale prima, come problema separato in se stesso, e solo dopo passiate al contenuto tecnico.

Sfortunatamente è molto facile e troppo tipico, che discussioni costruttive scadano in distruttive guerre offensive. Le persone diranno cose per email che non avrebbero mai detto faccia-a-faccia. L'argomento della discussione però amplifica questo effetto: nei problemi tecnici, le persone spesso pensano che ci sia una sola risposta giusta a molte domande, e che il disaccordo con quella risposta possa essere spiegato come ignoranza o stupidità. Il tratto è breve fra il chiamare la proposta di qualcuno stupida e il chiamare la persona stessa stupida. Infatti, spesso è difficile dire dove si lascia il dibattito e incomincia l'attacco al carattere, che è una ragione per cui reazioni drastiche o punizioni non sono una buona idea. Invece, quando pensate di vedere che questo sta succedendo inserite un post che metta l'accento sull'importanza di mantenere la discussione amichevole, senza accusare nessuno di essere deliberatamente velenoso. Tali posts di ”Politica Simpatica” hanno una sfortunata tendenza a suonare come una ramanzina a una classe di bambini sul buon comportamento:

Per quanto artificiose suonino queste reazioni, esse hanno un notevole effetto. Se voi costantemente gridate i cattivi comportamenti, ma non chiedete le scuse o una ammissione da parte di chi offende, allora voi lasciate le persone libere di raffreddarsi e di mostrare il lato migliore col comportarsi meglio la volta successiva—ed essi lo faranno. Uno dei segreti per fare ciò con successo è non trasformare la pseudo discussione nell'argomento principale. Ci dovrebbe essere sempre una breve prefazione a parte, alla parte principale della vostra risposta. Fate notare, incidentalmente, che “non facciamo le cose in questo modo qui da noi”, ma poi andate al reale contenuto in modo tale da dare alle persone qualcosa in argomento su cui rispondere. Se qualcuno obbietta che non merita il vostro rimprovero, rifiutatevi semplicemente di essere condotti sull'argomento. O non rispondete (se pensate che essi si stiano giusto sfogando e non richiedono una risposta), oppure dite che vi dispiace se avete reagito in modo esagerato e che è difficile distinguere le sfumature per email, quindi ritornate all'argomento principale. Mai, mai insistere su una ammissione, pubblica o privata, da parte di qualcuno che si è comportato in modo scorretto. Se essi da sé scelgono di postare delle scuse, ciò è una gran cosa, ma pretendere che lo facciano causerà solo risentimento.

L'obiettivo primario è far si che la buona etichetta sia visto come l'unico comportamento “in-gruppo”. Ciò aiuta il progetto, perchè gli sviluppatori possono essere allontanati (anche da progetti che essi amano e vogliono sostenere) da guerre di offese. Voi potete anche non sapere che essi si sono allontanati; qualcuno potrebbe anche nascondersi nella mailing list, vedere che si fa la pelle dura a partecipare al progetto, e decidere invece di essere coinvolto del tutto. Mantenere il forum confidenziale è una strategia di sopravvivenza, ed è più facile da attuarsi quando il progetto è ancora giovane. Una volta che ciò è parte della cultura, voi non dovrete essere la sola persona a a promuoverlo. Sarà mantenuto da ciascuno.

Uno dei migliori modi di allevare una comunità di sviluppo è il fatto di ottenere che le persone guardino il codice uno dell'altro. E' richiesta una qualche infrastruttura per consentire ciò effettivamente—in particolare, devono essere abilitate email di invio; vedere sezione chiamata «Email di commit» per maggiori dettagli. L'effetto delle email di invio è che ogni volta che uno invia un cambiamento al codice sorgente viene emessa una email che mostra una messaggio di log e le differenze per il cambiamento (vedere diff, in sezione chiamata «Vocabolario del controllo di versione»). La revisione del codice è la pratica di revisionare le emails di invio così come arrivano, cercando per bugs e possibili miglioramenti.^[11]

La revisione del codice serve a diversi scopi simultaneamente. E' il più chiaro esempio di revisione condivisa nel mondo dell'open source, e favorisce direttamente il mantenimento della qualità del software. Ogni bug che si imbarca in un pezzo di software è preso lì per essere stato inviato e non individuato; quindi più sono gli occhi e meno bugs si imbarcheranno. Ma la revisione del codice serve anche ad uno scopo indiretto: esso conferma alle persone che ciò che essi fanno è importante, perchè uno non impiegherebbe il tempo a revisionare un invio amenochè non gli interessasse il suo effetto. Le persone fanno il loro migliore lavoro quando sanno che gli altri impiegheranno del tempo per analizzarlo.

Le revisioni dovrebbero essere pubbliche. Anche in occasioni in cui sono stato a sedere in una stanza fisica con sviluppatori, e uno di noi aveva fatto un invio, facevamo attenzione a non fare la revisione verbalmente nella stanza, ma invece la mandavamo alla mailing list dello sviluppo. Le persone seguono i commenti trovano difetti in essi, ed anche se non li trovano, ciò ricorda loro che la revisione è una attività prevista, regolare, come lavare i piatti, o tosare il prato.

Nel progetto di Subversion noi all'inizio non avevamo la buona pratica della revisione del codice. Non c'era la garanzia che ogni invio sarebbe stato revisionato sebbene uno potesse dare un'occhiata a un cambiamento se era interessato a una particolare area di codice. I bugs in essa potevano e dovevano essere trovati. Uno sviluppatore chiamato Greg Stein che conosceva il valore della revisione del codice per passati lavori decise di andare a fare un esempio revisionando ogni linea di ogni singolo invio che andava nel deposito degli invii. Ogni invio che ognuno faceva veniva immediatamente seguito da un'email alla lista degli sviluppatori da Greg, che parlava dell'invio, analizzava i possibili problemi, e occasionalmente esprimeva lode su un pezzo intelligente di codice. Subito, egli trovava bugs o pratiche non ottimali di scrivere il codice che diversamente sarebbero passate inosservate. Apparentemente egli non si lamentava di essere l'unica persona che revisionava ogni invio, anche se impiegò una gran parte del suo tempo, ma cantò le lodi delle revisione del codice ogni volta che ne ebbe l'occasione. Molto presto, altre persone, me incluso, incominciarono a revisionare gli invii con regolarità. Quale era la nostra motivazione? Non era che Greg consapevolmente ci avesse rimproverati per farlo. Ma egli aveva provato che la revisione del codice era un modo prezioso di spendere il tempo, e che uno avrebbe contribuito tanto al progetto sia revisionando i cambiamenti degli altri, sia scrivendo nuovo codice. Dopo che egli dimostrò ciò, questo diventò il comportamento scontato, al punto che ogni invio che non riceveva una reazione faceva preoccupare chi lo aveva effettuato, e lo induceva anche a chiedere alla lista se qualcuno tuttavia avesse avuto l'occasione di revisionarlo. Più tardi Greg prese un lavoro che non gli lasciò tanto tempo per Subversion, e dovette finire di fare revisioni con regolarità. Ma, da allora, l'abito si radicò a tal punto per il resto di noi che sembrò che continuasse da tempo immemorabile.

Incominciate a fare revisioni sin dal primo invio. Il tipo di problemi più facili da incontrare nella revisione delle differenze sono le vulnerabilità nella sicurezza, falle nella memoria, i commenti insufficienti o l'insufficiente documentazione, gli errori logici in una iterazione, la discordanza di disciplina chiamante/chiamato, e altri problemi che richiedono un minimo di contesto intorno da vedere. Comunque anche problemi su larga scala come i fallimenti nell'estrarre procedure ripetute in una locazione diventano osservabili dopo che una ha fatto la revisione regolarmente, perchè la memoria di passate differenze avverte sulle differenze presenti.

Non vi spaventate se non trovate niente da commentare, o se non conoscete ogni area di codice. Usualmente ci sarà qualcosa da dire su quasi ognuno degli invii; anche dove non trovate niente da chiedere, potete trovare qualcosa da apprezzare. L'importante è che sia chiaro a ogni persona che fa un invio che ogni cosa che fa è visto e capito. Certo, la revisione del codice non libera i programmatori dalla responsabilità di rivedere il proprio codice prima di inviarlo. Nessuno dovrebbe dipendere dalla revisione del codice per individuare cose che dovrebbe individuare da sé.

Se state aprendo un progetto esistente, un progetto che ha già sviluppatori attivi abituati a lavorare in un ambiente closed-source, assicuratevi che ognuno capisca che sta venendo un grosso cambiamento, e assicuratevi di capire come ciò sta venendo percepito dal loro punto di vista.

Cercate di capire come la situazione appare loro: in passato, tutte le decisioni riguardanti il codice e la progettazione venivano prese in un gruppo di programmatori che conoscevano il software più o meno bene in modo uguale, in cui tutti ricevevano le stesse pressioni dalla stessa organizzazione, e in cui tutti conoscevano la forza e le debolezze degli altri. Adesso voi state chiedendo loro di esporre il loro codice allo sguardo indagatore di casuali estranei, che si formeranno un giudizio solo sul codice, con nessuna consapevolezza di quante pressioni mercantili possono aver forzato certe decisioni. Questi estranei faranno un sacco di domande, domande che turberanno gli sviluppatori preesistenti fino al punto che essi si renderanno conto che la documentazione sulla quale hanno sgobbato è tuttavia inadeguata (questo è inevitabile). E per giunta, i nuovi arrivati sono sconosciuti, entità anonime. Se uno dei vostri sviluppatori non si sente sicuro riguardo alle sue capacità, immaginate come questa cosa si inasprirà quando i nuovi arrivati faranno notare gli errori nel codice che ha scritto, e peggio, lo faranno davanti ai suoi colleghi. Amenoché voi non abbiate un team di perfetti svilippatori, questo è inevitabile—infatti ciò accadrà probabilmente a tutti loro all'inizio. Ciò non avviene perchè essi siano dei cattivi programmatori; avviene giusto che ogni programma al di sopra di una certa grandezza ha bugs, ed ogni revisione alla pari evidenzierà alcuni di questi bugs (vedere sezione chiamata «Praticare una Visibile Revisione del Codice» prima in questo capitolo ). Allo stesso tempo, il nuovo arrivato stesso non sarà soggetto a molte revisioni alla pari all'inizio, perchè non può contribuire al codice finchè non familiarizza col progetto. Ai vostri sviluppatori potrà sembrare che tutto il criticismo sta arrivando e non andando via. Così c'è il pericolo che una mentalità di assedio assuma il controllo fra i vecchi sviluppatori.

Il miglior modo per prevenire ciò è mettere in guardia ciascuno su ciò che sta venendo, spiegarlo, dire loro che lo sconforto iniziale è perfettamente normale, e rassicurarli che sta per andare meglio. Alcuni di questi preavvisi dovrebbe aver luogo in privato, prima che il progetto venga aperto. Ma potete anche trovare utile ricordare alle persone sulle liste pubbliche che questo è un nuovo modo di sviluppare nel progetto, e che ci vorrà un pò di tempo per adattarsi. La miglior cosa che voi possiate fare è guidare con l'esempio. Se vedete che i vostri sviluppatori non rispondono a sufficienza alle domande dei novizi, allora il dire loro di rispondere meglio, non è utile. Può darsi che essi non abbiano ancora una buona idea di ciò che garantisce una reazione e di ciò che non lo fa, o potrebbe darsi che essi non abbiano idea di quanto privilegiare il codice nei confronti del nuovo carico della comunicazione esterna. Il miglior modo di farli partecipare è partecipare voi stessi. Essere sulle mailing lists e accertarsi di rispondere ad alcune domande lì. Quando non avete l'esperienza per rispondere abilmente a una domanda, allora passate in maniera visibile la palla a uno sviluppatore che lo faccia, e assicuratevi che egli dia una risposta, o almeno che abbia una reazione. Ci sarà naturalmente la tentazione per lungo tempo di abbandonarsi a discussioni private, poiché quello era ciò a cui erano abituati. Assicuratevi di essere iscritti alle mailing lists interne in cui ciò può avvenire, dimodochè possiate chiedere che tali discussioni siano spostate sulle liste pubbliche immediatamente.

Ci sono altre attività a lungo termine relative all'apertura di un progetto precedentemente chiuso. Capitolo 4, L'Infrastruttura Sociale e Politica esamina tecniche per mettere insieme con successo sviluppatori pagati e non pagati, Capitolo 9, Licenze, Diritti d'Autore e Brevetti e tratta della necessità di una osservanza del termini legali quando si apre un codice base privato che può essere stato scritto o “posseduto” da altre parti.

Tra quando questa frase è stata scritta e quando è stata pubblicata, il problema dello spam, grande quanto la Rete, sarà probabilmente raddoppiato nella sua gravità— o almeno sembrerà così. C'era una volta, non così tanto tempo fa, un tempo in cui uno poteva gestire una mailing list senza adottare assolutamente nessuna prevenzione per lo spam. Gli occasionali messaggi non pertinenti sarebbero comunque comparsi, ma abbastanza infrequentemente ed essere solo una piccola noia. Quell'era è andata per sempre. Oggi, una mailing list che non adotta misure di prevenzione dello spam sarà velocemente sommersa di email spazzatura, fino al punto di diventare inservibile. La prevenzione dello spam è imperativa.

Dividiamo la prevenzione dello spam in due categorie: prevenire il comparire di messaggi di spam sulla mailing list e prevenire che la vostra mailing list diventi una fonte di nuovi indirizzi email per gli spammer. La prima è più importante, quindi la esaminiamo per prima.

Gli iscritti spesso vogliono mettere le mail della mailing list in una cartella specifica per il progetto, separata dalle altre mail. Il loro software per la lettura di email può fare ciò automaticamente esaminando gli header delle email. Gli header sono i campi in cima della mail che indicano mittente, destinatario, oggetto, data, e varie altre cose riguardo al messaggio. Alcuni header sono noti e anche obbligatori:

From: ...
To: ...
Subject: ...
Date: ...

Altri sono opzionali, anche se abbastanza standard. Per esempio, alle email non è strettamente richiesto di avere il seguente header

Reply-to: sender@email.address.here

ma molti ce l'hanno, perchè dà ai destinatari un modo per raggiungere l'autore assolutamente sicuro (è specialmente utile quando l'autore ha dovuto inviare da un indirizzo diverso da quello a cui le risposte andrebbero inviate).

Alcuni software per la lettura delle email offrono semplici interfacce per riempire le email basandosi sul modello dell'header dell'oggetto della mail. Questo porta la gente a richiedere che la mailing list aggiunga automaticamente un prefisso a tutti gli oggetti delle email, così che loro possano configurare i loro software per cercare tale prefisso e mettere le email nelle giusta cartella in modo automatico. L'idea è che l'autore scriva:

Oggetto: fare la release 2.5.

ma l'email inviata nella mailing list sarà del tipo:

Oggetto: [discuss@lists.example.org] fare la release 2.5.

Anche se la maggior parte dei software di gestione offre l'opzione di farlo, raccomando fortemente di non abilitare questa opzione. Il problema che risolve può essere facilmente affrontato in altri modi meno intrusivi, e il costo dello spazio sprecato nell'header dell'oggetto è davvero troppo alto. Gli utenti esperti di mailing list scorrono gli oggetti delle email in arrivo per decidere cosa leggere e/o a cosa rispondere. Aggiungere il nome della mailing list all'inizio dell'oggetto delle email può spingere la parte destra dell'oggetto fuori dallo schermo, invisibile. Ciò nasconde l'informazione di cui la gente ha bisogno per decidere quali email aprire, riducendo quindi per tutti la funzionalità complessiva della mailing list.

Invece di usare l'header dell'oggetto, insegnate ai vostri utenti ad usare a loro vantaggio gli altri header standard, a cominciare dall' header del destinatario (To), che dovrebbe dire il nome della mailing list:

To: <discuss@lists.example.org>

Ogni software di lettura mail che può applicare filtri sull'oggetto dovrebbe essere in grado di filtrare altrettanto facilmente l'header del destinatario.

Ci sono alcuni altri header opzionali ma standard che sono previsti nelle mailing list. Applicare filtri su questi è persino più affidabile che usare gli header "To" o "Cc" (Carbon copy, Copia carbone); dato che questi header sono aggiunti dal software di gestione ad ogni nuovo messaggio pubblicato, alcuni utenti potrebbero contare sulla loro presenza:

list-help: <mailto:discuss-help@lists.example.org>
list-unsubscribe: <mailto:discuss-unsubscribe@lists.example.org>
list-post: <mailto:discuss@lists.example.org>
Delivered-To: mailing list discuss@lists.example.org
Mailing-List: contact discuss-help@lists.example.org; run by ezmlm

Per la maggior parte, sono auto-esplicativi. Vedi http://www.nisto.com/listspec/list-manager-intro.html per ulteriori spiegazioni, o se avete bisogno della specifica formale e veramente dettagliata, http://www.faqs.org/rfcs/rfc2369.html.

Va notato che questi header implicano che se avete una mailing list che si chiama "list", allora avete anche gli indirizzi amministrativi "list-help" e "list-unsubscribe" a disposizione. Oltre a questi, è normale avere "list-subscribe", per iscriversi, e "list-owner", per contattare gli amministratori della mailing list. A seconda del software di gestione che usate, questi e/o vari altri indirizzi amministrativi possono essere creati; la documentazione conterrà dettagli su questo. Solitamente una spiegazione completa di tutti questi indirizzi speciali è inviata ad ogni nuovo utente come parte di una email automatica di benvenuto quando si iscrive. Voi stessi probabilmente avrete una copia di questa mail di benvenuto. Se non l'avete, allora chiedetene una copia a qualcun altro, così saprete cosa gli utenti vedono quando si iscrivono alla mailing list. Tenete questa copia a portata di mano così da poter rispondere alle domande riguardo alle funzionalità della mailing list, o ancora meglio mettetela su una pagina web da qualche parte. In questo modo quando la gente perde la loro copia delle istruzioni e scrive per chiedere "Come mi disiscrivo dalla mailing list?", possiate semplicemente passar loro l'URL.

Alcuni software di gestione offrono come opzione l'appendere le istruzioni per la disiscrizione al fondo di ogni messaggio. Se tale opzione è disponibile, usatela. Provoca solo qualche riga in più ad ogni messaggio, in un posto che non dà problemi, e può risparmiarvi molto tempo, riducendo il numero di persone che scrivono—o peggio, scrivono alla mailing list!—chiedendo come disiscriversi.

Prima, in sezione chiamata «Evitare discussioni private», ho sottolineato l'importanza di fare in modo che le discussioni avvengano sui forum pubblici, e ho parlato di come misure sono a volte necessarie per prevenire che le conversazioni finiscano in flussi di email private; inoltre, questo capitolo tratta di come configurare il software di comunicazione del progetto per fargli fare al vostro posto la maggior parte di lavoro possibile. Quindi, se il software di gestione offre un modo di far rimanere in modo automatico le discussioni nella mailing list, potreste pensare che abilitare questa funzionalità sia la scelta più ovvia.

Be', non proprio. Questa funzionalità esiste, ma ha alcuni importanti svantaggi. La domanda riguardante il suo uso o meno è uno dei dibattiti più accesi nella gestione di mailing list—magari non la notizia che compare sui giornali della sera, ma può comparire di tanto in tanto nei progetti di free software. Più avanti, descriverò questa funzionalità, darò le argomentazioni a sostegno di entrambe le fazioni, e darò il miglior consiglio che posso.

La funzionalità in sè è molto semplice: il software di gestione può, se volete, configurare automaticamente l'header Reply-to (Rispondi A) di ogni messaggio in modo da ridirigere le risposte sulla mailing list. Cioè, nonostante cosa il mittente originale ha messo nell'header Reply-to (o anche se non è stato incluso del tutto), al momento in cui gli iscritti vedono il messaggio, l'header conterrà l'indirizzo della mailing list:

Reply-to: discuss@lists.example.org

A prima vista, sembra essere una buona cosa. Dato che virtualmente ogni software di lettura mail presta attenzione all'header Reply-to, quando chiunque risponde ad un messaggio, la risposta sarà automaticamente mandata all'intera mailing list, non solo al mittente del messaggio a cui si è risposto. Sicuramente, chi risponde può ancora cambiare a mano il destinatario, ma la cosa importante è che per default le risposte siano mandate alla mailing list. E' un esempio perfetto dell'uso della tecnologia per incoraggiare la collaborazione.

Sfortunatamente, ci sono alcuni svantaggi. Il primo è noto come il problema del Non Riesco a Trovare la Strada di Casa: a volte il mittente originale potrà mettere il proprio "vero" indirizzo email nel campo Reply-to, perchè per una qualche ragione manda la mail da un indirizzo diverso da quello dove lo riceve. La gente che legge e manda sempre dallo stesso indirizzo non ha questo problema, e potrebbe essere sorpresa della sua esistenza. Ma per chi ha configurazioni email particolari, o chi non può controllare come il suo indirizzo mittente sarà composto (magari perchè scrivono dal lavoro e non hanno influenze sul dipartimento IT), usare il Reply-to potrebbe essere l'unico modo che hanno per assicure che la risposta li raggiunga. Quando una persona di questo genere scrive ad una mailing list a cui non è iscritto, la sua configurazione del Reply-to diventa un'informazione essenziale. Se il software di gestione lo sovrascrive, potrebbe non vedere mai la risposta al suo messaggio.

Il secondo svantaggio ha a che fare con le aspettative, e secondo la mia opinione è l'argomento più potente contro l'occultamento del Reply-to. La maggior parte degli utenti esperti di email sono abituati a due modi basilari di risposta:rispondi a tutti (reply-to-all) e rispondi all'autore (reply-to-author). Tutti i moderni software di lettura mail hanno comandi separati per queste due azioni. Gli utenti sanno che per rispondere a tutti (quindi, includendo la mailing list), devono scegliere reply-to-all, e che per rispondere privatamente all'autore, devono scegliere reply-to-author. Anche se volete incoraggiare le persone a rispondere alla mailing list ogni volta sia possibile, ci sono certe circostanze in cui una risposta privata è prerogativa di chi risponde— per esempio, potrebbero volere dire qualcosa di confidenziale all'autore del messaggio originale, qualcosa che potrebbe essere non appropriato per la mailing list pubblica.

Considerate ora cosa succede quando la mailing list sovrascrive il Reply-to del mittente originale. Chi risponde schiaccia il tasto reply-to-author, aspettandosi di rispondere con un messaggio privato all'autore originale. Dato che questo è il comportamento atteso, potrebbe non preoccuparsi di guardare con attenzione all'indirizzo di destinazione nel nuovo messaggio. Scrive il suo messaggio privato e confidenziale, uno in cui magari dice cose imbarazzanti riguardo a qualcuno della mailing list, e schiaccia il tasto di invio. Inaspettatamente, pochi minuti dopo il suo messaggio appare sulla mailing list!. D'accordo, in teoria dovrebbe avere controllato al campo destinatario, e non dovrebbe aver presunto nulla riguardo all'header Reply-to. Ma gli autori praticamente sempre mettono nel Reply-to il loro indirizzo personale (o meglio il software di posta lo fa per loro), e molti utilizzatori di email di lunga data se lo aspettano. Infatti, quando una persona mette deliberatamente nel Reply-to qualche altro indirizzo, come la mailing list, solitamente lo scrive nel corpo del messaggio, così che la gente non sarà sorpresa per cosa succede quando rispondono.

A causa delle conseguenze anche serie di questo comportamento inaspettato, la mia personale preferenza è la configurazione del software di gestione della mailing list in modo che non tocchi mai l'header Reply-to. Questo è un caso in cui usare la tecnologia per incoraggiare la collaborazione ha, mi sembra, effetti collaterali potenzialmente pericolosi. In ogni caso, ci sono anche alcuni buoni argomenti nell'altra fazione del dibattito. Qualunque modo sceglierete, ogni tanto troverete persone che scrivono sulla mailing list chiedendo perchè non abbiate scelto l'altro modo. Dato che questo non è qualcosa che desiderate avere come argomento principale di discussione, potrebbe essere conveniente avere una risposta pronta preconfezionata, del tipo che sia incline a fermare la discussione piuttosto che incoraggiarla. Cercate di non insistere sul fatto che la vostra decisione, qualunque sia, è ovviamente l'unica giusta e sensata (anche se pensate che sia così). Cercate invece di precisare che è un vecchio dibattito, che ci sono buone argomentazioni a favore di entrambe le fazioni, che nessuna scelta soddisferà tutti gli utenti e quindi avete solo preso la miglior decisione che potevate. Educatamente chiedete che l'argomento non sia ripreso a meno che qualcuno abbia qualcosa di davvero nuovo da dire, quindi stare fuori dalla discussione e sperate che muoia di morte naturale.

Qualcuno potrebbe suggerire una votazione per scegliere un modo piuttosto che un altro. Potete farlo se volete, ma personalmente non penso che votare sia una soluzione soddisfacente in questo caso. La penalità per qualcuno che è sorpreso da questo comportamento è così grande (mandare accidentalmente una email privata ad una mailing list pubblica) e l'inconveniente per gli altri è talmente leggero (doversi ricordare qualche volta di rispondere a tutta la mailing list invece che solo a voi), che non è chiaro perchè la maggioranza, anche se rimane la maggioranza, dovrebbe poter esporre la minoranza a tale rischio.

Non ho trattato tutti gli aspetti del problema qui, solo quelli che sembravano di primaria importanza. Per una discussione completa, vedete questi due documenti 'canonici', che sono quelli che la gente cita sempre quando affrontano questo dibattito:

Nonostante la debole preferenza indicata sopra, non penso che ci sia una risposta "giusta" a questo problema, e participo felicemente a molte mailing list che configurano il Reply-to. La cosa più importante che possiate fare è di implementare un modo o l'altro da subito, cercando di non essere coinvolti in questo dibattito in seguito.

I dettagli tecnici della configurazione della mailing list sono specifici rispetto al software che è in uso, e sono fuori dall'ambito di questo libro. Al momento della scelta o della configurazione dell'archiviatore, considerate queste caratteristiche:

Cosa scritto sopra è solo una lista di punti tecnici per aiutarvi a valutare e configurare un archiviatore. Fare in modo che la gente davvero usi l'archiviatore per il bene del progetto, è discusso nei prossimi capitoli, in particolare sezione chiamata «Uso Ben Visibile degli Archivi».

Qui di seguito ci sono alcuni strumenti open source per gestire mailing list e archiviazione. Se il sito dove è ospitato il vostro progetto ha già una configurazione di default, allora potreste non avere mai bisogno di decidere sull'uso di nessun strumento. Ma se dovete installarne uno da voi, ci sono alcune possibilità. Quelli che ho effettivamente usato sono Mailman, Ezmlm,MHonArc, e Hypermail, ma questo non vuol dire che altri non siano pure buoni (e di sicuro ci saranno altri strumenti là fuori che non ho trovato, quindi non prendete questa come una lista completa).

Software di gestione di mailing list:

Software di archiviazione mailing list:

Questo libro non può insegnarvi come usare il controllo di versione se non l'avete mai usato prima, ma sarebbe impossibile discuterne senza alcune parole chiave. Queste parole sono utili indipendentemente da ogni sistema di controllo di versione: sono i nomi e i verbi di base della collaborazione in rete, e saranno usati in modo generico lungo il resto di questo libro. Anche se non ci fossero sistemi di controllo di versione, il problema della gestione delle modifiche rimarrebbe, e queste parole ci forniscono un linguaggio per parlare concisamente di questo problema.

I due sistemi di controllo di versione più popolari nel mondo del free software sono Concurrent Versions System (CVS, http://www.cvshome.org/) e Subversion (SVN, http://subversion.tigris.org/).

CVS c'è da molto tempo. La maggior parte degli sviluppatori esperti ne hanno già familiarità, fa più o meno cosa di cui avete bisogno, e dal momento che è stato popolare per molto tempo, probabilmente non finirete in nessun lungo dibattito sul fatto che sia la scelta giusta o meno. Comunque, CVS ha alcuni svantaggi. Non fornisce un modo semplice per riferirsi a modifiche che coinvolgono diversi file; non vi permette di rinominare o copiare file sotto il controllo di versione (quindi se avete bisogno di riorganizzare il vostro albero del codice dopo l'inizio del progetto, può essere una vera sofferenza); ha un mediocre supporto al merging (unione); non maneggia molto bene grossi file o file binari; e alcune operazioni sono lente quando un gran numero di file è coinvolto.

Nessuna delle crepe di CVS è fatale ed è tuttora abbastanza popolare. Ad ogni modo, negli ultimi anni il più recente Subversion ha guadagnato terreno, soprattutto nei progetti più nuovi.^[15]. Se state iniziando un nuovo progetto, raccomando Subversion.

Dall'altro lato, dato che sono coinvolto nel progetto Subversion, la mia oggettività può essere giustamente messa in discussione. E negli ultimi anni alcuni nuovi sistemi di controllo open source hanno fatto la loro comparsa. Appendice A, Sistemi di Controllo di Versione Liberi elenca tutti quelli di cui sono a conoscenza, in un ordine approssimativo di popolarità. Come la lista mostra, decidere su un sistema di controllo di versione può facilmente diventare un progetto di ricerca lungo una vita. Magari vi risparmierete la decisione perchè sarà presa per voi dal sito che vi ospita. Ma se dovete scegliere, consultatevi con gli altri sviluppatori, chiedete in giro per vedere con quale la gente ha esperienza, infine prendetene uno e andate avanti con quello. Ogni sistema di controllo di versione stabile e pronto alla produzione andrà bene; non dovete preoccuparvi troppo di fare una scelta totalmente sbagliata. Se proprio non riuscite a farvi un'idea, allora usate Subversion. E' abbastanza facile da imparare e probabilmente rimmarrà standard per almeno un po' di anni.

I consigli di questa sezione non sono indirizzati a particolari versioni di sistemi di controllo di versione, e dovrebbero essere facili da implementare in ognuno di loro. Consultate la documentazione specifica del vostro sistema di versione per i dettagli.

Fate in modo che il bug tracker non diventi un forum di discussione. Anche se è importante mantenere una presenza umana nel bug tracker, non è fondamentalmente fatto per le discussioni in tempo reale. Pensatelo piuttosto come un archiviatore, un modo per organizzare fatti e riferimenti ad altre discussioni, principalmente quelli che avvengono sulle mailing list.

Ci sono due motivi per fare questa distinzione. Primo, il bug tracker è più difficoltoso da usare rispetto alla mailing list ( o rispetto ai forum di chat in tempo reale, per questo ambito). Questo non è solo perchè i bug tracker hanno un cattivo design dell'interfaccia grafica, è solo che le loro interfacce sono state disegnate per catturare e presentare stati discreti, non discussioni in libera espansione. Secondo, non tutti quelli che dovrebbero essere coinvolti nella discussione su un particolare problema sta necessariamente guardando il bug tracker. Parte di una buona gestione del problema (vedi sezione chiamata «Suddividete i Compiti di Management e i Compiti Tecnici» in Capitolo 8, Gestire i Volontari) è fare in modo che ogni problema sia portato all'attenzione delle giuste persone, piuttosto che richiedere ad ogni sviluppatore di controllare tutti i problemi. In sezione chiamata «Nessuna Conversazione nel Tracciatore di Bug» in Capitolo 6, Comunicazione, vedremo i modi per fare in modo che le persone non incappino accidentalmente in discussioni al di fuori degli appropriati forum e nel bug tracker.

Alcuni bug tracker possono controllare le mailing list e fare il log automatico di tutte le email che riguardano un problema noto.Tipicamente lo fanno riconoscendo il numero identificativo del problema nell'oggetto della email, da che è parte di una stringa particolare; gli sviluppatori imparano ad includere queste stringhe nelle loro email per attrarre l'attenzione del bug tracker. Il bug tracker può o salvare la email per intero o (ancora meglio) solo registrare un riferimento alla mail nel normale archivio della mailing list. In entrambi i modi, questa è una funzionalità molto utile; se il vostro tracker ce l'ha, fate in modo sia di attivarla e sia di ricordare alla gente di sfruttarla.

La maggior parte dei database dei problemi alla fine soffre dello stesso problema: un distruttivo carico di problemi duplicati o non validi registrati da ben intenzionati ma inesperti o malinformati utenti. Il primo passo nel combattere questa tendenza è solitamente mettere un messaggio in evidenza sulla pagina iniziale del bug tracker, spiegando come dire se un bug è davvero tale, come fare ricerche per vedere se è già stato registrato, e infine, come effettivamente riportarlo se si è ancora convinti che sia un nuovo bug.

Questo abbasserà il livello del rumore per un po', ma non appena il numero di utenti crescerà, il problema infine ritornerà. Nessun singolo utente può essere incolpato di questo. Ognuno sta solo provando a contribuire alla buona riuscita del progetto, e anche se la sua prima segnalazione di bug non è di grande aiuto, volete comunque ancora incorraggiare il coinvolgimento e la segnalazione di problemi migliori in futuro. Nel frattempo, comunque, il progetto ha bisogno di tenere il database dei problemi il più possibile libero da spazzatura.

Le due cose che faranno il massimo per prevenire questo problema sono: essere certi che ci sia gente a guardare il bug tracker che abbia abbastanza competenze per chiudere i problemi perchè invalidi o duplicati al momento in cui arrivano, e richiedendo (o incoraggiando fortemente) agli utenti di confrontare i loro bug con altra gente prima di aggiungerli al tracker.

La prima tecnica pare essere universalmente impiegata. Anche progetti con database di problemi enormi (per dire, il bug tracker di Debian a http://bugs.debian.org/, che conteneva 315,929 problemi nel momento di questa scrittura) ancora fa in modo che qualcuni veda ogni problema che arriva. Potrebbe essere una persona differente a seconda della categoria del problema. Per esempio, il progetto Debian è una collezione di pacchetti di software, quindi Debian instrada automaticamente ogni problema ai manutentori del pacchetto appropriato. Certo, gli utenti possono a volte identificare male la categoria di un problema, con il risultato che il problema è inizialmente inviato alla persona sbagliata, che deve poi reinstradarla. Comunque, la cosa importante è che tale fardello è ancora condiviso—sia che l'utente sia nel giusto o nel torto quando segnala, il controllo del problema è ancora più o meno equamente distribuito tra gli sviluppatori, così che ogni problema sia in grado di ricevere una pronta risposta.

La seconda tecnica è meno diffusa, probabilmente perchè è più difficile da automatizzare. L'idea fondamentale è che ogni nuovo problema viene "affiancata" nel database. Quando un utente pensa di aver trovato un problema, gli è richiesto di descriverlo su una delle mailing list, o in un canale IRC, e di ottenere una conferma da qualcuno che si tratti davvero di un bug. Coinvolgere subito questo secondo paio di occhi può prevenire molte segnalazioni non genuine. A volte la seconda parte riesce a capire che non si tratta di un bug o che è stato riparato in un rilascio recente. O può essere familiare con i sintomi di un problema precedente, e può prevenire una duplicazione di segnalazioni indicando all'utente il vecchio problema. A volte è sufficiente solo chiedere all'utente "Hai cercato nel bug tracker per vedere se è già stato segnalato?" Molta gente semplicemente non ci pensa, e comunque sono contenti di fare la ricerca una volta che sanno che qualcuno si aspetta che lo facciano.

Il sistema di affiancamento può davvero tenere il database dei problemi pulito, ma ha anche alcuni svantaggi. Molto gente registrerà da sola comunque, o non guardando o infrangendo le istruzioni per trovare un compagno per il nuovo problema. Quindi è comunque necessario per i volontari guardare il database dei problemi. Inoltre, siccome la maggior parte dei nuovi segnalatori non capisce quanto sia difficile il compito di mantenere il database dei problemi, non è giusto rimproverarli troppo duramente per avere ignorato le linee guida. Quindi i volontari devono essere vigili, e comunque praticare influenza su come rimbalzano indietro i problemi non affiancati ai loro segnalatori. Lo scopo è di educare ogni segnalatore ad usare il sistema di affiancamento nel futuro, così che ci sia un insieme sempre in crescita di persone che capiscono il sistema di filtraggio dei problemi. Vedendo un problema non affiancato, i passi ideali sono:

Ricordate che anche se questo sistema migliorerà il rapporto tra segnale e rumore nel database dei problemi nel tempo, non fermerà completamente le segnalazioni non corrette. L'unico modo per prevenirle del tutto è di limitare l'accesso al bug tracker ai soli programmatori—una cura che è quasi sempre peggio della malattia. E' meglio accettare che la pulizia di problemi non validi sarà sempre parte della periodica manutenzione del progetto, cercare di avere il maggior numero possibile di persone che diano una mano.

Vedi anche sezione chiamata «Il Manager di Problemi» in Capitolo 8, Gestire i Volontari.

Molti canali IRC tecnici hanno un membro non umano cosiddetto bot, che è capace di archiviare e rigurgitare informazioni in risposta a specifici comandi. Tipicamente, il bot è interpellato come ogni altro membro del canale, cioè i comandi sono inviati "parlando" al bot. Per esempio:

<kfogel> ayita: learn diff-cmd = http://subversion.tigris.org/faq.html#diff-cmd
<ayita>  Grazie!

Questo dice al bot (che è loggato nel canale come ayita) di ricordare una certa URL come risposta alla domanda "diff-cmd". Ora possiamo interpellare ayita, chiedendogli di dire ad un altro utente di diff-cmd:

<kfogel> ayita: tell jrandom about diff-cmd
<ayita>  jrandom: http://subversion.tigris.org/faq.html#diff-cmd

La stessa cosa può essere fatta usando una conveniente scorciatoia:

<kfogel> !a jrandom diff-cmd
<ayita>  jrandom: http://subversion.tigris.org/faq.html#diff-cmd

L'insieme di comandi e comportamenti può cambiare da bot a bot. L'esempio sopra è con ayita (http://hix.nu/svn-public/alexis/trunk/), di cui un'istanza di solito è presente in #svn su Freenode. Altri bot sono Dancer (http://dancer.sourceforge.net/) e Supybot (http://supybot.com/). Da notare che non c'è bisogno di particolari privilegi sul server per far andare un bot. Un bot è un programma client; tutti possono impostarne uno e metterlo in ascolto su un particolare server o canale.

Se il vostro canale tende ad ospitare domande ripetute molte volte, raccomando vivamente di impostare un bot. Solo una piccola percentuale di utenti del canale avrà la capacità di manipolare il bot, ma questi utenti risponderanno ad una percentuale sproporzionatamente alta di domande, perchè il bot permette loro di rispondere in modo più efficiente.

Anche se è possibile archiviare tutto ciò che succede in un canale IRC, non è necessariamente atteso. Le conversazioni IRC possono essere nominalmente pubbliche, ma molte persone le considerano informali, semi-private. Gli utenti possono essere incuranti della grammatica, e a volte esprimere opinioni (per esempio, su altro software o altri programmatori) che non vorrebbero salvati in un archivio online.

Certo, ci saranno a volte estratti che dovrebbero essere preservati, e va bene. La maggior parte dei client IRC può fare il log di una conversazione su file su richiesta dell'utente, o non potendo, si può sempre fare semplice copia e incolla della conversazione da IRC in un forum più permanente (molto spesso il bug tracker). Ma tenere traccia indiscriminata di tutto può mettere a disagio alcuni utenti. Se archiviate tutto, fate in modo di dirlo chiaramente nell'argomento del canale, e fornite la URL dell'archivio.

Ci sono due grandi vantaggi nell'uso di siti preconfezionati (canned site). Il primo è la capacitò dei server e la larghezza di banda: i loro server sono grosse scatole sedute su tubi davvero capienti. Non importa quanto il vostr progetto diventerà di successo, non farete finire lo spazio su disco nè sovraccaricare la connessione di rete. Il secondo vantaggio è la semplicità. Hanno già scelto un bug tracker, un sistema di controllo di versione, un gestore di mailing list, un archiviatore, e ogni altra cosa di cui avete bisogno per fare andare avanti un sito. Hanno configurato gli strumenti, e si prendono cura dei backup per tutti i dati memorizzati in tali strumenti. Non avete bisogno di prendere alcuna decisione. Tutto quello che dovete fare è riempire un form, schiacciare un bottone e improvvisamente avete un sito web del progetto.

Questi sono vantaggi abbastanza significativi. Gli svantaggi, certo, sono il fatto di dover accettare le loro scelte e configurazioni, anche se qualcosa di diverso sarebbe stato meglio per il vostro progetto. Solitamente i siti preconfezionati sono personalizzabili in certi secondari parametri, ma non avrete mai il controllo dettagliato che avreste se creaste il sito da voi e aveste un pieno controllo amministrativo sul server.

Un perfetto esempio di questo è la gestione dei file generati. Alcune pagine web del progetto potrebbero essere file generati—per esempio, ci sono sistemi per mantenere i dati delle FAQ in un formato facile da modificare, da cui HTML,PDF e altri formati di presentazione possono essere generati. Come spiegato in sezione chiamata «Tenere tutto sotto controllo di versione» prima in questo capitolo, non vorreste mettere sotto controllo di versione i formati generati, solo il file di origine. Ma quando il vostro sito web è ospitato sul server di qualcun altro, potrebbe essere impossibile generare un hook personalizzato per rigenerare la versione HTML onlinea delle FAQ in qualunque momento il file di origine sia modificato. L'unico modo di aggirare questo è di mettere sotto controllo di versione anche i formati generati, così come appaiono sul sito web.

Ci possono anche essere conseguenze più importanti. Potreste non avere abbastanza controllo sulla presentazione quanto vorreste. Alcuni siti di canned hosting vi permettono di personalizzare le vostre pagine web, ma il layout di default del sito solitamente finisce per uscir fuori nei modi peggiori. Per esempio, alcuni progetti che ospitano se stessi su SourceForge hanno completamente personalizzato le pagine principali, ma rimandano ancora gli sviluppatori alle loro pagine SourceForge per maggiori informazioni. La pagina SourceForge è cosa sarebbe la pagina principale del progetto, se questo non avesse usato la pagina personalizzata. La pagina SourceForge ha link al bug tracker, al repository CVS, download eccetera. Sfortunatamente, la pagina ourceForge contiene anche una grande quantità di rumore estraneo. La cima è un banner di pubblicità, spesso un'immagine animata. Il lato sinistro è un insieme verticale di link di scarsa rilevanza per qualcuno interessato al progetto. Il lato destro è spesso un'altra pubblicità. Solo il centro della pagina è dedicato al vero materiale specifico del progetto, e anche questo è organizzato in un modo confusionario che spesso rende i visitatori insicuri su cosa cliccare dopo.

Dietro ogni aspetto del design di SourceForge, c'è senza dubbio una buona ragione—buona dal punto di vista di SourceForge, come le pubblicità. Ma dal punto di vista di un progetto individuale, il risultato può essere una pagina web meno che ideale. Non intendo bacchettare SourceForge; gli stessi problemi si trovano in molti dei siti di canned hosting. Il punto è che c'è un compromesso. Voi guadagnate il sollievo dal fardello tecnico di far andare il sito del progetto, ma solo al prezzo di accettare il modo di farlo di qualcun altro.

Solo voi potete decidere se il canned hosting è la scelta migliore per il vostro progetto. Se scegliete un sito preconfezionato, lasciate aperta l'opzione di trasferirvi su un vostro server più avanti, usando un nome di dominio personale per l'"indirizzo di casa". Potete fare il forward della URL al sito preconfezionato, o avere un home page completamente personalizzata alla URL pubblica e mandare gli utenti al sito preconfezionato per le funzionalità sofisticato. Fate solo in modo di arrangiare le cose in modo che se più avanti decidiate di usare una diversa soluzione di hosting, l'indirizzo del progetto non abbia bisogno di cambiare.

Essere un BD richiede una combinazione di caratteristiche. C'è bisogno, prima di tutto, di una sensibilità ben affilata per quanto riguarda la propria influenza nel progetto, che di volta in volta porta a un auto controllo. Nei primi stadi di una discussione un singolo non esprimerebbe opinioni e conclusioni con così tanta certezza che altri potrebbero percepire come inutile il dissentire. La gente deve esprimere pubblicamente e liberamente le idee, anche sciocche idee. E' inevitabile che il BD anche esprimerà una idea sciocca di volta in volta, certamente, e quindi il ruolo richiede anche una abilità a rendersi conto e a riconoscere quando uno ha preso una cattiva decisione sebbene questo sia un caratteristica che ogni buon sviluppatore dovrebbe avere, specialmente se rimane col progetto per un lungo tempo. Ma la differenza è che i BD può permettersi un lapsus di volta in volta senza preoccuparsi per sua credibilità a lungo termine. Gli sviluppatori con minore anzianità possono non sentirsi così sicuri, così il BD dovrebbe esprimere critiche o decisione contrarie con una certa sensibilità per quanto riguarda il peso che hanno le sue parole, sia tecnicamente che psicologicamente.

Il BD non deve aver bisogno di avere la più evidente esperienza di tutti nel progetto. Egli deve aver sufficiente esperienza sul suo codice, e capire e commentare ogni cambiamento in considerazione, ma questo è tutto. La posizione di BD è né acquisita né mantenuta per virtù di una abilità nello scrivere codice che intimidisce. Quello che è importante è l'esperienza e il senso dell'insieme nella progettazione non necessariamente la capacità di produrre una buona progettazione su richiesta, ma la capacitò di riconoscere la buona progettazione, qualunque sia la sua origine.

E' comune che il dittatore benevolo sia il fondatore del progetto. Ma questa è più una correlazione che una causa. Il tipo di qualità che rende uno capace di avviare un progetto con successo—competenza tecnica, capacità di persuadere altri ad unirsi ad esso, ecc...—sono esattamente le qualità di cui ogni BD avrebbe bisogno. E, certamente, i fondatori incominciano con una sorta di anzianità automatica, che può spesso essere sufficiente a far si che la dittatura benevola appaia il percorso di minor difficoltà per tutti gli interessati.

Ricordate che la possibilità per la forchetta esiste in entrambi i casi. Un BD può fare una diramazione dal progetto appunto facilmente come ciascun altro, e alcuni hanno occasionalmente fatto così, quando hanno visto che la direzione che essi volevano che prendesse il progetto era diversa da quella che gli altri sviluppatori volevano. A causa della possibilità di diramazione, non ha importanza se il dittatore benevolo ha la radice (i privilegi di amministratore del sistema) sui principali servers del progetto. La gente a volte parla del controllo del server come se essa fosse la fonte principale del potere in un progetto, ma nei fatti ciò è irrilevante. Il fatto di aggiungere o rimuovere le password di invio su un particolare server riguarda solo la copia del progetto che è sul server. Un prolungato abuso di questo potere, da parte del BD o di qualche altro, spingerebbe solamente lo sviluppo a spostarsi su un altro server.

Il fatto che il codice sorgente è tenuto sotto il controllo di versione significa che si può tornare indietro dalla maggior parte delle decisioni. Il più comune modo in cui ciò avviene è che ognuno invia un cambiamento pensando erroneamente che ognuno sarebbe contento di esso, solo che si trova di fronte a obiezioni dopo il fatto. E' tipico che tali obiezioni incomincino con un obbligatorio encomio per aver evitato una precedente discussione, anche se questo si può evitare se chi fa l'obiezione non ricorda di una tale discussione negli archivi della mailing list. In un modo o nell'altro, non c'è ragione per la quale il tono della discussione debba essere differente se l'invio del cambiamento è avvenuto prima o dopo. Ogni modifica può essere annullata, almeno fino a quando modifiche dipendenti da essa siano introdotte (cioè la nuova codifica così verrebbe fermata se la modifica originaria fosse subito rimossa). Il sistema del controllo di versione dà al progetto il modo di annullare gli effetti di giudizi cattivi o frettolosi. Questo, a sua volta, libera la gente dall'affidarsi al proprio istinto su quante conferme siano necessarie prima di fare qualcosa.

Ciò significa anche che il processo dello stabilire il consenso non ha bisogno di essere molto formale. La maggior parte dei progetti con esso si comportano a sensazione. Le modifiche minori possono andare avanti confidenzialmente senza discussione, o con un minimo di discussione seguito da pochi cenni di accordo. Per le modifiche più significative, specialmente quelle che possono destabilizzare una gran quantità di codice, le persone dovrebbero aspettare un giorno o due prima di dare per acquisito che c'è il consenso, essendo razionale che nessuno dovrebbe essere marginalizzato in una importante conversazione semplicemente perché non ha controllato la posta abbastanza frequentemente.

Così, quando qualcuno confida di sapere quello che deve essere fatto, dovrebbe procedere e farlo. Questo non si applica solo alla correzione del software, ma all'aggiornamento del sito, alle modifiche della documentazione, e a ogni altra cosa, a meno che la cosa non sia controversa. Usualmente ci saranno solo poche occasioni in cui una azione avrà bisogno di essere annullata, e queste saranno trattate sulla base del caso per caso. Certamente, uno non dovrebbe incoraggiare la gente ad essere testarda. C'è ancora una differenza psicologica fra una decisione sotto discussione e una che ha già avuto effetto, anche se questa è tecnicamente reversibile. La gente pensa sempre che la velocità è alleata dell'azione e sarà leggermente più riluttante ad annullare un cambiamento che a prevenirlo innanzitutto. Se uno sviluppatore abusa di questo fatto inviando modifiche potenzialmente controverse troppo velocemente, comunque, la gente può e dovrebbe protestare e costringere quello sviluppatore a uno standard più stringente finché le cose migliorino.

Inevitabilmente alcuni dibattiti potranno arrivare al consenso. Quando tutte le altre vie per venir fuori da un punto morto falliscono, la soluzione è votare. Ma prima che sia raccolto il voto ci deve essere una chiara serie di scelte sulla scheda. Qui, di nuovo, il normale procedimento della discussione tecniche si unisce in modo benefico col procedimento del progetto di presa della decisioni. Il tipo di questione che vengono al voto spesso comprendono complessi e sfaccettati problemi. In ogni discussione così complessa ci sono usualmente una o due persone che occupano il ruolo di onesti mediatori: che postano sommari periodici dei vari argomenti e che tengono traccia di dove sono i punti di disaccordo (e di accordo). Questi sommari aiutano ciascuno a misurare quanto progresso è stato fatto e quanti problemi rimangono da essere elencati. Questi medesimi sommari possono servire come prototipo di scheda elettorale, dovrebbe diventare necessario un voto. Se gli onesti mediatori hanno fatto bene il loro lavoro, saranno capaci di chiamare con credibilità per il voto quando viene il momento, e il gruppo sarà contento di usare una scheda elettorale basata sui loro sommari di problemi. I mediatori stessi potranno esser partecipi al dibattito; non è necessario che essi rimangano superiori alla lite, fino a quando essi possono capire e rappresentare in modo imparziale i punti di vista, e non permettere che i propri sentimenti di parte gli impediscano di riassumere lo stato del dibattito in una maniera neutrale.

Il reale contenuto della scheda non è oggetto di controversie. Col tempo le materie vengono al voto, i disaccordi vengono condensati in pochi problemi chiave, con etichette riconoscibili e brevi descrizioni. Occasionalmente lo sviluppatore farà obiezione alla forma della scheda stessa. A volte il suo interessamento è legittimo, per esempio, che una scelta importante è stata lasciata fuori o non è stata descritta accuratamente. Ma altre volte uno sviluppatore può star cercando si evitare l'inevitabile, forse sapendo che il voto non andrà come lui vuole. Vedere sezione chiamata «Gente Difficile» in Capitolo 6, Comunicazione su come affrontare questo tipo do ostruzionismo.

Ricordatevi di specificare il sistema di voto, se ci sono molti differenti modi, e se la gente potrebbe potrebbe fare delle cattive supposizioni sulla procedura che viene usata. Una buona scelta nella maggior parte dei casi è il voto per approvazione, dove ogni votante può votare per quante scelte vuole nella scheda. Il voto per approvazione è semplice da spiegare a da contare, e diversamente da altri metodi, richiede un solo giro di voto. Vedere http://en.wikipedia.org/wiki/Voting_system#List_of_systems per maggiori dettagli sul voto di approvazione ed altri sistemi di voto, ma cercate si evitare di entrare in una lunga discussione su quale sistema usare (perché, certamente, allora voi stessi vi troverete in una discussione su quale sistema di voto usare per decidere quale sistema di voto usare). Una ragione per cui il voto di approvazione è una buona scelta è che è molto difficile per ognuno farvi obiezione;—è all'incirca tanto giusto quanto un sistema di voto può esserlo.

Infine portate il voto in pubblico. Non c'è bisogno di segretezza o anonimato nel voto su questioni che avete dibattuto pubblicamente comunque. Ogni partecipante deve postare il suo voto nella mailing list, in modo che ogni osservatore possa registrare e controllare il risultato per se stesso, e in modo tale che ogni cosa sia registrata negli archivi.

La cosa più difficile nel voto è determinare quando farlo. In generale passare al voto dovrebbe essere molto raro—un ultimo ricorso quando tutte le altre opzioni sono fallite. Non pensate che il voto sia un gran modo di risolvere i dibattiti. Non lo è. Esso mette fine alle discussioni e quindi mette fine a un modo creativo di pesare ai problemi. Nella misura in cui la discussione continua, c'è la possibilità che qualcuno venga fuori con una nuova soluzione che piace a tutti. Ciò avviene sorprendentemente spesso. Un dibattito acceso può produrre un nuovo modo di pensare ai problemi, e portare a proposte che possono soddisfare tutti. Anche quando non vengono fuori nuove proposte, è usualmente ancora meglio venire a un compromesso che sostenere un voto. Dopo un compromesso, ognuno e un po' scontento, mentre dopo un voto, alcuni sono scontenti mentre altri sono contenti. Da un punto di vista politico è preferibile la prima situazione: almeno ciascuno può avvertire di aver ricavato una ricompensa per la sua scontentezza. Egli può essere insoddisfatto, ma così è anche per gli altri.

Il principale vantaggio del voto è che finalmente sistema una questione in modo che ognuno possa andare avanti, ma esso la sistema con un conto delle teste, invece che con un dialogo razionale che porti tutti alla medesima conclusione. Più le persone hanno esperienza con i progetti open source, meno desiderose le trovo di sistemare le cose col voto. Invece essi cercheranno di esplorare soluzione non precedentemente considerate, o arrivare a un compromesso più forte di quanto avessero precedentemente pianificato. Sono disponibili varie tecniche per impedire di arrivare ad un voto prematuro. La più ovvia è semplicemente dire “Io penso che non siete ancora pronti per il voto”, e spiegare perché no. Un'altra è chiedere una informale (non vincolante) alzata di mano. Se il responso tende chiaramente da una parte o dall'altra, ciò spingerà alcuni a volere subito un compromesso, ovviando al bisogno di voto. Ma il modo più efficace è semplicemente offrire una nuova soluzione, o un nuovo punto di vista su una vecchia proposta, in modo che le persone si occupino nuovamente dei problemi invece di ripetere solamente i vecchi argomenti.

In certi rari casi ognuno può convenire che tutte le soluzioni di compromesso sono peggiori di quelle di non compromesso. Quando ciò avviene, votare è meno spiacevole, sia perché è più probabile arrivare a una soluzione migliore sia perché la gente non si dispiacerà troppo non importa quale sia il risultato. Anche allora il voto non dovrebbe essere affretto. La discussione che porta al voto è ciò che educa l'elettorato, cosicché fermare quella discussione può prematuramente abbassare la qualità del risultato.

(Notate che questo avvertimento a non chiamare il voto non si applica al voto di cambio inclusione descritto in sezione chiamata «Stabilizzare una Release» in Capitolo 7, Confezione, Rilascio, e Sviluppo Quotidiano. Lì il voto è più di un meccanismo di comunicazioni, un mezzo per registrare il coinvolgimento di uno nel processo di revisione del cambiamento, così che ognuno può dire quanta revisione ha avuto un dato cambiamento.)

Avere un sistema di voto solleva la questione dell'elettorato: chi accede al voto? Ciò ha la potenzialità di essere un problema sensibile, perché obbliga il progetto a riconoscere alcune persone come più coinvolte, o come aventi più giudizio di altre.

La miglior soluzione è assumere una distinzione esistente, l'accesso all'invio, e annettere il privilegio di votare ad esso. In progetti che offrono sia il pieno che il parziale accesso all'invio, la questione se coloro che hanno l'invio parziale possano votare dipende largamente dal procedimento col quale è concesso l'accesso all'invio. Se il progetto lo distribuisce liberalmente, per esempio come un modo di mantenere molti mezzi conferiti da terze parti nel deposito, allora dovrebbe essere chiaro che l'accesso all'invio parziale è in realtà solo per l'invio, non per il voto. Naturalmente permane la implicazione inversa: poiché i possessori del pieno invio avranno privilegi di voto, essi devono essere scelti non solo nella qualità di programmatori, ma anche in quella di membri dell'elettorato. Se qualcuno mostra tendenze distruttive o ostruzioniste nella mailing list, il gruppo dovrebbe esser molto prudente sul fatto di renderlo uno che può fare gli invii, anche se la persona è tecnicamente competente.

Lo stesso sistema di voto dovrebbe essere usato per scegliere nuove persone che possono fare l'invio, sia pieno che parziale. Ma qui c'è uno dei rari casi in cui la segretezza è appropriata. Non potete ricevere voti sulle potenziali persone con diritto di voto postati in una pubblica mailing list, perché la sensibilità (e la reputazione) dei candidati potrebbero essere ferite. Invece, il modo usuale è che uno con diritto di invio posti su una mailing list privata costituita solo da altri con diritto di invio, che propongono che a qualcuno sia concesso l'accesso all'invio. Gli altri con diritto di invio parlano di quello che pensano liberamente, sapendo che la discussione è privata. Spesso non ci sarà disaccordo, e quindi non ci sarà necessità del voto. Dopo aver aspettato pochi giorni per essere sicuri che tutti quelli con diritto di voto abbiano avuto modo di rispondere, il proponente manda una email al candidato, e gli offre l'accesso all'invio. Se c'è disaccordo, ne deriva una discussione come per ogni altra questione, con la possibilità che si arrivi a votare. Perché questo procedimento sia aperto e franco, il solo fatto che la discussione sta avendo luogo dovrebbe punto essere segreto. Se la persona in considerazione sapesse che essa sta andando avanti, e che quindi non gli è offerto l'accesso all'invio, potrebbe concludere che ha perso il voto, e presumibilmente ne sarebbe dispiaciuto. Certamente se qualcuno fa richiesta di accesso all'invio, allora non c'è scelta al di fuori di quella di prendere in considerazione la proposta e apertamente accettarla o respingerla. Se la seconda, allora la cosa dovrebbe essere fatta quanto più educatamente possibile, con una chiara spiegazione: “A noi piacciono le tue rettifiche, ma non ne abbiamo viste a sufficienza” o “Noi apprezziamo tutte le tue rettifiche, ma esse richiedevano considerevoli miglioramenti prima di poter essere applicate, così non ci sentiamo a nostro agio nel darti già l'accesso all'invio. Speriamo che ciò cambierà, tuttavia, col tempo” Ricordate, ciò che state dicendo potrebbe riuscire come un colpo, a seconda del livello e della confidenza con la persona. Cercate di vederla dal loro punto di vista quando gli mandate l'email.

Poiché aggiungere una nuova persona che possa fare gli invii è più conseguenziale che la maggior parte delle decisioni di una volta, alcuni progetti hanno speciali requisiti per il voto. Per esempio essi possono richiedere che la proposta riceva almeno n voti positivi e nessun voto negativo, che una super maggioranza voti a favore. Il parametro esatto non è importante; l'idea base è far si che il gruppo sia cauto nell'aggiungere nuove persone che possono fare l'invio. Simili o più stringenti requisiti possono applicarsi ai voti per rimuovere uno che può fare gli invii, sebbene si speri che ciò non sarà mai necessario. Vedere sezione chiamata «Quelli Che Fanno gli Invii» in Capitolo 8, Gestire i Volontari di più sugli aspetti del non voto per aggiungere o rimuovere le persone che possono fare gli invii.

Per certi tipi di voto può essere utile espandere l'elettorato. Per esempio, se gli sviluppatori semplicemente non possono capire se la scelta di una data interfaccia si adatta al modo in cui la gente in realtà usa il software, un modo è chiedere a tutti gli iscritti alla mailig list del progetto di votare. Questi sono in realtà sondaggi piuttosto che voti, ma gli sviluppatori possono scegliere di trattare il risultato come vincolante. Come con ogni sondaggio, assicuratevi che sia chiaro ai partecipanti che c'è una opzione inclusa: se qualcuno pensa che non sia offerta una migliore scelta nelle domande del sondaggio, la sua risposta può riuscire come il più importante risultato del sondaggio.

Alcuni progetti permettono una specie di voto conosciuto come veto. Un veto è un modo per lo sviluppatore per mettere un alt a un frettoloso o mal considerato cambiamento. Pensate a un veto come a qualcosa fra una forte obiezione e una ostruzione. Il suo esatto significato varia da un progetto all'altro. Alcuni progetti rendono molto difficile ignorare un veto; altri consento loro di essere ignorati da un regolare voto della maggioranza, magari dopo un rallentamento forzato per una ulteriore discussione. Ogni veto dovrebbe essere accompagnato da una accurata spiegazione; un veto senza una tale spiegazione dovrebbe essere considerato invalido o una comparsa.

Con il veto viene l'abuso del veto. A volte gli sviluppatori sono troppo desiderosi di sollevare steccati per sbarazzarsi di un veto, quando in realtà quello per cui erano stati chiamati era un maggior discussione. Potete prevenire un abuso di veto con l'essere molto riluttanti verso il veto voi stessi e richiedendolo quando qualcun altro usa il suo veto troppo spesso. Se necessario potete ricordare al gruppo che i veti sono vincolanti solo finché il gruppo è d'accordo che lo siano dopotutto se una chiara maggioranza di sviluppatori vuole X, allora X sta per succedere in un modo o nell'altro. O gli sviluppatori che pongono i veti fanno marcia indietro, o il gruppo deciderà di sminuire il significato di un veto.

Potete vedere gente scrivere “-1” per esprimere un veto. Questo uso proviene dall'Apache Software Foundation che ha estremamente strutturato il procedimento di voto e di veto descritto a http://www.apache.org/foundation/voting.html. Gli standard Apache si sono diffusi agli altri progetti, e voi vedrete le loro convenzioni usate con varie sfumature in molti posti nel mondo dell'open source. Tecnicamente “-1” non indica sempre un veto formale anche in accordo con lo standard Apache, ma in modo informale ciò viene preso a significare un veto, o almeno una obiezione molto forte.

Come i voti, i veti possono applicarsi retroattivamente. Non sta bene per obiettare a un veto, sulla base del fatto che il cambiamento in questione è stato già inviato, o che l'iniziativa è stata presa (a meno che non sia qualcosa di irrevocabile, come l'emissione un comunicato stampa). D'altra parte un veto che arrivi con un ritardo di settimane o di mesi verosimilmente non è da prendere molto sul serio, nè dovrebbe esserlo.

La comunità è tuttavia importante per il successo del lavoro a contratto. Il suo coinvolgimento nel processo di progettazione e revisione per cambiamenti su misura non può essere un pentimento. Deve essere considerato parte del lavoro e pienamente compreso dal lavoratore a contratto. Non pensate all'esame accurato della comunità come a un ostacolo da superare pensate ad esso come a un libero tavolo di progetto e a un dipartimento di QA. E' un beneficio essere inseguiti come in una caccia, non solamente sopportatati.

Certamente quando state scegliendo un imprenditore, volete qualcuno con le giuste capacità tecniche ed esperienza per il lavoro. Ma è anche importante scegliere qualcuno con una traccia dei precedenti comportamenti e realizzazioni di una costruttiva interazione con gli altri sviluppatori nella comunità. In questo modo voi state prendendo più di una singola persona; voi state prendendo un agente che sarà capace di disegnare una rete di esperienze in modo da essere sicuri che il lavoro sia fatto in modo solido e mantenibile.

Nello sviluppo di software proprietario, è normale avere gente unicamente destinata alla garanzia della qualità: ricerca dei bug, tests di prestazioni e scalabilità, controllo dell'interfaccia e della documentazione. Come regola, queste attività non sono inseguite tanto vigorosamente dalla comunità di volontari nel progetto di software libero. In parte perchè è difficile trovare lavoro volontario per un lavoro non affascinante come il testing, in parte perché la gente tende a dare per scontato che l'avere una vasta comunità di utilizzatori dà al progetto una buona copertura di testing, e, nel caso del testing delle prestazioni e della scalabilità, in parte perché i volontari spesso non hanno l'accesso alle risorse hardware, in qualche modo.

La convinzione che avere molti utilizzatori è equivalente ad avere molti che testano non è completamente senza fondamento. Certamente non ha senso assegnare persone che testano funzionalità base in una ambiente comune: i bugs saranno rapidamente trovati dagli utilizzatori nel naturale corso delle cose. Ma poiché gli utilizzatori stanno giusto cercando di di finire il lavoro, inconsciamente non partono con l'intenzione di esplorare casi sconosciuti di funzionamento ai limiti nelle funzionalità dei programmi, e sono propensi a lasciare certi tipi di bugs non trovati. Inoltre, quando scoprono un bug con un facile stratagemma, spesso implementano in silenzio lo stratagemma senza darsi noia di riportare il bug. Ancora più insidiosamente, il modo d'uso dei vostri clienti (le persone che guidano il vostro interesse nel software) può differire in in modo statisticamente significativo dal modo d'uso dell'Utilizzatore Medio Della Strada.

Un gruppo professionale do testing può scoprire questo tipo di bugs, e può farlo facilmente sia con il software libero sia con il software proprietario. La sfida è di riportare al pubblico il risultati del gruppo di testing in una forma utile. I gruppi di testing in azienda usualmente hanno un loro modo di riportare questi risultati, impiegando un linguaggio specifico della compagnia o una conoscenza di particolari clienti e del loro gruppo di dati. Tali rapporti sarebbero inadatti per il tracciatore di bug pubblico, sia a causa della loro forma e a causa della confidenzialità. Anche se il software tracciatore di bugs interno della vostra compagnia fosse lo stesso di quello usato nei progetti pubblici, l'amministrazione poterebbe aver bisogno di commenti specifici della compagnia e di cambiamento dei meta dati (per esempio sollevare una priorità interna dei problemi o programmare la sua risoluzione per un particolare cliente). Usualmente tali note sono confidenziali—talvolta non sono nemmeno mostrate al cliente. Ma anche quando esse non sono confidenziali, esse non riguardano il progetto pubblico, e quindi il pubblico non dovrebbe essere distratto da essi.

Tuttavia il cuore stesso del rapporto dei bugs èimportante per il pubblico. Infatti un rapporto del vostro dipartimento di testing è più prezioso di un rapporto dagli utilizzatori in libertà, poiché il dipartimento di testing indaga su cose su cui altri non indagherebbero. Dato che è improbabile che voi otteniate quel rapporto di bugs da altra fonte, volete di sicuro preservarlo e renderlo disponibile per il progetto pubblico.

Per fare questo o un dipartimento QA può archiviare i problemi nel tracciatore di problemi pubblico, se lo trova comodo, o un intermediario (usualmente uno degli sviluppatori) può “trasportare” i rapporti del dipartimento interno di testing in nuovi problemi nel tracciatore pubblico. Trasporto significa semplicemente descrivere i bugs in un modo tale che non faccia riferimento all'informazione specifica del cliente (il sistema della ripetizione può usare dati del cliente, assumendo che egli lo approvi, certamente).

E' alquanto preferibile che il dipartimento QA archivi i problemi direttamente nel tracciatore pubblico. Ciò dà al pubblico una stima del coinvolgimento nel progetto della vostra compagnia: un utile riporto dei bugs conferisce alla vostra compagnia credibilità giusto come lo farebbe un contributo tecnico. Ciò anche dà agli sviluppatori una linea di comunicazione col gruppo di testing. Per esempio, se il gruppo interno di QA sta monitorando il tracciatore pubblico di problemi, uno sviluppatore può inviare una correzione per un bug di scalabilità (per il quale lo sviluppatore può non avere le risorse per testarlo da se), e quindi aggiungere una nota al problema chiedendo al QA di vedere se la correzione ha avuto l'effetto desiderato. Aspettatevi un po' di resistenza da parte di qualche sviluppatore; i programmatori hanno la tendenza a guardare al QA come, nel migliore dei casi, al diavolo. Il gruppo QA può rimediare a questo trovando bugs significativi e mettendo in archivio rapporti comprensibili; d'altra parte se i loro rapporti non sono almeno buoni quanto quelli provenienti dalla comunità degli utilizzatori regolari, allora è inutile averli in relazione direttamente con il team di sviluppo.

In un modo o nell'altro, una volta che esiste un pubblico problema il problema originale dovrebbe far riferimento al problema pubblico per il contenuto tecnico. L'organizzazione e gli sviluppatori pagati possono continuare ad annotare i problemi interni con commenti specifici della compagnia quanto necessario, ma usare il problema pubblico per una informazione che dovrebbe essere disponibile per tutti.

Dovreste entrare in questo processo aspettandovi spese extra. Mantenere due problemi per un bug è, naturalmente, un lavoro maggiore che mantenerne uno. Il beneficio è che molti codificatori vedranno il rapporto e saranno capaci di contribuire a una soluzione.

Le compagnie per profitto o noprofit sono quasi le uniche entità che pongono l'attenzione sui complessi aspetti legali del software libero. Gli sviluppatori individuali spesso capiscono le sottigliezze delle varie licenze open source ma non hanno il tempo o le risorse per seguire in dettaglio la legge sul copyright, sul marchi o sul brevetto. Se la vostra compagnia ha un dipartimento legale, può aiutare il progetto nel curare l'aspetto legale del codice, e aiutare gli sviluppatori a capire i potenziali problemi legali dei brevetti e del marchio. La forma che questo aiuto può prendere è discussa in Capitolo 9, Licenze, Diritti d'Autore e Brevetti. La cosa principale è essere sicuri che le comunicazioni fra il dipartimento legale e la comunità degli sviluppatori, se avviene punto, avvenga con il reciproco riconoscimento dei molto diversi universi da cui le parti provengono. Occasionalmente, questi due gruppi parlano uno dopo l'altro, ogni parte dando per scontato una comprensione dello specifico campo che l'altra non ha. Una buona strategia è avere un intermediario (usualmente, uno sviluppatore, oppure un legale con esperienza tecnica) che stia nel mezzo e medi finché sia necessario.

La documentazione e l'usabilità sono ambedue i punti delicati nei progetti open source, sebbene io penso, almeno nel caso della documentazione, che la differenza fra il software libero e quello proprietario sia frequentemente esagerata. Nondimeno è nei fatti vero che molti software open source difettano di una documentazione di prima classe e di ricerca di usabilità.

Se la vostra organizzazione vuole contribuire a riempire questi vuoti, probabilmente la cosa migliore che può fare è assumere le persone che non sono sviluppatori regolari nel progetto, ma che saranno capaci di interagire produttivamente con gli sviluppatori. Non assumere sviluppatori regolari è un bene per due ragioni: uno, in quel modo non portate via tempo dal progetto; due, quelli vicini al software sono usualmente le persone sbagliate per scrivere la documentazione o studiare l'usabilità, perché non hanno la il pensiero di vedere il software dal punto di vista di un estraneo.

Comunque sarà necessario per chiunque lavori a questi problemi comunicare con gli sviluppatori. Trovate persone che siano abbastanza tecniche per parlare col team dei codificatori, ma non così esperti nel software da non potersi ancora immedesimare nei normali utilizzatori.

Un utilizzatore di medio livello è la persona giusta per scrivere una buona documentazione. Infatti, dopo che la prima edizione di questo libro fu pubblicata, ricevetti la seguente email da uno sviluppatore open source chiamato Dirk Reiners:

Un commento sui Soldi:: La documentazione e l'Usabilità: quando avevamo
qualche soldo da spendere e concludemmo che una guida per quelli che 
cominciavano era la parte più critica  assumemmo un utilizzatore di medio
livello per scriverla. Egli era andato per induzione al sistema abbastanza
recentemente per ricordare i problemi, ma era passato attraverso di essi 
per sapere come descriverli. Ciò gli permise di scrivere qualcosa che
serviva solo per le correzioni minori da parte di sviluppatori di base per 
le cose che non aveva capito bene, ma che tuttavia trattava le 'ovvie' cose 
che gli sviluppatori avrebbero tralasciato.

Il suo caso era persino migliore, come se fosse stato suo compito introdurre 
un sacco di altra gente (studenti) nel sistema, in modo che egli unì 
l'esperienza di tanta gente, che è qualcosa che fu una felice avvenimento 
e che è probabilmente difficile da raggiungere nella maggior parte dei casi.

Per un progetto che non stia usando un hosting confezionato gratuito (vedere sezione chiamata «Canned Hosting» in Capitolo 3, L'Infrastruttura Tecnica ), procurare un server e una connessione a un netwoork e in modo molto rilevante, un sistema di aiuto all'amministrazione può essere di significativa assistenza. Anche se questo è tutto quello che la vostra organizzazione fa per il progetto, può essere moderatamente un modo efficace per ottenere una buona atmosfera di pubbliche relazioni, sebbene ciò non porterà ad una influenza sulla direzione del progetto.

a che fare con la vostra compagnia, anche se voi non contribuite per nulla allo sviluppo. Il problema è, gli sviluppatori sono al corrente di questa tendenza associativa eccessiva, e possono non essere contenti di avere il loro progetto sul vostro dominio a meno che voi non immettiate più risorse che non la sola banda. Dopotutto ci sono un sacco di posti che danno hosting di questi tempi. La comunità può eventualmente essere del parere che la relativa cattiva assegnazione del riconoscimento non equivale alla convenienza ottenuta con l'hosting e trasferire il progetto altrove. Così se volete fornire l'hosting, fatelo—ma o pianificate di essere coinvolti di più presto o state attenti a quanto coinvolgimento reclamate.

Nell'intento di mantenere dalla vostra parte la comunità degli sviluppatori volontari èmolto importante non dire ciò non sia in modo dimostrabile vero. Verificate tutte le affermazioni con cura, prima di farle e date al pubblico i mezzi per verificare le vostre affermazioni da se. La verifica indipendente dei fatti è una parte importante dell'open source e si applica a molto più che al solo codice.

Naturalmente nessuno consiglierebbe alle compagnie di fare affermazioni non verificabili comunque. Ma con le attività open source, c'è una insolita gran quantità di gente con l'esperienza per verificare le affermazioni le persone che trovano conveniente anche avere un accesso a internet a larga banda e i giusti contatti sociali per pubblicizzare le sue conclusioni in un modo da danneggiare, dovrebbero sceglierlo loro. Quando la Global Megacorp Chemical Industries inquina un corso d'acqua, questo è verificabile, ma solo da parte di scienziati esperti, lanciando alla gente di grattarsi la testa e di chiedersi cosa pensare. Invece il vostro comportamento nel mondo dell'open source non è solo visibile e registrato; è anche possibile per molta gente verificarlo indipendentemente, pervenire alle proprie conclusioni e propagare quelle conclusioni per via orale. Queste reti di comunicazioni sono già in piedi; esse sono l'essenza di come l'open source opera, e possono essere usate per trasmettere ogni sorta di informazione. La confutazione è usualmente difficile, se non impossibile, specialmente quando ciò che la gente sta dicendo è la verità.

Per esempio è giusto riferire alla vostra organizzazione di aver “fondato il progetto X” se realmente lo avete fatto. Ma non fate riferimento a voi stessi come i “costruttori di X” se la maggior parte del codice è stato scritto da estranei. Al contrario, non proclamate di aver profondamente coinvolto una comunità di sviluppatori volontari se chiunque può vedere nel vostro deposito e constatare che ci sono pochi o nessun cambiamento al codice provenienti dal di fuori della vostra organizzazione.

Non molto tempo fa, vidi un annuncio da parte di una ben nota compagnia, che affermava che la compagnia stava rilasciando un importante confezione di un software sotto una licenza open source. Quando l'annuncio iniziale uscì, diedi un'occhiata al deposito del controllo della ora pubblica versione e vidi che conteneva solo tre revisioni. In altre parole quelli avevano fatto una importazione iniziale del codice sorgente, ma difficilmente qualcosa era avvenuta da allora. Cosa che in se stessa non era —quelli avevano fatto solo un annuncio dopotutto. Non c'era motivo di aspettarsi una grande attività di sviluppo immediatamente.

Qualche tempo più tardi, quelli fecero un altro annuncio. Questo è quello che diceva, con il nome e il numero di versione sostituiti da pseudonimi:

Curioso di sapere cosa la comunità avesse scoperto “nei rigorosi tests” ritornai al deposito a vedere la storia dei loro cambiamenti recenti. Il progetto era ancora alla revisione 3. Apparentemente non avevano trovato una sola correzione di bug di pregio prima della release. Pensando che il risultato dei tests della comunità potessero essere stati registrati altrove, esaminai il tracciatore di bugs. Li c'erano esattamente aperti 6 problemi, 4 dei quali erano stati aperti ormai per diversi mesi.

Questo è incredibile, certamente. Quando i collaudatori controllano su un grande e complesso pezzo di software per un certo tempo, troveranno bugs. Anche se le correzioni di questi bugs non lo trasformano nella prossima release, uno tuttavia si aspetterebbe qualche attività di controllo della versione come risultato del processo di prova, o almeno qualche nuovo problema. Eppure a tutta apparenza, niente era avvenuto tra l'annuncio della licenza open source e le prima release open source.

Il punto non è che la compagnia stava mentendo sull'attività di prova della comunità. Non ho idea se lo stesse facendo o no. Ma essi erano ignari di quanto sembrava verosimile che essi stavano mentendo. Siccome né il controllo di versione né il deposito di controllo né il tracciatore di problemi davano indicazione che le asserite prove erano avvenute non avrebbero dovuto fare l'affermazione in primo luogo, o avrebbero dovuto fornire un link a qualche tangibile risultato di quelle prove (“Abbiamo trovato 287 bugs; cliccare qui per i dettagli”). La seconda cosa avrebbe permesso a chiunque di capire il livello dell'attività della comunità molto velocemente. Così com'era mi ci vollero pochi minuti per determinare che qualunque cosa fosse questa comunità di prova, non aveva lasciato tracce in nessuno dei posti usuali. Quello non fu un grande sforzo, e sono sicuro che non sono il solo che si prese il disturbo.

La trasparenza e la possibilità di verifica sono anche una parte importante della credibilità, certo. Vedere sezione chiamata «Riconoscimenti» in Capitolo 8, Gestire i Volontari per maggiori informazioni su questo.

Astenetevi dal dare cattive opinioni sul software open source concorrente. E' perfettamente giusto fornire fatti —negativi cioè affermazioni facilmente confermabili del tipo spesso visto in buoni quadri comparativi. Ma caratterizzazioni di natura meno rigorosa è meglio evitarle, per due ragioni. Primo, esse possono portare a guerre di ingiurie che distolgono da discussioni produttive. Secondo, e più importante, alcuni dei vostri sviluppatori volontari nel vostro progetto possono anche allontanarsi per lavorare al progetto concorrente. Ciò è più probabile di quando potrebbe sembrare in un primo momento: i progetti sono già nello stesso dominio (che è il motivo per cuoi sono in competizione), e sviluppatori con esperienza in quel dominio possono dare contributi dovunque la loro esperienza è applicabile. Anche quando non c'è una diretta sovrapposizione di sviluppatori è probabile che gli sviluppatori del vostro progetto abbiano familiarizzato con gli sviluppatori del progetto affine. La loro capacità di mantenere rapporti costruttivi personali potrebbe essere intralciata da messaggi negativi di marketing.

Primo, esse possono portare a guerre di ingiurie che distolgono da discussioni produttive. Secondo, e più importante, alcuni dei vostri sviluppatori volontari nel vostro progetto possono anche allontanarsi per lavorare al progetto concorrente. Ciò è più probabile di quando potrebbe sembrare in un primo momento: i progetti sono già nello stesso dominio (che è il motivo per cuoi sono in competizione), e sviluppatori con esperienza in quel dominio possono dare contributi dovunque la loro esperienza è applicabile. Anche quando non c'è una diretta sovrapposizione di sviluppatori è probabile che gli sviluppatori del vostro progetto abbiano familiarizzato con gli sviluppatori del progetto affine. La loro capacità di mantenere rapporti costruttivi personali potrebbe essere intralciata da messaggi negativi di marketing. Colpire prodotti closed source concorrenti sembra essere largamente accettato nel mondo open source, specialmente quando questi prodotti sono creati dalla Microsoft. Personalmente io deploro questa tendenza (sebbene d'altra parte non ci sia nulla di sbagliato nella chiara comparazione dei fatti), non solo perché è rozzo, ma anche perché è dannoso per un progetto partire credendo che ciò sia una propria pubblicità e quindi ignorare i modi in cui la competizione può essere veramente migliore. In generale guardatevi dagli effetti che le leggi del marketing possono avere sulla vostra comunità di sviluppo. La gente può venire così eccitata nell'essere sostenuta dai dollari del marketing da perdere la propria obiettività sulle vere solidità e debolezze del suo software. E' normale, e anche previsto, per una compagnia di sviluppatori esibire un certo distacco nei confronti delle leggi del marketing, anche in forum pubblici. Chiaramente essi non dovrebbero venir fuori e contraddire il messaggio di marketing direttamente (a meno che esso non sia veramente sbagliato, tuttavia uno spera che quel tipo di cosa dovrebbe essere scoperta prima). Ma possono prendersi gioco di questo, di volta in volta, come modo per riportare il resto della comunità di sviluppo sulla terra.

Non cadete nella trappola di scrivere tutto come se fosse un messaggio di testo per il telefono cellulare. Scrivete frasi complete, mettendo la maiuscola alla prima parola di ogni frase, e usate interruzione di paragrafo dove necessario. Ciò è fondamentale nelle email e in altri scritti strutturati. In IRC o forum similarmente effimeri, va generalmente bene lasciare perdere le maiuscole usare abbreviazioni di espressioni comuni eccetera. Soltanto non portate queste abitudini in forum più formali, persistenti. Email, documentazione, segnalazioni di bug, e altre forme di scrittura pensate per persistere dovrebbero essere scritte usando la grammatica e la sintassi standard, e avere una struttura narrativa coerente Questo non è perchè c'è qualcosa di interiormente buono nel seguire regole arbitrarie, ma piuttosto queste regole non sono arbitrarie: sono evolute nella forme attuali perchè rendono il testo più leggibile, e dovreste seguirle per questa ragione. La leggibilità  è desiderabile non solo perchè significa che più persone capiranno cosa scrivete, ma perchè vi fa apparire come il tipo di persona che usa del tempo per comunicare chiaramente: cioà  qualcuno a cui valga la pena dare attenzione.

Soprattutto per le email, gli sviluppatori esperti di open source hanno stabilito alcune convenzioni:

Mandare solo email di puro testo, no HTML, RichText, o altri formati che potrebbero essere opachi ad alcuni lettori di email di solo testo. Impostate le vostre righe per essere lunghe circa 72 colonne. Non andate oltre le 80 colonne, che sono diventate lo standard de facto della lunghezza di terminale (cioè alcuni usano terminali più larghi, ma nessuno ne usa di più stretti). Facendo le vostre righe un po' meno di 80 colonne, lasciate spazio per alcuni livelli di caratteri di citazione aggiunti nelle risposte di altri senza costringere alla riformattazione del vostro testo.

Usate vere interruzioni di linea. Alcuni programmi di mail fanno una specie di falsa delimitazione di riga, quindi quando state scrivendo una mail, il display mostra delle interruzioni di linea che in realtà  non ci sono. Quando la email viene spedita, potrebbe non avere le interruzioni di linea voi pensiate che abbia, e si disporrà  in maniera orrenda sugli schermi di un po' di gente. Se il vostro programma può usare false interruzioni di linea, cercate una qualche impostazione che possiate attivare per fare in modo di mostrare le vere interruzioni di linea quando scrivete.

Quando si includono output video, stralci di codice, o altro testo preformattato, delimitatelo chiaramente, così che anche un occhio pigro possa facilmente vedere i confini tra le vostre parole e il materiale che state evidenziando. (Non mi sarei mai aspettato di scrivere un consiglio come questo quando iniziai questo libro, ma più avanti su un gran numero di mailing list open source, ho visto gente mischiare testo da diverse fonti senza rendere chiaro cosa fosse cosa. L'effetto è molto frustrante. Rende i loro post decisamente più difficili da capire, e sinceramente fa vedere queste persone come un po' disordinate.)

Quando citate una email di qualcun altro, inserite le vostre risposte dove è più appropriato, in molti posti diversi se necessario, e tagliate via le parti della mail che non usate. Se state scrivendo un breve commento che riguarda all'intero messaggio, va bene anticipare il commento (cioè mettere la vostra risposta al di sopra del testo citato della email); altrimenti, dovreste prima citare la porzione rilevante del testo originale, seguita dalla vostra risposta.

Scegliete attentamente l'oggetto delle vostre email. E' la riga più importante della vostra email, perchè permette ad ogni altra persona nel progetto di decidere se leggerla o meno. I moderni software di lettura email organizzano gruppi di messaggi correlati in thread, che possono essere definiti non solo da un oggetto comune, ma da vari altri header (che a volte non sono mostrati) Ne consegue che se un thread inizia ad andare verso un nuovo argomento, potete—e dovreste—aggiustare di conseguenza l'oggetto quando rispondete. L'integrità  del thread sarà  preservata, grazie a quegli altri header, ma il nuovo oggetto aiuterà  la gente che cerca un'idea del thread a sapere che il soggetto è cambiato. Similarmente, se davvero volete iniziare un nuovo argomento, fatelo mandando una nuova email, e non rispondendo a email esistenti e cambiandone l'oggetto. Altrimenti, la vostra email sarebbe ancora raggruppata con quelle dello stesso thread a cui state rispondendo, e quindi confonderebbe la gente nel pensare che sia su qualcosa che non è. Di nuovo, la pena non sarebbe solo lo spreco del loro tempo, ma la piccola falla nella vostra credibilità  come qualcuno spigliato nell'uso dei mezzi di comunicazione.

Email ben formattate attraggono i lettori, ma il contenuto li mantiene. Nessun insieme di regole fisse può garantire un buon contenuto, certo, ma ci sono alcuni principi che lo rendono possibile.

Rendete le cose facili ai vostri lettori. Ci sono tonnellate di informazioni in giro in ogni progetto open source attivo, e non ci si può aspettare che i lettori siano familiari con la maggior parte dell'informazione—infatti, non ci si può aspettare che sappiano come diventarne familiari. Ovunque possibile, i vostri messaggi dovrebbero fornire informazione nella forma più appropriata per i lettori. Se dovete usare due minuti in più per cercare una URL di un particolare thread negli archivi della mailing list per risparmiare ai lettori di farlo, ne vale la pena. Se dovete spendere 5 o 10 minuti riassumendo le conclusioni fino a questo punto di un thread complesso, così da dare alla gente un contesto in cui capire il messaggio,allora fate così. Pensatela in questo modo: più un progetto ha successo, più alto sarà  il rapporto lettori per scrittore in ogni dato forum. Se ogni messaggio che pubblicate è visto da n persone, allora quando n cresce, la convenienza di fare uno sforzo extra per risparmiare tempo a questa gente sale con lui. E quando la gente vi vede imporre a voi stessi questo standard, lavorerà  per fare altrettanto nelle loro comunicazioni. Il risultato è, idealmente, un aumento dell'efficienza globale del progetto: quando c'è una scelta tra che n persone facciano uno sforzo e una persona farlo, il progetto preferisce la seconda ipotesi.

Non perdetevi in iperboli. Esagerare nei messaggi in linea è una tipica corsa alle armi. Per esempio, una persona che segnala un bug potrebbe preoccuparsi che gli sviluppatori non gli presteranno sufficente attenzione, quindi lo descriverà  come un problema serio e bloccante che sta impedendo a lui (e a tutti i suoi amici/colleghi/cugini) di usare il software in maniera produttiva, quando è soltanto una piccola noia. Ma l'esagerazione non è limitata agli utenti—i programmatori a volte fanno lo stesso durante dibattiti tecnici, in particolare quando il disaccordo è su di una questione di gusto piuttosto che di correttezza:

Lo stesso sentimento in realtà  diventa più forte quando espresso in maniera meno netta:

Non sarete in grado di liberarvi completamente dalle iperboli, e in generale non è necessario. Rispetto ad altre forme di cattiva comunicazione, l'iperbole non è globalmente dannosa—danneggia principalmente chi la fa. I destinatari possono compensarla, soltanto il mittente perde un po' più credibilità  ogni volta. Quindi, per l'amore della vostra stessa influenza nel progetto, provate a stare nel lato della moderazione. In questo modo, quando voi avete bisogno di fare un'affermazione forte, la gente vi prenderà  seriamente.

Controllate due volte. Per ogni messaggio più lungo di un paragrafo di media grandezza, rileggetelo dall'inizio alla fine prima di mandarlo ma dopo che pensate di averlo finito una prima volta. Questo è un consiglio noto a chiunque abbia seguito lezioni di composizione, ma è soprattutto importante nelle discussioni online. Dato che il processo di comporre online tende ad essere altamente discontinuo (durante la scrittura di un messaggio, potreste aver bisogno di andare indietro e controllare altre email, visitare alcune pagine web, usare un comando per catturare il suo output di debug eccetera) è incredibilmente facile perdere il vostro senso di posizione nella narrazione. I messaggi che sono stati composti in maniera discontinua e non controllati prima di essere inviati sono spesso riconoscibili come tali, soprattutto dallo smarrimento ( o così si dovrebbe sperare) dei loro autori. Prendetevi del tempo per rivedere cosa mandate. Più i vostri messaggi stanno assieme strutturalmente, più saranno letti.

Dopo aver scritto migliaia di messaggi, probabilmente noterete il vostro stile diventare conciso. Questa sembra essere la norma nella maggior parte dei forum tecnici, e non c'è nulla di sbagliato di per sè. Un grado di concisione che sarebbe inaccettabile nelle normali interazioni sociali è semplicemente la normalità  per chi ha a che fare con il free software. Qui c'è una risposta che una volta presi da una mailing list su qualche CMS (content management system) ben in evidenza:

Puoi spiegare un po' di più esattamente qual'è il tuo problema,eccetera?

Anche:

Che versione di Slash stai usando? Non l'ho capito dal tuo precedente messaggio.

Esattamente, come hai fatto il build del codice apache/mod_perl?

Hai provato la patch di Apache 2.0 di cui si è parlato su slashcode.com?

  Shane

Ora, questo è conciso! Nessun saluto, nessuna firma a parte il nome, e il messaggio stesso è solo un serie di domande poste nel modo più compatto possibile. La sua unica frase dichiarativa era una implicita critica al mio messaggio originale. Eppure, fui felice di vedere la email di Shane, e non presi la sua concisione come segno di nient'altro se non essere una persona occupata. Il mero fatto che stava chiedendo domande, invece di ignorare il mio messaggio, significava che voleva spendere del tempo sul mio problema.

Tutti i lettori reagiranno positivamente al suo stile? Non necessariamente; dipende dalla persona e dal contesto. Per esempio, se qualcuno ha appena scritto riconoscendo di aver fatto un errore (magari aveva segnalato un bug), e sapete dalla vostra esperienza passata che questa persona tende ad essere un po' insicura, allora mentre potreste scrivere una risposta compatta, dovreste fare in modo di completarlo con un qualche tipo di presa di coscienza dei suoi sentimenti. Il grosso della vostra risposta può essere una precisa, ingegneristica analisi della situazione, concisa quanto volete. Ma alla fine, scrivete qualcosa che indichi che la vostra concisione non deve essere presa per freddezza. Per esempio, se avete appena dato una gran quantità  di consigli esattamente su come la persona deve riparare il bug, poi concludete con "Buona fortuna, <il vostro nome>" per indicare che gli augurate del bene e che non è pazzo. Uno smiley strategicamente piazzato o altro genere di emoticon può a volte essere anche abbastanza per rassicurare un interlocutore.

Può sembrare strano focalizzarsi tanto sui sentimenti dei partecipanti quanto sulla superficie di cosa dicono, ma per dirla semplicemente, i sentimenti condizionano la produttività . I sentimenti sono importanti anche per altre ragioni, ma anche limitandoci a livelli puramente utilitaristici, possiamo notare che persone infelici scrivono software peggiore, e meno. Data la natura ristretta della maggior parte dei media elettronici, comunque, non ci sarà  spesso alcuna indicazione di come una persona si sente. Dovrete farvi una educata idea basata su a) come la maggior parte della gente si sentirebbe in quella situazione, e b) cosa sapete di questa particolare persona da passate interazioni. Alcune persone preferiscono un atteggiamento diretto, e trattare semplicemente con chiunque come fossero faccia a faccia, con l'idea che se un partecipante non tira fuori che si sente in un particolare modo, allora uno non ha modo di trattare con lui come dovrebbe. Non seguo questo approccio, per alcune ragioni. Uno, la gente non si comporta così nella vita reale, quindi perchè dovrebbero online? Due, dato che la maggior parte delle interazioni avviene in forum pubblici, la gente tende ad essere ancora più riservata nell'esprimere emozioni che se fosse in privato. Per essere più precisi, spesso vogliono esprimere emozioni dirette agli altri, come gratitudine o rabbia, ma non emozioni dirette verso se stessi, come insicurezza o orgoglio. Comunque, la maggior parte degli umani lavora meglio quando sanno che gli altri sono al corrente del loro stato di pensiero. Prestando attenzione a piccoli indizi, potete solitamente indovinare giusto la maggior parte delle volte, e motivare la gente a rimanere coinvolta ad un livello maggiore di quello che altrimenti farebbero.

Certo non voglio dire che il vostro ruolo sia di essere un terapista di gruppo, aiutanto costantemente tutti a rimanere in contatto con i loro sentimenti. Ma facendo molta attenzione ai percorsi sul lungo periodo del comportamento umano, inizierete ad avere un'idea di loro come individui anche se non li avete mai incontrati faccia a faccia. Ed essendo sensibile al tono del vostro scrivere, potete avere una sorprendente influenza su come gli altri si sentono, per il bene finale del progetto.

Una delle caratteristiche distintive della cultura open source è la sua nozione di cosa costituisce maleducazione e cosa no. Mentre le convenzioni descritte in seguito non sono peculiari dello sviluppo di software libero, nè del software in generale— dovrebbero essere familiari a chiunque lavori in matematica, scienze dure, o discipline ingegneristiche—il software libero, con i suoi confini porosi e il costante afflusso di nuove leve, è un ambienete dove la gente non abituata a queste convenzioni si contri con loro.

Cominciamo con le cose che non sono maleducate:

Il criticismo tecnico, anche quando diretto e non filtrato, non è maleducato. Invece, può essere una forma di adulazione: la critica sta dicendo, per implicazione, che vale la pensa prendere seriamente in considerazione il suo bersaglio, e vale la pena spenderci un po' di tempo. Vale a dire, più sarebbe stato facile ignorare il post di qualcuno, più diventa un complimento prendere del tempo per criticarlo (ovviamente a meno che la critica diventi un attacco ad hominem o qualche altra farma di palese maleducazione).

Anche domande grezze e spoglie, come quelle di Shane a me nella mail prima citata, non sono maleducate. Domanede che in altri contesti sembrano fredde, retoriche o persino ironiche, sono spesso intese come serie, e non hanno nessun obbiettivo nascosto tranne ottenere informazioni il più velocemente possibile. La famosa domanda del supporto tecnico "Il tuo computer è attaccato alla corrente?" è un classico esempio di questo. La persona di supporto davvero ha bisogno di sapere se il tuo computer è attaccato alla corrente, e dopo i primi giorni di lavoro, si è stancato di premettere alla domanda qualche educato preambolo ("Chiedo scusa, vorrei soltanto farle alcune semplici domande per escludere alcune possibilità. Alcune di queste sono molto elementari,ma mi aiuti..."). A questo punto, non gli interessano più i preamboli, chiede direttamente: è attaccato o no? Domande simili sono fatte di continuo nelle mailing list di software libero. L'intento non è insultare il destinatario, ma per escludere velocemente le spiegazioni più ovvie ( e magari le più comuni). I destinatari che capiscono questo e rispondono di conseguenza, guadagnano punti nell'ottenere una visione ampia senza chiedere pressantemente. Ma i destinatari che reagiscono male non devono essere neanche esclusi. E' solo uno scontro di culture, non è colpa di nessuno. Spiegate amabilmente che le vostre domande (o critiche) non avevano significati nascosti; erano solo tesi ad ottenere (o trasmettere) informazioni nel modo più efficiente possibile, nient'altro.

Cos'è allora maleducato?

Per lo stesso principio per cui un dettagliato criticismo tecnico è una forma di adulazione, non fornire critica di qualità può essere un insulto. Non intendo semplicemente ignorare il lavoro di qualcuno, sia esso una proposta, un cambiamento al codice, la segnalazione di un nuovo problema o altro. A meno che non abbiate esplicitamente promesso in anticipo una risposta dettagliata, va solitamente bene semplicemente non rispondere per niente. La gente assumerà che non avevate tempo di dire nulla. Ma se rispondete, non risparmiate; prendete il tempo per analizzare davvero le cose, fornire esempi concreti dove appropriato, spulciare negli archivi per cercare post correlati nel passato eccetera. O se non avete tempo di imbarcarvi in questo tipo di sforzo, ma tuttavia avete bisogno di scrivere qualche tipo di risposta veloce, allora scrivetelo apertamente nel messaggio ("Penso che ci sia un problema registrato per questo, ma sfortunatamente non ho avuto il tempo di cercarlo, mi dispiace"). La cosa principale è riconoscere l'esistenza della norma culturale, o assecondandola o riconoscendo apertamente di non aver avuto tempo. In entrambi i modi, la norma è rispettata. Ma non rispettarla, allo stesso tempo non spiegando perchè non l'avete fatto, è come dire che la discussione (e coloro che vi partecipano) non valeva il vostro tempo. E' meglio mostrare che il vostro tempo è prezioso essendo chiari che essendo pigri.

Ci sono certamente molte altre forme di maleducazione, ma la maggior parte di queste non sono peculiari del software libero, e il senso comune è una sufficiente guida per evitarle. Vedete anche sezione chiamata «Stroncate sul Nascere la Scortesia» in Capitolo 2, Partenza, se non l'avete ancora fatto.

C'è una regione nel cervello umano che è dedicata in maniera specifica al riconoscimento delle facce. E' informalmente nota come 'area fusiforme della faccia', e le sue capacità sono nella maggior parte innate, non imparate. Ne consegue che riconoscere gli individui è talmente una capacità cruciale per la sopravvivenza che abbiamo sviluppato hardware specializzato per farlo.

La collaborazione basata su Internet è quindi psicologicamente strana, perchè implica una stretta collaborazione tra esseri umani che non riescono praticamente mai ad identificarsi l'un l'altro con i metodi più naturali ed intuitivi: il riconoscimento facciale innanzitutto, ma anche il suono della voce, la postura eccetera. Per compensare a questo, provate ad usare un nome immagine consistente ovunque. Potrebbe essere la parte iniziale del vostro indirizzo email (la parte prima del simbolo @), il vostro username IRC, il nome che usate nei commit, lo username del tracciamento dei problemi, eccetera. Questo nome è la vostra "faccia" online : una breve stringa identificativa che provvede ad alcuni degli stessi usi della vostra vera faccia, anche se sfortunatamente non stimola lo stesso hardware integrato nel cervello.

Il nome immagine dovrebbe essere qualche permutazione intuitiva del vostro nome reale (il mio, per esempio, è "kfogel"). In alcune situazioni sarà comunque accompagnato dal vostro nome completo, per esempio nelle testate delle email:

From: "Karl Fogel" <kfogel@whateverdomain.com>

In realtà, ci sono due cose in questo esemio. Come menzionato prima, il nome immagine rimanda al nome reale in modo intuitivo. Inoltre, il nome reale è reale. cioè non è qualche appellativo costruito come:

From: "Fantastico Hacker" <fantasticohacker@undominio.com>

C'è un famosto fumetto di Paul Steiner, del 5 luglio 1993 uscito sul The New Yorker, che mostra un cane loggato ad un computer, guardare in basso e dire ad un altro in modo cospirativo: "In Internet, nessuno sa che sei un cane". Questo tipo di pensiero risiede probabilmente dietro a molte delle identità da fighi, auto-esaltanti che la gente si dà in rete—come se chiamarsi "Fantastico Hacker" farà davvero credere alla gente di esserlo. Ma il fatto rimane: anche se nessuno sa che sei un cane, sei ancora un cane. Una fantastica identità online non impressiona mai i lettori. Invece, li fa pensare che sei più forma che sostanza, o semplicemente che sei insicuro. Usate il vostro vero nome per tutte le interazioni, o se per qualche ragione avete bisogno di anonimato, allora costruite un nome che sembri come un nome perfettamente reale, ed usatelo consistentemente.

Oltre a tenere il vostro nome immagine consistente, ci sono alcune cose che potete fare per renderlo più attraente. Se avete un titolo ufficiale (per esempio "dottore", "professore", "direttore"), non ostentatelo, nè menzionatelo tranne quando è direttamente rilevante nella conversazione. Il mondo hacker in generale, e la cultura del software libero in particolare, tende a vedere l'esposizione del titolo come esclusiva e segno di insicurezza. Va bene se il vostro titolo appare come parte del blocco di firma standard alla fine di ogni email, solo non usatelo mai come mezzo per rinforzare la vostra posizione in una discussione—il tentativo garantisce fuoco di risposta. Volete la gente che rispetta voi, non il titolo.

Parlando dei blocchi di firma: manteneteli brevi e gradevoli, o meglio ancora, inesistenti. Evitate ingombranti disclaimer legali alla fine di ogni email, specialmente quando esprimono sentimenti incompatibili con la partecipazione ad un progetto di software libero. Per esempio, il seguente classico appare alla fine di ogni messaggio che un particolare utente manda su una pubblica mailing list di cui faccio parte:

OSSERVAZIONE IMPORTANTE

Se avete ricevuto questa email per errore o volete leggere il nostro disclaimer
per le email e la politica di monitoraggio, per favore fate riferimento sotto o contattate
il mittente.

Questa comunicazione proviene da Deloitte & Touche LLP.  Deloitte &
Touche LLP è una società a responsabilità limitata registrata in Inghilterra e Galles con
il numero registrato OC303675. Una lista dei nomi dei membri è disponibile
per ispezioni a Stonecutter Court, 1 Stonecutter
Street, London EC4A 4TR, United Kingdom, la sede principale dell'attività ed ufficio registrato. 
Deloitte & Touche LLP è autorizzato e regolato dalla Financial Services Authority.

Questa comunicazione e tutti gli allegati contengono
informazioni che sono confidenziali e possono essere legalmente protette.
Sono per l'uso esclusivo dei destinatari. Se non siete il destinatario, per favore
notate che ogni forma di comunicazione, pubblicazione, copia o uso di questa comunicazione
o delle informazioni contenute o degli allegati è strettamente proibita e può essere illegale.
Se avete ricevuto questa comunicazione per errore, per favore rimandatela con "ricevuta per errore"
come oggetto a to IT.SECURITY.UK@deloitte.co.uk e poi cancellate la email e distruggetene ogni copia.

Non si può garantire che le comunicazioni email siano sicure e senza errori,
dato che le informazioni possono essere intercettate, corrotte, stralciate, perse,
distrutte, in ritardo o incomplete, o contenenti virus. Non ci assumiamo
la responsabilità di nessuno di questi fatti o delle loro conseguenze. Chiunque comunichi
con noi via email accetta il rischio di farlo.

Quando inviate ai nostri clienti, tutti le opinioni o i consigli contenuti in questa
email ed ogni allegato sono soggetti ai termini e alle condizioni espresse nella lettera
di ingaggio del cliente in uso a Deloitte & Touche LLP.

Opinioni, conclusioni e altre informazioni in questa email e tutti gli allegati che non
riguardano gli affari ufficiali della ditta non sono da lei forniti nè supportati.

Per qualcuno che si mostra appena per chiedere qualcosa ogni tanto, questo enorme disclaimer sembra un po' strano ma probabilmente non fa male. Comunque, se questa persona volesse partecipare attivamente al progetto, questa sbrodolata legale inizierebbe ad avere effetti più insidiosi. Manderebbe almeno due segnali potenzialmente distruttivi: primo, che questa persona non ha pieno controllo dei suoi strumenti—è intrappolato in qualche programma di posta aziendale che appioppa un noioso messaggio alla fine di ogni email, e non ha avuto modo di evitarlo— e, secondo, che ha poco o nessun supporto organizzativo per le sue attività di software libero. Si che l'organizzazione chiaramente non gli ha impedito di lasciare messaggi sulle mailing list, ma ha fatto sembrare i suoi messaggi nettamente ostili, come se il rischio di far uscire informazioni confidenziali debba smorzare tutte le altre priorità.

Se lavorate in un'azienda che insiste nell'aggiungere tali blocchi di firma a tutte le email in uscita, allora cercate di avere un account email gratis come, per esempio, gmail.google.com, www.hotmail.com, o www.yahoo.com, e usare questo come indirizzo per il progetto.

Una trappola comune nella partecipazione a progetti in rete è pensare che dobbiate rispondere a tutto. Non dovete. Prima di tutto, solitamente ci saranno più thread che vanno avanti di quelli a cui potete star dietro, almeno dopo che il progetto ha passato i primi suoi mesi. Secondo, anche nei thread a cui avete deciso di partecipare, la maggior parte delle cose che la gente dice non avrà bisogno di risposta. I forum di sviluppo in particolare tendono ad essere dominati da tre tipi di messaggi:

Nessuno di questi richiede inerentemente di risposta, in particolare se potete essere sicuri, basandovi sull'esperienza accumulata nei thread, che qualcun altro probabilmente dirà comunque cosa avreste detto. (Se siete preoccupati di essere presi in un ciclo di attesa-attesa perchè anche tutti gli altri stanno usando la stessa tattica, non siatelo; c'è praticamente sempre qualcuno là fuori che si sentirà di saltare nel mucchio.) Una risposta dovrebbe essere motivata da un proposito definito. Innanzitutto chiedetevi: sapete cosa volete raggiungere? E poi: non sarà raggiunto a meno che voi diciate qualcosa?

Due buone ragioni per aggiungere la vostra voce ad un thread sono a) quando vedete un difetto in una proposta e sospettate di essere l'unico a vederlo, e b) quando vedete che sta succedendo qualche equivoco tra altri, e sapete che potete appianarlo con un messaggio chiarificatore. Va solitamente bene fare un messaggio per ringraziare qualcuno per aver fatto qualcosa, o per dire "Anche io!", affinchè un lettore possa capire facilmente che tale messaggio non ha bisogno di nessuna risposta o ulteriore azione, e quindi lo sforzo mentale richiesto dal messaggio finisce nettamente quando il lettore arriva all'ultima riga delle email. Ma anche allora, pensateci due volte prima di dire qualcosa; è sempre meglio lasciare la gente desiderare che voi postiate di più invece che di meno. (Vedete la seconda metà di Appendice C, Perchè dovrebbe importarmi di che colore sia la rastrelliera? per ulteriori pensieri su come comportarsi su mailing list trafficate.)

Su una mailing list trafficata, avete due imperativi. Uno, ovviamente, è capire di cosa avete bisogno di seguire e cosa potete ignorare. L'altro è di comportarvi in modo da evitare di causare rumore: non solo volete che i vostri messaggi abbiano un alto tasso segnale/rumore, volete anche che siano quel tipo di messaggio che stimola altra gente a scrivere con un simile tasso segnale/rumore o non scrivere per niente.

Per vedere come fare ciò, considerate il contesto in cui avviene. Quali sono alcuni dei segnali di un thread improduttivo?

Solo perchè un thread non è produttivo non basta per stabilire che sia una perdita di tempo. Potrebbe trattare un argomento importante, nel qual caso il fatto che non si stia risolvendo rende tutto più problematico.

Guidare un thread verso l'utilità senza essere pressanti è un'arte. Non funzionerà semplicemente consigliando alla gente di smettere di perdere il loro tempo, o chiedendo loro di non scrivere a meno di avere qualcosa di costruttivo da dire. Potreste, certo, pensare queste cose privatamente, ma se lo dite ad alta voce allora sarete offensivi. Invece, dovete suggerire le condizioni per ulteriori progressi—dare alla gente una strada, un sentiero da seguire che porta ai risultati che volete, pur senza sembrare di stare dettando la strada. La distinzione è principalmente di tono. Per esempio, questo non va bene:

Mentre questo è buono:

Confrontate il secondo approccio con il primo. Il secondo modo non traccia una linea tra voi e gli altri, nè li accusa di procedere in una discussione a spirale. Parlo di "noi", che è importante sia che abbiate o meno partecipato veramente nel thread in precedenza, perchè ricorda a tutti che anche quelli che sono stati in silenzio fino ad ora possono ancora contribuire al risultato del thread. Descrive perchè il thread non sta andando da nessuna parte, ma lo fa senza peggiorazioni o giudizi—spassionatamente preciso solo alcuni fatti. Più importante, offre un corso positivo di azioni, così che invece di sentirsi come se la discussione sia stata troncata (una restrizione verso cui potrebbero solo tentare di ribellarsi), la gente si sentirà come se fosse stata loro offerto un modo di portare la conversazione ad un livello più costruttivo. Questo è uno standard che la gente vorrà naturalmente raggiungere.

Non vorrete sempre portare un thread al prossimo livello di costruttività—a volte vorrete solo farlo finire. Il proposito del vostro messaggio allora è fare uno o l'altro. Se potete dire dal modo in cui il thread è andato fino ad allora che nessuno da veramente facendo i passi che suggerite, allora il vostro messaggio effettivamente chiude il thread senza sembrare di farlo. Di certo non c'è nessun modo a prova di idiota per chiudere un thread, e anche se ci fosse, non vorreste usarlo. Ma chiedere ai partecipanti o di mostrare progressi visibili o di smettere di scrivere è perfettamente difendibile, se fatto diplomaticamente. Siate comunque attenti nel fermare prematuramente i thread. Un po' di chiacchiere possono essere produttive, a seconda dell'argomento, e chiedere che sia risolto troppo velocemente soffocherà il processo creativo, così come vi farà sembrare impazienti.

Non aspettatevi che un thread si stoppi all'istante. Ci saranno comunque ancora alcuni messaggi dopo al vostro, sia perchè le mail si saranno incrociate nell'instradamento, o perchè la gente vuole avere l'ultima parola. Questo non è nulla di cui preoccuparsi, e non avete bisogno di scrivere di nuovo. Lasciate la gente calmarsi, o non calmarsi, a seconda dei casi. Non potete avere completo controllo; dall'altro lato, potete aspettarvi di avere statisticamente un effetto significativo su molti thread.

Anche se la discussione può deviare su ogni argomento, la probabilità di deviazione sale quando la difficoltà tecnica di un argomento diminuisce. Dopo tutto, maggiore è la difficoltà tecnica, meno partecipanti potranno veramente seguire cosa sta succedendo. Quelli che possono essere gli sviluppatori più esperti, che hanno già preso parte in queste discussioni migliaia di volte in precedenza, e sanno che tipo di comportamento può portarli ad ottenere quel consenso con cui ognuno può andare avanti.

Quindi, il consenso è più difficile da ottenere nelle questioni tecniche che sono semplici da capire ed è facile farsi un'opinione, ed in argomenti "leggeri" come l'organizzazione, la pubblicità, i fondi, eccetera. La gente può partecipare a queste discussioni sempre, poichè non sono necessarie qualifiche per farlo, nessun modo chiaro per decidere (anche dopo) se una decisione sia stata giusta o sbagliata, e perchè aspettare più a lungo degli altri partecipanti alla discussione è a volte una tattica vincente.

Il principio che la quantità di discussione è inversamente proporzionale alla complessità dell'argomento ha circolato per molto tempo, ed è noto informalmente come l'Effetto Bikeshed. Segue la spiegazione di Poul-Henning Kamp, da un messaggio ora famoso fatto agli sviluppatori BSD:

(Vale anche la pena leggere il suo messaggio completo. Vedete Appendice C, Perchè dovrebbe importarmi di che colore sia la rastrelliera?; o anche http://bikeshed.com.)

Chiunque abbia mai preso regolarmente parte in qualche gruppo di decision riconoscerà di cosa Kamp sta parlando. Comunque, è solitamente impossibile persuadere tutti di evitare di disegnare rastrelliere. La cosa migliore che possiate fare è precisare che il fenomeno esiste, quando vedete che sta succedendo, e persuadere gli sviluppatori anziani—le persone i cui messaggi hanno maggior peso—di posare i loro pennelli presto, così almeno loro non contribuiscono al rumore. Dipingere rastrelliere non scomparirà mai del tutto, ma potete renderlo più breve e meno frequente diffondendo la coscienza del fenomeno nella cultura del progetto.

Una Guerra Santa è una disputa, spesso ma non sempre riguardo ad un problema relativamente secondario, in cui la gente si sente abbastanza appassionata da continuare a discutere in ogni caso nella speranza che la loro parte prevalga. Le guerre sante non sono come dipingere rastrelliere. La gente che dipinge rastrelliere è solitamente rapida nel saltare su con un'opinione (perchè loro possono), ma non se ne sentiranno necessariamente convinti, infatti potranno a volte esprimere altre opinioni incompatibili, per mostrare che capiscono tutti i versi del problema. In una guerra santa, d'altro canto, capire le altre posizioni è un segno di debolezza. In una guerra santa, tutti sanno che c'è Una Risposta Giusta; solo non sono d'accordo su quale sia.

Una volta che una guerra santa è iniziata, in genere non può essere risolta accontentando tutti. Non fa bene puntualizzare, nella mischia di una guerra santa, che una guerra santa è in corso. Tutti lo sanno già. Purtroppo, un tratto comune delle guerre sante è il disaccordo sulla domanda se la disputa è risolvibile continuando la discussione. Visto da fuori, è chiaro che nessuno schieramento sta cambiando le idee dell'altro. Visto da dentro, l'altro schieramento è ottuso e non sta pensando in modo chiaro, ma ci potrebbero arrivare se pressati abbastanza. Ora, non sto dicendo che non ci sia mai uno schieramento giusto in una guerra santa. A volte c'è—nelle guerre sante a cui ho partecipato, è sempre stato il mio ovviamente. Ma non importa, perchè non c'è un algoritmo per dimostrare in modo convincente che uno schieramento o l'altro abbia ragione.

Un modo comune ma non soddisfacente con cui la gente prova a risolvere le guerre sante è dire "Abbiamo già speso più tempo ed energia discutendo ciò di quanto ne valga la pena! Possiamo per favore semplicemente lasciare stare?" Ci sono due problemi in questo. Primo, questo tempo e questa energia sono già stati spesi e non potranno mai essere recuperati— l'unica domanda è quanto altro sforzo rimane? Se certa gente pensa che solo ancora un poco di discussione porterà il problema alla fine, allora ha ancora senso (dal loro punto di vista) continuare.

L'altro problema nel chiedere di lasciare perdere il problema è che questo è spesso equivalente a permettere ad uno schieramento, lo status quo, di dichiarare la vittoria per mancanza di azioni. E in alcuni casi, lo status quo è comunque noto per essere inaccettabile: tutti sono d'accordo che qualche decisione deve essere presa, qualche azione intrapresa. Lasciare il soggetto sarebbe peggio per tutti di quanto lo sarebbe per qualcuno lasciare perdere. Ma dato che il dilemma si applica ugualmente a tutti, è comunque possibile finire a discutere per sempre su cosa fare.

So how should you handle holy wars?

Allora come dovreste trattare le guerre sante?

La prima risposta è fate in modo che non succedano. Non è una cosa così senza speranza come sembra:

Potete anticipare alcune guerre sante standard: tendono a venire fuori sui linguaggi di programmazione, licenze (vedi sezione chiamata «La GPL e la compatibilità di Licenza» in Capitolo 9, Licenze, Diritti d'Autore e Brevetti), blocco dei reply-to ( vedi sezione chiamata «Il grande dibattito sul 'Rispondi A'» in Capitolo 3, L'Infrastruttura Tecnica ), e alcuni altri argomenti. Ogni progetto solitamente ha una sua guerra santa o due, con cui gli sviluppatori di lunga data diventeranno presto familiari. Le tecniche per fermare le guerre sante, o almeno limitarne i danni, sono sempre le stesse ovunque. Anche se siete convinti che il vostro schieramento abbia ragione, cercate di trovare qualche modo di esprimere simpatia e comprensione per gli argomenti che l'altro schieramento propone. Spesso il problema in una guerra santa è che poichè ogni schieramento ha costruito le proprie mura le più alte possibile, e reso chiero che ogni altra opinione è pura follia, l'atto di arrendersi o cambiare la propria idea diventa psicologicamente intollerabile: sarebbe l'ammissione non solo di aver sbagliato, ma di essere stati certi e comunque aver sbagliato. Il modo in cui potete rendere questa ammissione accettabile per l'altro schieramento è di esprimere voi stessi qualche dubbio—precisamente mostrando che capite gli argomenti che stanno facendo e trovarli almeno interessanti, se non alla fine convincenti. Fate un gesto che dia spazio per un gesto reciproco, e solitamente la situazione migliorerà. Non sarà più facile nè difficile raggiungere il risultato tecnico che volevate, ma almeno potete evitare inutili danni morali al morale del progetto.

Quando una guerra santa non può essere evitata, decidete presto quanto ci tenete, e poi vogliate pubblicamente lasciarla perdere. Quando fate così. potete dire che vi tirate indietro perchè non ne vale la pena, ma non esprimete amarezza e non usate l'occasione per un ultimo colpo agli argomenti dello schieramento opposto. Lasciare perdere è efficace solo quando fatto con grazia.

Le guerre sante sui linguaggi di programmazione sono un po' un caso speciale, perchè spesso sono altamente tecnici, e comunque molte persone si sentono qualificate a prenderne parte, e la posta è molto alta, dato che il risultato può determinare in quale linguaggio una buona parte del codice del progetto sarà scritta. La soluzione migliore è scegliere presto il linguaggio, con l'appoggio degli influenti sviluppatori iniziali, e poi difenderlo per il fatto che è quello per cui siete a vostro agio ad usarlo, non sul fatto che è meglio di qualche altro linguaggio che avrebbe invece potuto essere usato. Non lasciate mai degenerare la conversazione in un confronto accademico sui linguaggi di programmazione ( che sembra accadere in particolare spesso quando qualcuno tira fuori Perl, per qualche ragione); è l'argomento mortale in cui dovete semplicemente rifiutarvi di farvi trascinare.

Per una maggiore conoscenza delle guerre sante, vedi http://catb.org/~esr/jargon/html/H/holy-wars.html, e l'articolo di Danny Cohen che rese popolare il termine, http://www.ietf.org/rfc/ien/ien137.txt.

In ogni discussione su mailing list, è facile per una piccola minoranza dare l'impressione che ci sia un grande problema di dissenso, inondando la mailing list con numerose lunghe email. E' un po' come una guerriglia, tranne il fatto che l'illusione di dissenso diffuso è persino più potente, perchè è divisa in un arbitrario numero di messaggi discreti e la maggior parte della gente non si preoccuperà di tenere traccia di chi ha detto cosa, quando. Avranno la vaga impressione che l'argomento è molto controverso, aspetteranno che la confusione finisca.

Il modo migliore per contrastare questo effetto è puntualizzare chiaramente e fornire prove a supporto di quanto piccolo sia il vero numero dei dissidenti, rispetto a quelli che sono d'accordo. Per incrementare la disparità, potreste voler chiedere privatamente alla gente che è stata quasi sempre zitta, ma che sospettate che sarebbe d'accordo con la maggioranza. Non dite nulla che suggerisca che i dissidenti volessero deliberatamente provare ad accrescere l'impressione che stavano dando. Ci sono possibilità che non lo facessero, e se anche lo avessero fatto, non c'è nessun vantaggio strategico nel puntualizzarlo. Tutto ciò di cui avete bisogno è mostrare i veri numeri in un confronto faccia a faccia, e la gente capirà che la loro percezione della situazione non corrisponde alla realtà.

Questo consiglio non vale solo per problemi con chiare posizioni pro e contro. Vale in ogni discussione dove c'è confusione, ma non è chiaro che la maggior parte della gente consideri il problema in discussione un vero problema. Dopo un po', se siete d'accordo che il problema non vale l'azione, potete vedere che ha fallito nell'ottenere seguito (anche se ha generato molte email), potete semplicemente osservare pubblicamente che non c'è seguito. Se l'effetto "minoranza rumorosa" ha lavorato, il vostro messaggio sembrerà come un respiro di aria fresca. L'impressione della maggior parte della gente della disussione fino a quel momento sarà stata in qualche modo confusa: "Huh, di sicuro sembra che ci sia qualche grosso problema qui, perchè ci sono molti messaggi, ma non riesco a vedere succedere nessun progresso". Spiegando come la forma della discussione la faccia apparire più turbolenta di quando sia davvero, gli date retrospettivamente una nuova forma, in cui la gente può rivedere la propria comprensione di cosa ne veniva fuori.

Per contrastare tale comportamento, aiuta capire la mentalità di coloro che lo adottano. Solitamente la gente non lo fa di proposito. Nessuno si sveglia al mattino e dice a se stesso: "Oggi cinicamente manipolerò i form procedurali per essere un irritante ostruzionista." Piuttosto, tali azioni sono spesso precedute da una sensazione semi-paranoica di essere tagliato fuori dalle interazioni e decisioni del gruppo. La persona sente che non sarà presa in considerazione seriamente, o (nei casi più gravi) che c'è quasi una cospirazione contro di lui—che gli altri membri del gruppo hanno deciso di formare un club esclusivo, di cui lui non è membro. Questo allora giustifica, nella sua mente, il prendere le regole alla lettera e procedere in una manipolazione formale delle procedure del progetto, per farsi prendereseriamente in considerazione da tutti gli altri. In casi estremi, la persona può persino pensare che sta combattendo una battaglia solitaria per salvare il progetto da se stesso.

E' la natura di questo tipo di attacco dall'interno che non tutti lo noteranno nello stesso momemento, e certa gente potrebbe non vederlo del tutto a meno che presentato con forte evidenza. Questo significa che neutralizzarlo potrebbe essere un bel po' di lavoro. Non è abbastanza persuadere voi stessi che sta succedendo; dovete trovare abbastanza prove anche per persuadere gli altri, e poi dovete far conoscere queste prove in modo intelligente.

Dato che è così tanto lavoro combattere, è spesso meglio tollerarlo giusto un po'. Pensatelo come una malattia da parassiti, ma leggera: se non è troppo debilitante, il progetto può permettersi di rimanere infetto, e le medicine avrebbero dolorosi effetti collaterali. Comunque, se tollerarla diventa troppo dannoso, allora è il momento di agire. Iniziate a prendere appunti sulle modalità che vedete. Fate in modo di includere riferimenti agli archivi pubblici—questa è una delle ragioni per cui il progetto registra le cose, così potete anche usarle. Una volta che avete costruito un buon caso, iniziate ad avere conversazioni private con altri partecipanti al progetto. Non dite loro cosa avete osservato, piuttosto, chiedete prima a loro cosa hanno osservato. Questa potrebbe essere la vostra ultima possibilità di avere un riscontro non filtrato di come gli altri vedono il comportamento di chi crea problemi; una volta che iniziate a parlarne apertamente, l'opinione diventerà polarizzata e nessuno sarà in grado di ricordare cosa avesse pensato in precedenza riguardo al problema.

Se le discussioni private indicano che almeno anche qualcun altro vede il problema, allora è il momento di fare qualcosa. Questo è quando dovete diventare veramente cauti, perchè è molto facile per questo tipo di gente cercare di far sembrare come se li steste criticando ingiustamente. Qualunque cosa facciate, non accusateli mai di abusare in modo malizioso delle procedure del progetto, di essere paranoici, o, in generale, di tutte le altre cose che sospettate siano probabilmente vere. La vostra strategia deve essere di sembrare sia più ragionevole e più concentrato con la salute generale del progetto, con l'obiettivo di o riformare il comportamento della persona, o farlo andare via in maniera definitiva. A seconda degli altri sviluppatori, e della vostra relazione con loro, potrebbe essere vantaggioso prima cercare alleati privatamente. O potrebbe non esserlo; potrebbe solo creare malumori dietro le quinte, se la gente pensa che stiate intraprendendo una impropria campagna silenziosa.

Ricordate che anche se l'altra persona potrebbe essere uno che si comporta in maniera distruttiva, voi sarete quelli che appaiono distruttivi se fate una pubblica accusa da cui non potete tornare indietro. Siate sicuri di avere molti esempi per dimostrare quello che state dicendo, e ditelo il più gentilmente possibile pur essendo diretti. Magari non persuaderete la persona in questione, ma va bene fino a quando persuadete tutti gli altri.

Ricordo solo una situazione, in più di 10 anni di lavoro nel software libero, dove le cose si fecero così cattiva che dovemmo chiedere tutti insieme a qualcuno di smettere di scrivere. Come spesso accade, non era maleducato, e sinceramente voleva solo essere d'aiuto. Solo non sapeva quando scrivere e quando non scrivere. Le nostre mailing list sono aperte al pubblico, e lui stava scrivendo così spesso, e chiedendo domande su così tanti argomenti diversi, che stava diventando un problema di rumore per la comunità. Avevamo già provato a chiedergli gentilmente di fare un po' più di ricerca di risposte prima di scrivere, ma non aveva avuto effetto.

La strategia che alla fine funzionò è un perfetto esempio di come costruire un caso robusto su dati neutrali e in quantità. Uno dei nostri sviluppatori fece un po' di scavi negli archivi, e poi mandò il seguente messaggio privatamente a pochi sviluppatori. L'imputato (il terzo nome nella lista sotto, mostrato qui come "J. Random") aveva una storia molto breve nel progetto, e non aveva contribuito codice nè documentazione. E comunque era il terzo più attivo produttore di messaggi sulla mailing list:

From: "Brian W. Fitzpatrick" <fitz@collab.net>
To: [... lista dei destinatari omessa per riservatezza ...]
Subject: Il Lavandino dell'energia di Subversion
Date: Wed, 12 Nov 2003 23:37:47 -0600

Negli ultimi 25 giorni, i sei maggiori produttori di messaggi sulla mailing list svn
[sviluppatori|utenti] sono stati:

    294  kfogel@collab.net
    236  "C. Michael Pilato" <cmpilato@collab.net>
    220  "J. Random" <jrandom@problematic-poster.com>
    176  Branko Čibej <brane@xbc.nu>
    130  Philip Martin <philip@codematters.co.uk>
    126  Ben Collins-Sussman <sussman@collab.net>

Vorrei dire che cinque di queste persone stanno contribuendo a Subversion, che
raggiungerà 1.0 nel prossimo futuro.

Vorrei anche dire che una di queste persone sta consumando in maniera consistente il tempo
e l'energia degli altri 5, per non dire della mailing list intera,
quindi (magari non intenzionalmente) rallentando lo sviluppo di Subversion. Non ho
fatto un'analisi di tutti i thread, ma facendo il vgrep delle mie mail di Subversion si vede
che ogni mail di persona ha ricevuto risposta almeno una volta da almeno 2 delle altre 5 persone
della lista sopra.

Penso che qui sia necessario qualche tipo di intervento radicale, anche se faremo scappare
via la persona sopracitata. Carinerie e gentilezze si sono già dimostrate senza effetto.

dev@subversion è una mailing list per facilitare lo sviluppo di un sistema
di controllo di versione, non una sessione di terapia di gruppo.

-Fitz, che prova a guadare attraverso tre giorni di email svn che ha lasciato accumulare

Anche se potrebbe non sembrare così a prima vista, il comportamento di J.Random era un classico esempio di abuso delle procedure di progetto. Non stava facendo nulla di ovvio come provare a sabotare un voto, ma stava abusando della politica della mailing list di affidarsi sulla auto moderazione dei suoi membri. Abbiamo lasciato al giudizio di ogni individuo quando scrivere messaggi e su quali argomenti. Quindi, non avevamo procedure di ricorso per gestire qualcuno che o non aveva, o non usava, tale giudizio. Non c'era alcuna regola a cui riferirsi e dire che il tizio la stava violando, eppur tutti sapevano che il suo frequente scrivere messaggi stava diventando un problema serio.

La strategia di Fitz era, in retrospettiva, da maestro. Ha trovato un esempio dannatamente fondato, ma poi l'ha distribuito discretamente, mandandolo prima alle poche person il cui supporto sarebbe stato la chiave per ogni azione drastica. Si sono trovati d'accordo che qualche tipo di azione era necessaria, e alla fine abbiamo chiamato J. Random al telefono, descritto il problema a lui direttamente, e gli abbiamo chiesto semplicemente di smetterla di scrivere messaggi. Lui non ha mai veramente capito il perchè; se fosse stato in grado di capire, probabilmente avrebbe fin dall'inizio usato un criterio adeguato. Ma accettò di smettere di scrivere, e la mailing list tornò ad essere utilizzabile. Parte del motivo per cui questa strategia ha funzionato, magari, è stata l'implicita minaccia che avremmo potuto iniziare a limitare i suoi messaggi usando il software di moderazione solitamente usato per prevenire lo spam (vedi sezione chiamata «Prevenire lo spam» in Capitolo 3, L'Infrastruttura Tecnica ). Ma la ragione per cui eravamo in grado di avere questa opzione di riserva è stata il fatto che Fitz ha in primo luogo trovato il necessario supporto nelle persone importanti.

Tipicamente tutte le comunicazioni in un progetto open source (eccetto talvolta le conversazioni IRC) vengono archiviate. Gli archivi sono pubblici e vi si possono fare ricerche, e hanno una stabilità informativa: cioè, una volta che un dato pezzo di informazione è registrato in un particolare indirizzo, rimane in quell'indirizzo per sempre.

Usate questi archivi quanto più è possibile, e quanto più in modo visibile possibile. Anche quando sapete la risposta spontanea a qualche domanda, se pensate che c'è un riferimento nell'archivio che contiene la risposta, spendete tempo a riportarla alla luce e fornitela. Ogni volta che fate ciò in modo visibile, qualche persona imparerà che ci sono gli archivi lì, e che cercare in essi può produrre risposte. Anche, riferendovi agli archivi invece di riscrivere il consiglio, rafforzate una norma sociale contro la duplicazione delle informazioni. Perché avere la stessa risposta in due posti differenti? Quando il numero di posti in cui essa può essere trovata è tenuto al minimo, le persone che le hanno trovate prima è molto probabile che ricordino cosa cercare per trovale di nuovo. Riferimenti ben collocati, possono anche contribuire alla qualità dei risultati della ricerca in generale, perchè essi rafforzano il ranking della risorsa obiettivo nei motori di ricerca di Internet.

Ci sono volte in cui la duplicazione delle informazioni ha senso, comunque. Per esempio, supponete che ci sia già una risposta negli archivi, non vostra, che dice:

Pare che in vostri indici di Scanley si siano imbrogliati. Per ripararli fate questi passi:

1. Spegnete il server di Scanley.
2. Fate girare il programma 'sbroglia' che si carica con Scanley.
3. Avviate il server.

Allora, mesi dopo, vedete un altro post che indica che gli indici di qualcuno si sono imbrogliati. Cercate negli archivi e vien fuori la vecchia risposta di sopra, ma vi rendete conto che sono mancanti alcuni passi (forse per errore, o perché il software è cambiato da quando quel post fu scritto). Il modo classico di gestire ciò è postare un nuovo, più completo set di istruzioni, e rendere obsoleto il vecchio post menzionandolo:

Pare che in vostri indici di Scanley si siano imbrogliati. Vedemmo questo problema nel lontano Luglio, e J. Casuale postò una soluzione a http://blahblahblah/blah. Sotto c'è una completa descrizione di come sbrogliare i vostri indici, basata sulle istruzioni di  J.  Casuale ma che le estende un poco:

1. Spegnete il server di Scanley.
2. Diventate l'utilizzatore col quale il server di Scanley gira.
3. Come tale utilizzatore fate girare il programma 'sbroglia' per gli indici.
4. Fate girare Scanley a mano per vedere se gli indici funzionano ora.
5. Riavviate il server.

(In un mondo ideale, sarebbe possibile attaccare una nota al vecchio post, che dica che c'è una informazione più fresca e che punti al nuovo post. Comunque non so di un nuovo software per l'archiviazione che offra una funzionalità “obsoleto per”, forse perchè sarebbe leggermente complessa da implementarsi in un modo che non violi l'integrità dell'archivio in quanto registrazione parola per parola. Questa è un'altra ragione perché creare pagine dedicate con risposte alle domande comuni è una buona idea).

Negli archivi probabilmente si ricerca di più per risposte a domande tecniche, ma la loro importanza per i progetto va ben al di là di questo. Se le linee guida formali di un progetto sono la sua legge statutaria, gli archivi sono la sua legge comune: una registrazione di tutte le decisioni prese e di come sono arrivate là. In ogni discussione ricorrente è quasi obbligatorio oggigiorno partire con una ricerca nell'archivio. Questo ti permette di incominciare una discussione con un sommario dello stato corrente delle cose, di anticipare obiezioni, di preparare i rifiuti, e possibilmente di scoprire degli angoli a cui non avevate pensato. Anche, gli altri partecipanti si aspetteranno che abbiate fatto una ricerca nell'archivio. Anche se le discussioni precedenti non andarono da nessuna parte, voi dovreste includere dei puntatori ad esse quando balza si di nuovo l'argomento (così la gente può guardare da sé) che non a) andarono da nessuna parte e probabilmente diranno ora ciò che non è stato detto prima b) che voi avete fatto i vostri compiti, e quindi state probabilmente dicendo cose che non sono state dette prima.

<un name=”miaetichetta”>...</a>

<p id=”miaetichetta”>...</p>

http://myproject.example.com/faq.html#miaetichetta

<a name="mia etichetta"></a>

<a name=”miaetichetta” title=”miaetichetta”>...</a>

Nella misura in cui un progetto acquista anzianità e complessità, la quantità di dati che ogni partecipante che arriva deve assorbire cresce. Coloro che sono stati col progetto per lungo tempo saranno in grado di imparare, e inventare, le convenzioni del progetto nella misura in cui andarono avanti. Essi spesso non saranno consapevolmente al corrente di quale enorme corpo di tradizione hanno accumulato, e possono essere sorpresi di fronte a quanti passi falsi sembrano fare i nuovi arrivati. Certo, il fatto non è che i nuovi arrivati siano di qualche qualità inferiore di prima; è che essi sono di fronte a un più grande carico di acculturazione rispetto ai nuovi arrivati del passato.

L'anzianità che il progetto accumula è tanta nel comunicare e nel preservare le informazioni quanta essi ne hanno negli standard del codice e altre minuterie tecniche. Noi abbiamo dato un'occhiata a tutti e due i tipi di standard in sezione chiamata «La documentazione sviluppatore» in Capitolo 2, Partenza e sezione chiamata «Metter Giù Tutto Per Iscritto» in Capitolo 4, L'Infrastruttura Sociale e Politica rispettivamente e gli esempi sono dati lì. Ciò di cui tratta questa sezione è come mantenere le linee guida aggiornate nella misura in cui il progetto si evolve, specialmente le linee guida su come sono trattate le comunicazioni, perché queste sono le uniche che cambiano al massimo grado nella misura in cui il progetto cresce in grandezza e complessità.

Primo, prestate attenzione ai motivi per i quali la gente si confonde. Se vedete la stessa situazione presentarsi ancora e ancora, specialmente con i nuovi partecipanti. La possibilità che c'è è è una linea guida che necessita di di essere documentata e non lo è. Secondo, non vi stancate di dire la stessa cosa ancora e ancora, e non suonate come se siete stanchi di dirle. Voi e i veterani di altri progetti dovete ripeterlo a voi stessi; questo è un effetto inevitabile dell'arrivo di nuovi arrivati.

Ogni pagina web, ogni messaggio della mailing list, ed ogni canale IRC dovrebbe essere considerato uno spazio per i consigli, non per pubblicità, eccetto che per pubblicità delle risorse del vostro progetto. Ciò che mettete in quello spazio dipende dalla demografia di quelli che lo leggono. Un canale IRC per le domande degli utilizzatori, è, per esempio, adatto a portare gente che che non ha mai interagito col progetto prima—spesso qualcuno che ha appena installato il software e ha una domanda a cui vorrebbe venga risposto immediatamente (dopotutto, se potesse aspettare, l'avrebbe mandata alla mailing list, che probabilmente meno meno del suo tempo totale, sebbene ci vorrebbe di più perché ne venga indietrouna risposta). La gente di solito non fa un investimento permanente nel canale IRC; essi si presentano, fanno la loro domanda, e vanno via.

Quindi l'argomento del canale dovrebbe essere diretto a persone che cercano risposte tecniche sul software adesso, piuttosto che a, diciamo, a persone che potrebbero essere coinvolte nel progetto nel lungo termine e per i quali le linee guida di interazione della comunità potrebbero essere più appropriate. Qui è come un canale occupato gestisce ciò (comparate questo col precedente esempio in sezione chiamata «IRC / Sistemi di Chat in tempo reale» in Capitolo 3, L'Infrastruttura Tecnica ):

State parlando su #linuxhelp

L'argomento per #linuxhelp è Prego LEGGERE
http://www.catb.org/~esr/faqs/smart-questions.html &&
http://www.tldp.org/docs.html#howto PRIMA di fare domande | Le regole del canale si trovano a http://www.nerdfest.org/lh_rules.html | Prego consultare
http://kerneltrap.org/node/view/799 prima di chiedere di aggiornare al kernel 2.6.x | lettura di memoria possibile: http://tinyurl.com/4s6mc ->
aggiornare a 2.6.8.1 o 2.4.27 | in certa misura disastro hash: http://tinyurl.com/6w8rf
| reiser4 fuori

Con le mailing list lo “spazio pubblicitario” è una piccola è un piccolo spazio in basso attaccato ad ogni messaggio. La maggior parte dei progetti vi mettono lì le istruzioni iscrizione/deiscrizione, e magari un puntatore alla homepage oppure alla pagina delle FAQ. Voi potreste pensare che chi si è iscritto alla mailing list saprebbe dove trovare queste cose ed essi probabilmente lo sanno—ma molta più gente di quelli che si sono iscritti vedono questi messaggi della mailing list. Un post archiviato può essere linkato da molti posti, alcuni post diventano cosi largamente noti che alla fine hanno molti più lettori al di fuori della mailing list che dentro.

La formattazione può fare molta differenza. Per esempio, nel progetto di Subversion, noi stavamo avendo un limitato esito favorevole nell'usare il filtro dei bug descritto in sezione chiamata «Pre-Filtraggio del Bug Tracker» in Capitolo 3, L'Infrastruttura Tecnica . Molti rapporti di bug fasulli stavano venendo archiviati da gente inesperta, e ogni volta che ciò avveniva, l'archiviatore doveva essere educato esattamente nello stesso modo di 500 persone prima di lui. Un giorno, dopo che uno dei nostri sviluppatori era finalmente arrivato alla fine della sua cordata e aveva inveito contro qualche utilizzatore deficitario che non leggeva le linee guida del tracciatore di problemi abbastanza con cura, un altro sviluppatore decise che questo comportamento era andato avanti a lungo abbastanza. Egli suggerì che noi formattassimo la pagina frontale del tracciatore di bug in modo che la parte più importante, la ingiunzione a discutere il bug sulla mailing list o sul canale IRC prima di archiviarlo, si distinguesse per l'enormità, lettere in grassetto rosso, su uno sfondo giallo brillante, centrato in prominenza sopra ogni altra cosa nella pagina. Noi facemmo così (potete vederne i risultati a http://subversion.tigris.org/project_issues.html), e il risultato fu un salto notevole nella velocità dei problemi fasulli archiviati. Ancora li prendiamo, certo, noi li prenderemo sempre ma la velocità è diminuita considerevolmente, anche se il numero degli utilizzatori cresce. La conclusione è non solo che il database contiene meno spazzatura, ma che quelli che rispondono alla archiviazione dei problemi rimangono di umore migliore e sono più propensi a restare amichevoli quando rispondono ad una archiviazione di una delle adesso rare archiviazioni fasulle. Questo migliora sia l'immagine del progetto, sia la salute mentale dei suoi volontari.

La lezione per noi fu che scrivere solamente le linee guida non era abbastanza. Noi dovevamo metterle dove sarebbero state viste da coloro che più di tutti avevano bisogno di esse, e formattarle in modo tale che il loro stato come materiale di introduzione sarebbe stato immediatamente chiaro alle persone non familiari col progetto.

Le pagine statiche non sono il solo luogo per far pubblicità ai clienti del progetto. E' anche richiesta una certa quantità di politica interattiva (nel senso di “ricordare amichevolmente” non nel senso di ammanettare e mettere in prigione). Tutta la revisione paritaria, anche le revisioni degli invii descritte in sezione chiamata «Praticare una Visibile Revisione del Codice» in Capitolo 2, Partenza, dovrebbe includere la revisione della conformità o non conformità della gente alle norme del progetto, specialmente riguardo alle convenzioni delle comunicazioni.

Un altro esempio dal progetto di Subversion: noi stabilimmo che “r12908" significasse "revisione 12908” nel deposito del controllo di versione. Il prefisso minuscolo “r” è facile da battere, e poiché è la metà dell'altezza delle cifre, esso rende un blocco di testo facilmente riconoscibile quando combinato con le cifre. Certo, quando una email di invio arriva con un messaggio di log come questo:

------------------------------------------------------------------------
r12908 | qsimon | 2005-02-02 14:15:06 -0600 (Mer, 02 Feb 2005) | 4 righe

Patch dal collaboratore J. Casuale <jrcontrib@gmail.com>

* trunk/contrib/client-side/psvn/psvn.el:
  Corretti alcuni  errori di stampa dalla revisione 12828.
------------------------------------------------------------------------

...parte della revisione di questo invio è per dire “Strada facendo prego usate 'r12828', non 'revisione 12828' quando vi riferite al cambiamento passato”. Questa non è pedanteria; è altrettanto importante per l'analisi sintattica automatica quanto per i lettori umani.

Seguendo il principio generale che ci dovrebbero essere dei metodi di riferimento canonico e che questi metodi di riferimento dovrebbero essere usati coerentemente ovunque, il progetto in effetti esporta certi standards. Questi standards mettono la gente in grado di scrivere strumenti che presentino le comunicazioni del progetto in modi più usabili—per esempio un revisione formattata come "r12828" potrebbe essere trasformata in un link vivo al sistema di osservazione del deposito. Ciò sarebbe piuttosto difficile se la revisione fosse scritta "revisione 12828", sia perché quella forma potrebbe essere divisa da una interruzione di linea, sia perché è meno distinta (la parola “revisione” apparirà spesso da sola, e il gruppo dei numeri apparirà spesso da solo, mentre la combinazione "r12828" può significare solo un numeri di revisione. Simili preoccupazioni si applicano ai numeri di problema, voci di FAQ (suggerimento: usate un URL con un'ancora con nome, come descritto in Ancore con nome e attributi ID), ecc.

Anche per le entità dove non c'è una ovvia breve, forma canonica, la gente tuttavia dovrebbe essere incoraggiata a fornire pezzi chiave di informazione coerentemente. Per esempio, quando ci si riferisce ad un messaggio della mailing list, non date solo il mittente e i soggetto; date anche l'URL dell'archivio e e la testata Message ID. L'ultimo permette alla gente che ha la sua copia della mailing list (le gente a volte tiene copie offline, per esempio da usare su un laptop in viaggio) per identificare senza ambiguità i messaggio giusto anche se non ha l'accesso agli archivi. Il mittente e il soggetto non sarebbero sufficienti, per che la stessa persona potrebbe fare parecchi post nello stesso trhead, anche nello stesso giorno.

Più il progetto cresce, più importante diventa questo tipo di coerenza. Coerenza significa che qualunque persona guardi, essa vede seguiti gli stessi comportamenti, così essi sanno seguire i comportamenti stessi. Questo, successivamente, riduce il numero di domande che essi hanno bisogno di di fare. Il carico di avere milioni di lettori non è più grande di quello di averne uno; i problemi di scalabilità cominciano a sorgere quando un a certe percentuale di di quei lettori fa domande. Nella misura in cui il progetto cresce, esso deve ridurre quella percentuale aumentando la densità e l'accessibilità dell'informazione, in modo che la persona in grado di trovare ciò di cui ha bisogno senza dover chiedere.

Gestire le vulnerabilità della sicurezza è differente dal gestire ogni altro tipo di report di bug. Nel software libero, fare le cose apertamente e con trasparenza è normale quasi come un credo religioso. Ogni passo della gestione standard dei bug è visibile a tutti quelli che hanno la cura di di guardare: l'arrivo del report iniziale, la conseguente discussione, e l'eventuale correzione.

I bug della sicurezza sono differenti. Essi possono compromettere i dati degli utenti, e magari l'intero computer dell'utente. Per discutere apertamente un tale problema si dovrebbe avvisare della sua esistenza il mondo intero—incluse tutte le parti che potrebbero fare un uso maligno del bug. Anche solo facendo l'invio della correzione in effetti dà l'annuncio dell'esistenza del bug (ci sono persone potenziali che sferrano gli attacchi che guardano i log degli invii dei progetti pubblici, sistematicamente alla ricerca di cambiamenti che indicano problemi di sicurezza nel codice di pre cambiamento). Molti progetti open source hanno fissato lo stesso gruppo di passi per gestire questo conflitto fra l'essere aperti e la segretezza, basati su queste linee guida:

In pratica questi principi portano a una serie di passi molto standardizzati che sono descritti nella sezione sotto.

DA: Qui il Vostro Nome
To: admin@large-famous-server.com
Risposta a: Qui in Vosto Nome (non l'indirizzo della mailing list sulla sicurezza)
Oggetto: Notifica confidenziale della vulnerabilità di Scanley.


Questa email è una una notifica confidenziale di una allarme nel server di Scanley.

Prego *non inoltrare* nessuna parte di questa email ad alcuno. Non c'è annuncio fino al 19 Maggio e noi gradiremmo tenere questa informazione bloccata fino ad allora.

State ricevendo questa email perché (noi pensiamo) che voi facciate girare un server Scanley e vorreste averlo sistemato prima che il buco nella sicurezza venga reso pubblico il 19 Maggio.

Riferimenti:
===========

   CAN-2004-1771: Sovraccarico dello stack di Scanley nelle query

Vulnerabilità:
==============

Il server può essere messo nelle condizioni di eseguire comandi arbitrari se il locale del server è mal configurato e il client invia una query mal formata.

Serietà:
=========

   Molto seria. Può comportare l'arbitraria esecuzioni di codice sul server.

Soluzioni:
============

   Il mettere l'opzione del 'processo del linguaggio naturale' a 'off' in scanley.conf blocca questa vulnerabilità

Patch:
======

   La patch di sotto si applica a Scanley 3.0, 3.1, e 3.2.

Una nuova release (la Scanley 3.2.1) verrà creata il o appena prima del 19 Maggio, in modo che sia disponibile nello stesso momento in cui questa vulnerabilità è resa pubblica. Potete sistemare adesso, o appunto aspettare la release pubblica. L'unica differenza fra  la 3.2 e la 3.2.1 sarà questa patch.

[...la patch va qui...]

Questa sezione descrive le convenzioni formali della numerazione delle releases, e presuppone, una piccola precedente conoscenza. Se già avete familiarità con queste convenzioni, potete saltare questa sezione.

I numeri delle releases son gruppi di cifre separate da punti:

...e così via. I punti non ono punti decimali, essi sono solamente separatori; "5.3.9" sarebbe seguito da "5.3.10". Pochi progetti hanno fatto intendere diversamente, il più famoso il kernel Linux con la sua sequenza "0.95", "0.96"... "0.99" leading up to Linux 1.0, ma la convenzione che i punti non sono decimali è fermamente stabilita e deve essere considerato uno standard. Non c'è un limite al numero dei componenti (parti di cifre non contenenti il punto), ma la maggior parte dei progetti non va oltre tre o quattro. La ragione diventerà chiara avanti.

In aggiunta a componenti numerici i progetti a volte aggiungono un'etichetta descrittiva tipo “Alpha” o “Beta” (vedere Alpha e Beta), per esempio:

Un qualificatore Alpha o Beta significa che quella release precedeuna futura release che avrà lo stesso numero senza il qualificatore Così, "2.3.0 (Alpha)" porta alla fine a "2.3.0". Per far entrare queste release candidate in una riga, gli stessi qualificatori posso avere dei meta-qualificatori. Per esempio qui c'è una serie di releases che sarebbero rese disponibili al pubblico:

Notate che quando essa ha il qualificatore “Alpha” Scanley "2.3" si scrive "2.3.0". I due numeri sono equivalenti—tutti i componenti 0 seguenti possono sempre essere eliminati per brevità ma quando un qualificatore è presente, la brevità smette di esistere comunque, come pure uno potrebbe scegliere la completezza invece.

Altri qualificatori semi regolari usano includere “Stabile”, “Instabile”, “Sviluppo” e “RC” (per “Release Candidate”). Le più largamente usate sono comunque "Alpha" e "Beta", con “RC” che concorre da vicino per il terzo posto, ma notate che “RC” include sempre un meta-qualificatore numerico. Cioè non rilasciate "Scanley 2.3.0 (RC)", voi rilasciate "Scanley 2.3.0 (RC 1)", seguita dalla RC2, etc.

Queste tre etichette “Alpha”, “Beta” e “RC” sono piuttosto largamente conosciute ora, e raccomando di non usare le altre, anche se a prima vista sembrano scelte migliori perché sono parole normali, non gergo. Ma la gente che installa software da release ha già familiarità con quelle tre, è non c'è motivo per fare cose gratuitamente in modo differente dal modo in cui chiunque altro le fa.

Sebbene i punti nei numeri delle realases non siano punti decimali, indicano un significato del valore della posizione. Tutte le realeases "0.X.Y" precedono la "1.0" (che è equivalente alla “1.0.0”, certo). La"3.14.158" precede immediatamente la "3.14.159" e non immediatamente precede la "3.14.160" come la "3.15.qualcosa", e così via.

Una politica di numerazione delle releases rende capace l'utilizzatore di di guardare ai numeri di rilascio per lo stesso pezzo di software e dire, proprio dai numeri, le importanti differenze fra queste due relaeases. In un tripico sistema a tre componenti il primo componente è il numero maggiore, il secondo è il il secondo è il numero minore, il terzo è il micro numero. FPer esempio, la release "2.10.17" è la diciassettesima micro-relaese nella decima linea di release minore entro la seconda serie di release maggiore. Le parole “linea” e “serie” sono usate informalmente qui, ma significano ciò che uno si aspetterebbe. Una serie maggiore sono semplicemente tutte le releases che hanno in comune lo stesso numero maggiore, e una serie minore (o linea minore) sono semplicemente tutte le releases che hanno in comune lo stesso numero maggiore e lo stesso numero minore. Cioè la "2.4.0" e la "3.4.1" non si trovano nella stessa serie minore anche se ambedue hanno “4” come numero minore; d'altra parte la "2.4.0" e la "2.4.2" si trovano nella stessa linea minore, sebbene non siano adiacenti se la “2.4.1” è stata rilasciata fra di esse.

Il significato di questi numeri è esattamente ciò che vi aspettereste: un aumento del numero maggiore indica che il cambiamento maggiore è avvenuto; un cambiamento del numero minore indica che sono avvenuti cambiamenti minori, e un cambiamento del micro numero indica cambiamenti trascurabili. Alcuni progetti aggiungono un quarto componente, usualmente chiamato numero di patch, specialmente per un un controllo più fine sulle differenze fra le loro releases (in maniera disorientante, altri progetti usano “patch” come sinonimo di “micro” in un sistema. Ci sono anche progetti che usano un sistema a tre componenti). Ci sono anche progetti che usano l'ultimo componente come numero di fabbricazione, incrementato ogni volta che il software è costruito, e non rappresenta nessun cambiamento al di fuori dell'allestimento. Ciò aiuta il progetto a mettere in relazione ogni rapporto di bugs con uno specifico allestimento, ed è forse molto utile quando i pacchetti binari sono il metodo di distribuzione di default.

Sebbene ci siano molte differenti convenzioni su quanti componenti usare, e cosa significhino i componenti, le differenze tendono a diventare piccole, voi tenete una piccola tolleranza, ma non troppo. Le prossime sue sezioni parlano delle due convenzioni più largamente usate.

La maggior parte dei progetti ha delle regole su che tipo di cambiamenti sono permessi nella release se uno sta incrementando solo il micro numero, differenti regole per il numero minore e ancora differenti regole per il numero maggiore. Non c'è uno standard stabilito per queste regole ancora, ma qui io descriverò una politica che è stata usata con successo da più di un progetto. Voi potete giusto adottare questa politica nei vostri porgetti, ma anche se non lo volete, questo è tuttavia un buon esempio del tipo di informazione che i numeri di release dovrebbero portare con sé. Questa politica è adattata dal sistema di numerazione usato dal progetto APR, vedere http://apr.apache.org/versioning.html.

Che significhi compatibile in avanti e compatibile all'indietro , esattamente, dipende da ciò che il vostro software fa, ma nel contesto, non sono aperte a tante interpretazioni. Per esempio, se il vostro software è una applicazione client/server, allora “compatibile all'indietro” significa che l'aggiornamento del server alla 2.6.0 non dovrebbe causare per i clients la perdita di funzionalità o comportamenti differenti da quelli di prima (eccetto per i bugs che sono stati corretti, certo). D'altra parte, l'aggiornamento di uno di quei clients alla 2.6.0 , insieme al server, potrebbe rendere disponibili nuove funzionalità per quel client, funzionalità di cui i client 2.5.4 non sanno come avvantaggiarsi. Se ciò avviene, l'aggiornamento non è “compatibile in avanti”: chiaramente non potete ora tornare indietro con quel client alla 2.5.4 e mantenere tutte le funzionalità che aveva nella 2.6.0, perché alcune di quelle funzionalità erano nuove nella 2.6.0.

Questo è il motivo per cui le micro releases sono essenzialmente per le correzioni dei bugs. Esse devono rimanere compatibili in entrambe le direzioni: se voi aggiornate dalla 2.5.3 alla 2.5.4, poi cambiate idea e tornate indietro alla 2.5.3, nessuna funzionalità dovrebbe andar perduta. Certo i bugs corretti riapparirebbero dopo il ritorno alla precedente versione, ma voi non perdereste nessuna funzionalità, eccetto per il fatto che i bugs reintrodotti impediscono l'uso di alcune funzionalità esistenti.

I protocolli client/server sono giusto uno dei campi dalle molte possibili compatibilità. Un' altra è la formattazione dei dati: il software scrive i dati in uno spazio permanente? Se così, i formati che legge devono seguire le leggi di compatibilità promesse dalla politica dei numeri di rilascio. La versione 2.6.0 deve poter leggere files scritti nella 2.5.4, ma può in silenzio aggiornare il formato a qualcosa che la 2.5.4 non può leggere, perché la possibilità di ritornare indietro non è un requisito della 2.6.0 per via delle delimitazioni riguardanti un numero minore. Se il vostro progetto distribuisce librerie di codice per l'impiego in altri programmi, allora le API sono anche un dominio di compatibilità: dovete essere sicuri che le regole di compatibilità per il sorgente e il binario siano dette in maniera tale che l'utilizzatore informato non debba mai chiedersi se è sicuro e opportuno aggiornare o no. Egli deve essere capace di guardare i numeri è e saperlo istantaneamente.

In questo sistema voi non avete una chance per una fresca partenza finché non incrementate il numero maggiore. Questo può essere spesso un reale inconveniente: ci possono essere funzionalità che voi volete aggiungere, o protocolli che volete ridisegnare, cose che non possono essere semplicemente fatte mentre mantenete la compatibilità. Non c'è una soluzione magica a questo, eccetto che cercare di disegnare le cose in modo estensibile in primo luogo (una argomento che facilmente merita il proprio libro, ma certamente fuori tema in questo). Ma pubblicare una politica di compatibilità delle releases, e aderirvi, è una parte delle distribuzione del software a cui non si può sfuggire. Una sgradevole sorpresa può allontanare un sacco di utilizzatori. La politica appunto descritta è buona in parte perché è già abbastanza diffusa, ma anche perché è facile da spiegare e da ricordare, anche per coloro che non hanno ancora familiarità con essa.

E' generalmente convenuto che queste regole non si applicano alle release pre-1.0 (sebbene la vostra politica di release lo stabilisca esplicitamente, giusto per essere chiari). Un progetto che sia ancora allo sviluppo iniziale può rilasciare la 0.1, 0.2, 0.3 e così via in sequenza, finché non sia pronto per la 1.0, e le differenze fra queste releases possono essere arbitrariamente grandi. I micro numeri nelle releases pre-1.0 sono opzionali. A seconda della natura del vostro progetto e delle differenze fra le releases potreste trovare utile avere la 0.1.0, la 0.1.1. ecc.., oppure no. Le convenzioni per le releases pre-1.0 sono piuttosto permissive, principalmente perché la gente capisce che forti costrizioni di compatibilità intralcerebbero molto il primo sviluppo, e anche perché i primi che le adottano tendono ad essere indulgenti comunque.

Ricordate che tutte queste ingiunzioni si applicano a questo sistema a tre componenti. Il vostro progetto potrebbe venir su con un differente sistema a tre componenti, oppure potrebbe decidere di non avere bisogno di un così fine granulosità e usare invece un sistema a due componenti. La cosa importante è deciderlo per tempo, rendere pubblico ciò che i componenti significano, e aderire ad essi.

Alcuni progetti usano la parità del componente numero minore per indicare la stabilità del software. Pari significa stabile, dispari significa instabile. Ciò si applica solo al numero minore, non al numero maggiore a al micro numero. Incrementi nel micro numero ancora significano correzioni di bug (non nuove funzionalità), e incrementi nel numero maggiore ancora indicano grossi cambiamenti, nuovi set di funzionalità, ecc..

Il vantaggio del sistema pari/dispari, che è stato usato dal progetto kernel di Linux fra gli altri, è che offre una via per rilasciare nuove funzionalità per la fase di prova, senza costringere gli utilizzatori della produzione a un codice potenzialmente instabile. Le persone possono vedere dai numeri che la "2.4.21" va bene per l'installazione sul loro attivo web server, ma che la "2.5.1" dovrebbe essere usata solamente per esperimenti sulle work station. Il team di sviluppo gestisce i report di bugs che arrivano dalla serie minore (numerata dispari), e quando le cose incominciano a sistemarsi dopo un certo numero di micro releases in quella serie, incrementano il numero minore (così facendolo diventare pari), riportano il micro numero a “0”, e rilasciano il pacchetto presumibilmente stabile.

Questo sistema conserva, o almeno non va in conflitto con le linee guida date prima. Esso semplicemente carica ulteriormente il numero minore di qualche extra informazione. Questo costringe d'altronde il numero minore ad essere incrementato di circa due volte tanto spesso quanto sarebbe necessario, ma non c'è un gran male in ciò. Il sistema pari dispari è probabilmente il migliore per i progetti che hanno cicli di release molto lunghi, e che per loro natura hanno una grande fetta di utilizzatori conservatori che valutano la stabilità al di sopra delle nuove funzionalità. Questo comunque non è il solo modo di fare il test di nuove funzionalità allo stato selvaggio, comunque. sezione chiamata «Stabilizzare una Release» Più avanti in questo capitolo si descrive un altro, forse più comune, metodo di rilasciare al pubblico codice potenzialmente instabile, contrassegnato in modo che le persona abbiano un'idea del compromesso rischio/beneficio vedendo il nome della release.

L'esatto meccanismo della creazione di un ramo di release dipende dal vostro sistema di controllo della versione, certo, ma i concetti generali sono gli stessi nella maggior parte dei sistemi. Un ramo usualmente vien fuori da un altro ramo o dal tronco. Tradizionalmente, il tronco è dove si ha la linea principale dello sviluppo, libera dai vincoli della release. Il primo ramo della release, quello che porta alla release “1.0”, vien fuori dal tronco. Nel CVS il comando di ramo sarebbe qualcosa come

$ cd trunk-working-copy
$ cvs tag -b RELEASE_1_0_X

o in Subversion, come questo:

$ svn copy http://.../repos/trunk http://.../repos/branches/1.0.x

(Tutti questi esempi accettano il sistema di numerazione a tre componenti. Mentre non posso mostrare i comandi per ogni sistema di controllo della versione, farò degli esempi in CVS e Subversion e spero che i corrispondenti comandi in altri sistemi possano essere dedotti da questi due.)

Notare che noi creammo il ramo "1.0.x" (con una lettera "x") invece di "1.0.0". Questo perché la stessa linea minore cioè lo stesso ramo—sarebbe stato usato per le micro releases in quella linea. Il reale processo di stabilizzazione dei rami è trattato sezione chiamata «Stabilizzare una Release» più avanti in questo capitolo. Qui noi ci occupiamo appunto dell'interazione fra il sistema di controllo della versione con il processo di release. Quando il ramo di release è stabilizzato e pronto, è il momento di tracciare una fotografia del ramo:

$ cd RELEASE_1_0_X-working-copy
$ cvs tag RELEASE_1_0_0

or

$ svn copy http://.../repos/branches/1.0.x http://.../repos/tags/1.0.0

Questa traccia ora rappresenta lo stato esatto dell'albero origine nella release 1.0.0 (ciò è utile nel caso che qualcuno abbia bisogno di prelevare una vecchia versione dopo che distribuzioni confezionate e i binari siano stati dismessi). La successiva micro release nella stessa linea è preparata nello steso modo nel ramo 1.0.x, e quando è pronta, una traccia è fatta per la 1.0.1. Più avanti, risciacquatura, si ripete con la 1.0.2, e così via. Quando è il tempo di partire pensando alla release 1.1.x, create un nuovo ramo dal tronco:

$ cd trunk-working-copy
$ cvs tag -b RELEASE_1_1_X

or

$ svn copy http://.../repos/trunk http://.../repos/branches/1.1.x

Il mantenimento può continuare in parallelo lungo la 1.0.x e la 1.1.x e un rilascio può essere fatto indipendentemente da ambedue le differenti linee. La vecchia serie è raccomandata per gli amministratori di sito più conservatori che possono non voler fare il grosso salto alla (diciamo) 1.1 senza una attenta preparazione. Intanto, persone più avventurose prendono la più recente release sulla linea più alta, per essere sicuri di fare proprie le più recenti funzionalità, anche a rischio di una piuttosto grande instabilità.

Il gruppo conviene di permettere a una persona di essere proprietario della release. Questo proprietario ha la parola finale sui cambiamenti che devono entrare nella release. Certo, ci si aspetterebbe ed è normale che ci siano discussioni e argomentazioni, ma alla fine il gruppo deve assegnare al proprietario la sufficiente autorità per prendere le decisioni finali. Affinché questo sistema funzioni, è necessario scegliere una persona con la competenza tecnica per comprendere tutti i cambiamenti e la posizione sociale e le capacità di navigare fra le discussioni puntando alla release senza causare tanti sensi di risentimento.

Un comportamento comune del proprietario è dire “non penso che ci sia qualcosa di sbagliato in questo cambiamento, ma non abbiamo avuto abbastanza tempo per provarlo, per cui non deve entrare nelle release”. Ciò aiuta molto se il proprietario della release ha larghe conoscenze tecniche del progetto, e ha la capacità di rendere conto del perché il cambiamento potrebbe esser potenzialmente destabilizzante (per esempio la sua interazione con altre parti del software, o questioni di portabilità). La gente potrà a volte chiedere che tali decisioni siano giustificate o sostenere che il cambiamento non è un rischio come sembra. Queste conversazioni non devono essere provocatorie, nella misura in cui il proprietario della release è capace di prendere in considerazione tutte le argomentazioni obbiettivamente e non come un colpo alle sue gambe

Notate che non è necessario che il proprietario della release sia la stessa persona del leader del progetto (nei casi in cui c'è un leader del progetto; vedere sezione chiamata «I Dittatori Benevoli» in Capitolo 4, L'Infrastruttura Sociale e Politica). Infatti a volte è bene assicurarsi che non siano la stessa persona. Le capacità che fanno un buon leader di sviluppo non sono necessariamente le stesse che fanno un buon proprietario di release. In una cosa così importante come il processo di release, può essere saggio avere qualcuno che controbilanci il giudizio del leader di progetto.

Contrastate il ruolo del proprietario di release con un un ruolo meno dittatoriale descritto in sezione chiamata «Il manager di release» più avanti in questo capitolo.

All'estremo opposto della dittatura da parte del proprietario di release, gli sviluppatori possono semplicemente votare su quali cambiamenti includere nella release. Comunque, poichè la funzione più importante per la stabilizzazione delle release è escludere cambiamenti, è importante creare un sistema di voto in modo tale che fare cambiamenti alla release comporti una azione positiva da parte di più di uno sviluppatore. Per inserire un cambiamento ci dovrebbe essere bisogno più di una semplice maggioranza (vedere sezione chiamata «Chi Vota?» in Capitolo 4, L'Infrastruttura Sociale e Politica). Diversamente un voto a favore e uno contro un dato cambiamento sarebbe sufficiente per inserirlo nella release e si creerebbe una sciagurata dinamica per cui ciascuno sviluppatore voterebbe per i propri cambiamenti, mentre sarebbe riluttante a votare contro i cambiamenti degli altri, per paura di possibili ritorsioni. Per evitare ciò, il sistema dovrebbe essere congegnato in modo che sottogruppi di sviluppatori debbano agire in cooperazione per inserire cambiamenti nella release. Ciò significa non solo che più persone revisionano ogni cambiamento, ma rende uno sviluppatore individuale meno indeciso nel votare contro un cambiamento, perché egli sa che nessuno in particolare fra quelli che votarono per esso può prendere il suo voto contro come un affronto personale. Più grande è il numero di persone coinvolte, più numerose diventano le discussioni sui cambiamenti e meno numerose quelle sugli individui.

Il sistema che noi usiamo nel progetto Subversion sembra aver centrato un buon bilanciamento, per cui io lo raccomando qui. Affinché un cambiamento sia apportato a un ramo di release, almeno tre sviluppatori devono votare a favore di esso, e nessuno contro. Un singolo voto “no” è sufficiente a impedire che il cambiamento sia incluso; cioè un voto “no” in un contesto di release è equivalente a un veto (vedere sezione chiamata «I Veti»). Naturalmente ogni voto di questo tipo deve essere accompagnato da una giustificazione, e in teoria si potrebbe non tener conto del veto, se abbastanza gente ritenesse che esso è non ragionevole e obbliga a un voto speciale su di esso. In pratica, ciò non è mai successo, e prevedo che non succederà mai. Le persone sono conservatrici nei confronti delle release in ogni modo, e quando qualcuno si sente abbastanza fortemente a favore del veto nei confronti dell'inclusione di una cambiamento, c'è usualmente una buona ragione per ciò.

Poiché la procedura di rilascio è deliberatamente orientata verso il conservatorismo, le giustificazioni portate per il veto sono talvolta procedurali piuttosto che tecniche. Per esempio, una persona può ritenere che un cambiamento sia ben scritto e che sia improbabile che causi nuovi bugs, ma vota contro la sua inclusione nella micro release semplicemente perché è troppo grossa magari apporta nuove funzionalità, o in qualche modo sottile non riesce a seguire completamente le linee guida di compatibilità. Io occasionalmente ho visto anche sviluppatori porre il veto a qualcosa semplicemente perché avevano una sensazione viscerale che il cambiamento avesse bisogno di ulteriori prove, anche se essi non potevano individuare bugs in esse con un esame interno. Le persone si lagnavano un poco, ma il veto resisteva e il cambiamento non veniva incluso nella release (non ricordo se qualche bug veniva trovato o no in una ulteriore prova, comunque).

* r2401 (issue #49)
  Prevent client/server handshake from happening twice.
  Justification:
    Avoids extra network turnaround; small change and easy to review.
  Note:
    Ciò fu discusso in http://.../mailing-lists/message-7777.html
    e altrimessaggi in quel thread.
  Voti:
    +1: jsmith, kimf
    -1: tmartin (breaks compatibility with some pre-1.0 servers;
                 admittedly, those servers are buggy, but why be
                 incompatible if we don't have to?)

* r13222, r13223, r13232
  Riscrive libsvn_fs_fs's auto-merge algorithm
  Giustificazione:
    unacceptable performance (>50 minutes for a small commit) in
    a repository with 300,000 revisions
  Ramo:
    1.1.x-r13222@13517
  Voti:
    +1: epg, ghudson

Il codice sorgente dovrebbe essere inviato in formati standard per trasportare alberi di directory. Per i sistemi operativi Unix e pseudo Unix, la convenzione è usare il formato TAR, compresso da compress, gzip, bzip o bzip2 che sembra fare la compressione anche bene, in modo che non c'è bisogno di comprimere l'archivio dopo averlo creato.

Il nome del pacchetto dovrebbe consistere nel nome del software, più il numero di release, più il suffisso di formato per il tipo di archivio. Per esempio, Scanley 2.5.0, impacchettato per Unix che usa la compressione GNU Zip (gzip), apparirebbe come questo:

o per Windows che usa la compressione zip:

Ciascuno di questi archivi, quando è estratto, dovrebbe creare un unico albero di directory chiamato scanley-2.5.0 nella directory corrente. Sotto la nuova directory, il codice sorgente dovrebbe essere sistemato in una disposizione pronta per la compilazione (se c'è bisogno di compilazione) e per l'installazione. Nel livello più alto dell'albero delle directory ci dovrebbe essere un file di testo piano README che spieghi ciò che il software fa e quale release è, e che dà le indicazioni per altre risorse, come il sito del progetto, altri file di interesse, ecc.. Fra questi altri files ci dovrebbe essere un file fratello INSTALL del file README che dia istruzione su come costruire e installare il software per tutti i sistemi operativi che supporta. Come menzionato in sezione chiamata «Come Applicare Una Licenza Al Vostro Software» in Capitolo 2, Partenza, ci dovrebbe essere anche un file COPYING or LICENSE che fornisca i termini di distribuzione.

Ci dovrebbe essere anche un file CHANGES (a volte chiamato NEWS), che spieghi ciò che c'è di nuovo in quella release. Il file CHANGES accumula le liste dei cambiamenti per tutte le releases, in ordine cronologico inverso, in modo che la lista per quella release appaia in cima al file. A completare la lista c'è usualmente l'ultima cosa fatta per stabilizzare il ramo di release; alcuni progetti scrivono la lista un pò alla volta mentre si sviluppano, altri preferiscono salvarla alla fine di tutto, e hanno una persona a scriverla, che prende le informazioni setacciando i log del controllo di versione. La lista appare come qualcosa del genere:

Version 2.5.0
(20 December 2004, da /rami/2.5.x)
http://svn.scanley.org/repos/svn/tags/2.5.0/

 New features, enhancements:
    * Added regular expression queries (issue #53)
    * Added support for UTF-8 and UTF-16 documents
    * Documentation translated into Polish, Russian, Malagasy
    * ...

 Bugfixes:
    * fixed reindexing bug (issue #945)
    * fixed some query bugs (issues #815, #1007, #1008)
    * ...

L'elenco può facilmente essere tanto lungo quanto è necessario, ma non vi preoccupate di includere ogni piccola correzione di bug e accrescimento di funzionalità. Il suo proposito è solamente dare agli utilizzatori una visione d'insieme di quale sarebbe il guadagno ad aggiornare alla nuova release. Infatti, la lista dei cambiamenti è abitualmente inclusa nelle email di annuncio (vedere sezione chiamata «Prove e Rilascio» più avanti in questo capitolo), in modo che la scriviate con il pubblico nella mente.

Usualmente ci sono poche differenze, per esempio perché il pacchetto contiene alcuni file generati necessari per la compilazione e la configurazione (vedere sezione chiamata «Compilazione e Installazione» più avanti in questo capitolo), o perché contiene un software di terze parti di cui il progetto non fa manutenzione, ma ciò è richiesto e ciò è probabile che gli utilizzatori non abbiano. Ma anche se l'albero distribuito corrispondesse esattamente ad alcuni alberi di sviluppo nel deposito del controllo di versione, la distribuzione stessa non sarebbe un copia funzionante (vedere copia di lavoro). Si suppone che la release un punto di riferimento statico una particolare, immutabile configurazione dei files sorgenti. Se essa fosse una copia funzionante, il danno sarebbe che gli utilizzatori potrebbero aggiornarla, e successivamente pensare di avere ancora la release quando nei fatti egli ha qualcosa di differente.

Ricordate che il pacchetto è lo stesso indipendentemente dalla confezione. La release cioè la precisa entità riferita a quando qualcuno dice "Scanley 2.5.0"—è l'albero creato estraendo un file zip o tar. Così il progetto potrebbe offrire tutti questi per il download:

...ma l'albero sorgente estraendoli deve essere lo stesso. Quell'albero sorgente è la distribuzione.; la forma in cui è scaricato è un pura questione di convenienza. Certe differenze secondarie fra i pacchetti sorgente sono ammissibili: per esempio, nel pacchetto Windows i file di testo devono avere un fine linea con CRLF (Carriage Return and Line Feed), mentre il pacchetto Unix deve usare giusto LF. Gli alberi possono essere sistemati in maniera poco differente fra i pacchetti destinati a sistemi operativi differenti, anche, se questi sistemi operativi richiedono diversi tipi sistemazione per la compilazione. Comunque, queste sono di base le tutte le trasformazioni secondarie. I file sorgenti di base devono essere gli stessi nell'impacchettamento di una data release.

Per software che richiede compilazione e installazione dal sorgente, si sono usualmente delle procedure standard che si presume gli utilizzatoti esperti siano capaci di seguire. Per esempio, per programmi scritti in C, C++, o certi altri linguaggi compilati, lo standard per sistemi tipo Unix e che l'utilizzatore batta:

   $ ./configure
   $ make
   # make install

Il primo comando individua come sa l'ambiente e prepara il processo di allestimento (ma non installa), e il secondo comando installa sul sistema. I primi due comandi sono impartiti come utente normale, il terzo come radice. Per maggiori dettagli su come settare il sistema, vedere l'eccellente libro GNU Autoconf, Automake, and Libtool di Vaughan, Elliston, Tromey, e Taylor. Esso è pubblicato su carta da New Riders, e il suo contenuto è anche disponibile in forma freeware online a http://sources.redhat.com/autobook/.

Questo non è il solo standard, sebbene sia uno dei più diffusi. Il sistema di allestimento Ant (http://ant.apache.org/) sta guadagnando popolarità, specialmente con progetti scritti in Java, ed ha le sue proprie procedure standard per l'allestimento e l'installazione. Inoltre, certi linguaggi di programmazione come Perù e Pathos, raccomandano che, per la maggioranza del programmi scritti in quel linguaggio sia usato lo stesso metodo (per esempio moduli Perl usano il comando perl Makefile.PL). Se non è ovvio per voi quale debba essere lo standard applicabile per il vostro progetto, chiedete a uno sviluppatore esperto; potete con sicurezza accettare che qualche standard si applica, anche se non sapete quale venga prima.

Quale che sia lo standard adatto per il vostro progetto, non deviate da esso a meno che non dobbiate certamente farlo. Le procedure standard per l'installazione sono in pratica dei responsi automatici a stimoli specifici per un sacco di amministratori di sistema attualmente. Se essi vedono richieste di aiuto be note documentate nel file, ciò istantaneamente genera in essi la credenza che il vostro progetto è generalmente fuori dalle convenzioni, e anche che sarebbe riuscito bene in altre cose. Anche, come discusso in sezione chiamata «Downloads» in Capitolo 2, Partenza, avere una procedura standard di allestimento piace ai potenziali sviluppatori.

Su Windows gli standards per l'allestimento e per l'installazione sono un po' meno fissi. Per progetti che richiedono la compilazione, la convenzione generale sembra essere inviare un albero che si può sistemare in un modello di area di lavoro/progetto dell'ambiente di sviluppo standard di Microsoft (Developer Studio, Visual Studio, VS.NET, MSVC++, ecc...). A seconda della natura del vostro software, può essere possibile offrire una opzione di allestimento su Windows via ambiente Cygwin. (http://www.cygwin.com/) E certamente, se state usando un linguaggio o un framework di programmazione che viene con le sue convenzioni di allestimento e installazione, per esempio Phiton o Perl dovreste semplicemente usare quello che sia il metodo standard per quel framework, su Windows, Unix, Mac OS X, o ogni altro sistema operativo.

Siate disponibili a metterci un sacco di impegno extra per rendere il vostro progetto conforme agli standards di rilievo per l'allestimento e l'installazione. L'allestimento e l'installazione sono una fase di ingresso: è giusto che le cose diventino più difficili dopo di essi, se è fuori discussione che lo siano, ma sarebbe un disonore nei confronti degli utilizzatori o degli sviluppatori se la prima interazione col software richiedesse passi imprevisti.

Sebbene la release formale sia un pacchetto di codice sorgente, la maggior parte degli utilizzatori installeranno da pacchetti binari, sia che siano forniti dal meccanismo di distribuzione del software del sistema operativo, sia che siano ottenuti manualmente dal sito del progetto o da terze parti. Qui “binario” non significa necessariamente “compilato”; significa giusto una forma pre-configurata del pacchetto che permette a un utilizzatore di installarla sul proprio computer senza passare attraverso le solite procedure di allestimento e installazione. Su RedHat GNU/Linux, è il sistema RPM; su Debian GNU/Linux, È il sistema APT (.deb); su Windows, di solito i files .MSI il file autoistallante .exe.

Se il file binario sia assemblato da gente strettamente associate al progetto, o da distanti terze parti, gli utilizzatori tendono a considerarli equivalenti alle releases ufficiali del progetto, e depositeranno i problemi nel tracciatore di bug apposito per il comportamento dei pacchetti binari. Quindi, è nell'interesse del progetto fornire pacchetti con chiare linee guida, e lavorare moltissimo con esse per assicurarsi che quello che producono rappresenti il software in modo pulito e accurato.

La cosa principale che gli impacchettatori hanno bisogno di sapere è che essi dovrebbero basare sempre i loro pacchetti binari su una release ufficiale originale. Talvolta gli impacchettatori son tentati di tirar fuori una recente incarnazione del codice dal deposito, o di includervi cambiamenti selezionati che furono inviati dopo che la release fu fatta, per fornirli agli utilizzatori con certe correzioni di bugs o altri miglioramenti. Chi fa i pacchetti pensa di star facendo un favore ai suoi utilizzatori nel dare loro codice più recente, ma in realtà questa pratica causa una gran quantità di confusione. I progetti sono preparati a ricevere rapporti di bugs trovati nelle versioni rilasciate, e di bugs trovati nel recente tronco e nel codice del ramo maggiore (cioè trovati da gente lì apposta per far girare codice a rischio di stabilità e produttività). Quando un bug proviene da queste fonti, il risponditore sarà spesso capace di confermare che è noto che quel bug è presente in quell'istantanea, e forse che da allora è stato corretto e che l'utente dovrebbe aggiornare o aspettare la successiva release. Se esso è un precedente bug non noto, l'avere l'esatta release fa si che sia più facile riprodurlo e più facile classificarlo nel tracciatore.

progetti non sono preparati, comunque, a ricevere rapporti di bugs basati su un mezzo intermedio non specifico o su versioni ibride. Tali bugs possono essere difficili da riprodurre; inoltre possono essere dovuti a interazioni non previste in cambiamenti isolati introdotti da successivi sviluppi, quindi causano cattivi comportamenti di cui gli sviluppatori del progetto non dovrebbero essere incolpati. Ho visto una sconcertante gran quantità di tempo sprecata perché un bug era absent quando avrebbe dovuto essere presente: qualcuno stava facendo girare una versione leggermente modificata, basata (ma non identica) su una release ufficiale, e quando i bug predetto non si verificava ognuno doveva scavare un fossato per capire il perché.

Tuttavia quelle erano circostanze in cui chi faceva il pacchetto insisteva sul fatto che quelle modifiche alla release originale erano necessarie. Chi faceva i pacchetti avrebbe dovuto essere incoraggiato a tirar fuori questo con gli sviluppatori del progetto e a spiegare i suoi piani. Essi possono trovare consenso, ma mancando questo, almeno avranno notificato al progetto le loro intenzioni, così che il progetto può stare attento a insoliti rapporti di bugs. Gli sviluppatori possono rispondere mettendo un disclaimer sul sito del progetto, e possono chiedere a chi fa i pacchetti di fare la stessa cosa nel posto appropriato, di modo che gli utilizzatori di quel pacchetto binario sappiano che ciò che stanno prendendo non è esattamente la stessa cosa di ciò che il progetto ha rilasciato. Non ci deve essere animosità in questa situazione, sebbene purtroppo spesso ce ne sia. E' solo che chi fa i pacchetti ha degli obiettivi leggermente differenti da quelli degli sviluppatori. Coloro che fanno i pacchetti vogliono che i loro utilizzatori incontrino le migliori funzionalità. Gli sviluppatori vogliono anche questo, certo, ma hanno anche bisogno di essere sicuri di conoscere quali versioni del software ci sono in giro, in modo da poter ricevere rapporti di bugs intellegibili e garantire compatibilità. A volte i loro obiettivi sono in conflitto. Quando ciò avviene è bene avere in mente il fatto che il progetto non ha nessun controllo su coloro che fanno i pacchetti e che i vincoli degli obblighi funzionano in entrambe le direzioni. E' vero che il progetto sta facendo un favore a chi fa i pacchetti semplicemente producendo il software. Ma anche quelli che fanno i pacchetti stanno facendo un favore al progetto e si stanno accollando un lavoro non eccitante per rendere il software più largamente disponibile, spesso per ordine di rilievo. E' bene non essere d'accordo con gli impacchettatori, ma non è bene offenderli. Giusto cercate una soluzione alle cose meglio che potete.

Per le releases importanti contenenti molti cambiamenti, molti progetti preferiscono metter fuori le release candidates prima, cioè, scanley-2.5.0-beta1 prima della scanley-2.5.0. Lo scopo di una candidate è quello di sottoporre a una estesa fase di testing prima di darle il benelacito di release ufficiale. Se si trovano problemi, essi vengono corretti un ramo di release ed viene esibita una nuova candidate release. (scanley-2.5.0-beta2). Il ciclo continua finché non sono rimasti più bugs inaccettabili, punto nel quale l'ultima release candidate diventa la release ufficiale, cioè l'unica differenza fra la release candidate e la release reale è la rimozione del qualificatore dal numero di versione.

Sotto moltissimi aspetti, una candidate release deve essere considerata allo stesso modo di una vera release. Il qualificatore alpha, beta, o rc è sufficiente a mettere in guardia gli utilizzatori conservatori dall'aspettare fino alla vera release, e certamente le email di annuncio delle candidate releases dovrebbero mettere in evidenza che il loro scopo è quello di sollecitare reazioni. Tranne questo date alle candidate release la stessa quantità di attenzione che date alle normali release. Dopotutto, voi volete che la gente usi le candidates, a causa della esposizione migliore per scoprire bugs non scoperti, e anche perché voi non sapete mai quale candidate si conclude dando inizio alla release ufficiale.

Annunciare una release è come annunciare ogni altro evento, e dovrebbe usare le procedure descritte in sezione chiamata «La Pubblicità» in Capitolo 6, Comunicazione. Ci sono tuttavia poche nuove cose specifiche da fare.

Ogni volta che date l'URL al tar scaricabile della release, assicuratevi di dare anche la somma di controllo MD5/SHA1 e i puntatori al file delle firma digitali. Poiché gli annunci avvengono in molte tribune (mailing lists, pagine di news, ecc..), ciò significa che gli utilizzatori possono prendere le somme di controllo da molte fonti, il che dà ai titubanti sulla sicurezza una assicurazione extra che le somme di controllo stesse non sono state corrotte. Dare il link al file delle firme digitali molte volte non rende queste firme digitali più sicure, ma rassicura la gente (specialmente quelli che non seguono il progetto da vicino) che il progetto prende la sicurezza seriamente.

Nelle email di annuncio, e sulle pagine di news che contengono più che una semplice fascetta pubblicitaria sulla release, assicuratevi di inserire la porzione rilevante del file CAMBIAMENTI, così la gente può vedere perché dovrebbe essere loro interesse aggiornare. Ciò è importante sia con le candidate releases sia con le releases finali; la presenza di correzioni di bug e di nuove funzionalità è importante nel tentare la gente a provare una candidate release.

Infine, non dimenticate di ringraziare il team di sviluppo, quelli che hanno fatto i tests, e tutti quelli che hanno dedicato tempo ad archiviare buoni report di bugs. Non distinguerteli per nome, comunque, a meno che non ci sia qualcuno responsabile di una grossa parte del lavoro, il valore del quale sia riconosciuto da ognuno nel progetto. Giusto stiate attenti a non scivolar giù con la tendenza scivolosa all'inflazione dei riconoscimenti(vedere sezione chiamata «Riconoscimenti» in Capitolo 8, Gestire i Volontari).

La maggior parte dei dettagli sulla gestione dei bug sulla sicurezza era trattata in sezione chiamata «Annunciare le Vulnerabilità della Sicurezza» in Capitolo 6, Comunicazione, ma lì ci sono dettagli specifici per creare releases di sicurezza.

Una release di sicurezza è una release fatta solo per chiudere falle nella sicurezza. Il codice che corregge i bugs non può essere reso pubblico finché la release non è disponibile, il che significa non solo che i bugs non possono essere inviati al deposito fino al giorno della release, ma anche che la release non può essere testata pubblicamente prima che esca. Ovviamente gli sviluppatori possono esaminare i bugs fra di loro, e testare la release in privato, ma la diffusione nel mondo del testing reale non è possibile.

A causa di questa mancanza di testing, una release sulla sicurezza dovrebbe sempre essere fatta di alcune releases esistenti più le correzioni dei bugs di sicurezza, con nessun altro cambiamento. Questo perché più cambiamenti inviate senza testing, più probabilmente quell'unico fra essi causerà un nuovo bug, forse un nuovo bug di sicurezza. La prudenza è anche di famiglia per gli amministratori che possono aver bisogno di aprire le correzioni sulla sicurezza, ma la cui politica di aggiornamento preferisce di non aprire nessun altro cambiamento nello stesso tempo.

Il creare una release di sicurezza a volte comporta qualche inganno minore. Per esempio il progetto può aver lavorato alla release 1.1.3, con certe correzioni di bugs già pubblicamente dichiarate, quando arriva un report di bugs. Naturalmente gli sviluppatori non possono parlare di problemi si sicurezza fino a quando non rendono disponibile la correzione. Fino ad allora essi devono continuare a parlare pubblicamente come se la 1.1.3 sarà ciò che si è sempre pianificato che sia. Ma quando la 1.1.3 finalmente esce, differirà dalla 1.1.2 solo per le correzioni dei bugs sulla sicurezza, e tutte le altre correzioni saranno state rinviate alla 1.1.4 (che certamente ora conterrà anche le correzioni sulla sicurezza, come le conterranno tutte le releases future).

Potreste aggiungere un componente extra in una release esistente per indicare che essa contiene solo cambiamenti sulla sicurezza. Per esempio la gente dovrebbe saper dire, giusto dai numeri che la 1.1.2.1 è una release di sicurezza nei confronti della 1.1.2 e dovrebbero sapere che ogni release più “alta” di quella (per esempio, 1.1.3, 1.2.0, ecc...) contiene le stesse correzioni sula sicurezza. Per quelli ben informati, questo sistema porta un sacco di informazioni. D'altra parte, per quelli che non seguono il progetto da vicino, può essere causa di confusione vedere un numero di release a tre componenti la maggior parte delle volte con una release a quattro componenti inserita apparentemente a caso. La maggior parte dei progetti che ho visto scelgono la coerenza e semplicemente e scelgono il numero successivo regolarmente programmato per le releases di sicurezza, anche quando ciò significa far slittare di uno le altre releases programmate.

Un campo in cui i progetti open source si sono differenziati dai progetti proprietari è la pianificazione delle releases. I progetti proprietari di solito hanno scadenze più decise. A volte ciò avviene perché i clienti sono stati avvisati che un aggiornamento sarebbe disponibile per una certa data, perché c'è bisogno che la nuova release sia coordinata con altri impegni di marketing, o perché il capitalista che rischia, che ha investito in tutta la cosa ha bisogno di vedere alcuni risultati prima di mettervi dentro altri finanziamenti. I progetti open source, invece, erano fino a tempi recenti in gran parte motivati da dilettantismo nel senso più letterale: erano scritti per amore di essi. Nessuno sentiva il bisogno di inviare prima che tutte le funzionalità fossero pronte, e perché avrebbero dovuto? Non era incredibile che il lavoro di ognuno fosse senza indugi.

Al giorno d'oggi, molti progetti open source sono finanziati dalle compagnie, e sono di conseguenza influenzati dalla cultura della scadenza delle compagnie. Questo è sotto molti aspetti una buona cosa, ma può creare dei conflitti fra le priorità degli sviluppatori pagati e quelle di coloro che stanno offrendo volontariamente il loro tempo. Questi conflitti avvengono spesso sul come e quando programmare le releases. Gli sviluppatori salariati che sono sotto pressione vorranno naturalmente scegliere una data in cui avverrà la release e ottenere che l'attività di ognuno ci si allinei. Ma i volontari possono avere un'altra agenda forse funzionalità che vogliono completare o qualche prova che vogliono fare a riguardo —essi ritengono che la release dovrebbe aspettare.

Non c'è una soluzione che vada bene sempre a questo problema, tranne la discussione e il compromesso, certo. Ma potete rendere minimi la frequenza e i grado di attrito che si verifica, separando la vita che ci si ripropone per una data release dalla data in cui deve uscire. Cioè, cercare di indirizzare la discussione verso l'argomento di quali releases il progetto sta creando nel futuro a medio termine, e su quali funzionalità ci saranno in esse, senza prima fare nessuna menzione delle date, eccetto che approssimative congetture con largo margine di errore.^[21]. Fissando prima gli insiemi di funzionalità, riducete la complessità delle discussione incentrata su una singola release, e quindi ne migliorate la prevedibilità. Questo crea anche una tendenza inerziale contro chiunque proponga di espandere la definizione della release aggiungendo nuove funzionalità e altre complicazioni. Se i contenuti della release sono del tutto ben definiti, è onere di chi propone giustificarne l'espansione, anche se la data della release non può essere ancora fissata.

Nella biografia multi volume di Thomas Jefferson, efferson e il suo Tempo, Dumas Malone racconta la storia di come Jefferson gestì il primo meeting tenutosi per decidere l'organizzazione della futura Università della Virginia. L'Università aveva avuto l'idea di Jefferson al primo posto, ma (come è nel caso di ogni luogo, non solo nei progetti open source, molti altri gruppi erano saliti sul palco rapidamente, ognuno coi propri interessi e agende. Quando essi si adunarono in quel primo meeting per parlare delle cose, Jefferson si assicurò con i disegni di una meticolosa architettura preparata, budgets dettagliati per la costruzione e per l'operatività, un programma di studi proposto, e i nomi delle specifiche facoltà che voleva importare dell'Europa. Nessun altro nella sala era così preparato anche lontanamente; e finalmente l'Università fu fondata più o meno in accordo con i suoi piani. Il fatto che la costruzione andò di molto oltre il budget, e molte delle sue idee invece no, per molte ragioni, si risolse alla fine, in cui Jefferson conosceva perfettamente le cose che sarebbero accadute. Il suo proposito fu strategico: mettersi in mostra nel meeting con qualcosa di così concreto che chiunque altro avrebbe fallito nella parte di proporre semplicemente modifiche ad esso, cosicché il disegno complessivo, e quindi il programma, sarebbe stato in modo grezzo quello che voleva.

Nel caso di un progetto di software libero non c'è un singolo “meeting”, ma invece una serie di piccole proposte fatte per la maggior parte per mezzo del tracciatore di problemi. Ma se avete un certa credibilità nel progetto per incominciare, e partite con l'assegnare varie funzionalità, accrescimenti, e bugs alla release obiettivo nel tracciatore di problemi, in accordo con quelche piano complessivo annunciato, la gente per la maggior parte andrà insieme a voi. Una volta che avete ottenuto che le cose siano sistemate più o meno come volete, la conversazione sulle date delle releases andrà avanti in modo più regolare.

E' cruciale, certo, non presentare mai una decisione individuale come scritta nella pietra. Nei commenti associati all'assegnamento di un problema a una specifica futura release, provocate una discussione, e siate genuinamente desiderosi di essere persuasi ogni volta che è possibile. Non esercitate mai il controllo con lo scopo di esercitare solamente il controllo: più a fondo gli altri parteciperanno al processo di pianificazione delle releases (vedere sezione chiamata «Suddividete i Compiti di Management e i Compiti Tecnici» in Capitolo 8, Gestire i Volontari), più facile sarà il persuaderli a condividere le vostre priorità sui problemi che contano veramente per voi.

L'altro modo in cui il progetto può smorzare le tensioni sulla pianificazione delle release è fare releases molto spesso. Quando c'è molto tempo fra le releases, l'importanza di ogni singola releases è amplificato nella mente di ognuno; le persone si sentono così tanto più annientate quando il loro codice non ce la fa ad entravi, perché sanno quanto tempo ci vorrà per il prossimo cambiamento. A seconda della complessità del processo di rilascio e della natura del vostro progetto, qualcosa come tre o sei mesi è il giusto intervallo di solito fra le releases, sebbene le linee di manutenzione possono far uscire micro releases un po' più spesso, se c'è bisogno di esse.

DLa delega non è solo un modo per suddividere il carico di lavoro; esso è anche uno strumento politico e sociale. Considerate tutte le conseguenze di quando chiedete a qualcuno di fare qualcosa. Il più ovvio effetto è che, se accetta, lui fa il lavoro e voi no. Ma un'altra conseguenza è che egli fa sapere che voi avete avuto fiducia in lui nell'affidargli il compito. Inoltre, se avete fatto la richiesta in un forum pubblico, allora egli sa che gli altri nel gruppo sono anche al corrente di quella fiducia. Egli può aver la sensazione di una certa pressione ad accettare, il che significa che dovete chiedere in un modo che gli permetta di declinare gentilmente se non vuole realmente il lavoro. Se il compito richiede coordinazione con gli altri nel progetto, voi in realtà state chiedendo che egli diventi più coinvolto, obblighi di forma che non avrebbero potuto esserci in altre circostanze, e che forse diventano una forma di autorità in qualche sotto dominio del progetto. Il coinvolgimento aggiuntivo potrebbe spaventarlo, o potrebbe portarlo anche ad impegnarsi in altri modi, per un aumentato senso di impegno complessivo.

A causa di tutte queste conseguenze, spesso ha un senso chiedere a qualche altro di fare qualcosa anche quando sapete che potreste farlo più facilmente e velocemente voi stessi. Certo, c'è talvolta uno stringente argomento di efficienza economica relativamente a questa cosa comunque: forse il costo economico di farlo voi stessi sarebbe troppo alto ci potrebbe essere qualcosa di più importante che potreste fare in quel lasso di tempo. Ma anche quando non si applica l'argomento del costo economico, voi potete ancora voler chiedere a qualche altro di intraprendere il lavoro perché a lungo andare voi volete tirarlo più in profondità nel progetto, anche se ciò significhi spendere un tempo extra per aver cura di lui all'inizio. Si applica anche le tecnica inversa: se voi occasionalmente vi offrite volontari per fare qualcosa che qualche altro non vuole o non ha il tempo di fare, vi guadagnerete la sua buona volontà e il rispetto. La delega e la sostituzione non esistono solo per ottenere che un compito individuale sia portato a termine; esse esistono anche per coinvolgere più strettamente la gente nel progetto.

Lode e critica non sono opposti; sotto molti aspetti essi sono simili. Sono sia una forma primaria cdi attenzione, e sono tantissimo efficaci quando sono specifici piuttosto che generici. Sia dovrebbero essere espressi con obiettivi concreti in mente. Sia possono essere sminuiti per inflazione: lodate troppo o troppo spesso, e svaluterete la vostra lode; lo stesso vale per la critica, sebbene in pratica, la critica provochi una reazione e quindi è un po' più resistente alla svalutazione.

Una importante caratteristica della cultura tecnica è che la critica dettagliata spassionata è spesso presa come una specie di lode (come discusso in sezione chiamata «Riconoscere la maleducazione» in Capitolo 6, Comunicazione), a causa della conseguenza che il lavoro di chi la riceve è apprezzato per il tempo richiesto per analizzarlo. Comunque ambedue le condizioni—dettagliato e spassionato—devono per questa persona risultare veri. Per esempio, se qualcuno fa un cambiamento trasandato al codice è inutile (e in realtà dannoso) fargli seguire una semplice frase del tipo “Questo era trasandato”. La trascuratezza è in fin dei conti una caratteristica della persona, non del suo lavoro, ed è importante mantenere le vostre reazioni focalizzate sul lavoro. E' molto più efficace descrivere tutte le cose sbagliate in quel cambiamento, tatticamente e senza malizia. Se questo è il terzo o il quarto cambio trasandato in una riga da parte delle stessa persona, è opportuno dirlo—di nuovo senza rabbia—alla fine della vostra critica, per rendere chiaro che il comportamento è stato notato.

Se qualcuno non si migliora in risposta alla critica, la soluzione non è più critica o più forte critica. La soluzione per il gruppo è rimuovere quella persona dalla posizione di non competenza, in un modo tale da le sensazioni di risentimento quanto più è possibile; vedere sezione chiamata «Gli avvicendamenti» più avanti in questo capitolo per gli esempi. Questa è una occorrenza rara comunque. La maggior parte della gente risponde molto bene alla critica che sia specifica, e che contenga una chiara (anche se non detta) aspettativa di miglioramento.

La lode non dovrebbe offendere i sentimenti di nessuno, certo, ma questo non significa che dovrebbe essere usata per nulla meno con attenzione della critica. La lode è uno strumento: prima di usarla, chiedetevi perché volete usarla. Come regola, non è una buona idea lodare la gente per cose che usualmente fa, o per azioni che sono una parte normale e prevista della partecipazione al gruppo. Se voi doveste farlo, sarebbe difficile sapere quando smettere dovreste lodare ognuno perché fa le cose normali? Dopotutto, se lasciate fuori qualcuno, egli si chiederà perché. E' molto meglio esprimere lode e gratitudine con parsimonia, in risposta a inattesi e insoliti sforzi, con l'intento di incoraggiare più sforzi di questi. Quando un partecipante sembra essesi mosso permanentemente in uno stato di alta produttività, adattate la vostra soglia di lode per quella persona in modo consono. Lodi ripetute per comportamenti normali diventano senza senso comunque. Invece, quella persona dovrebbe avvertire che il suo alto livello di produttività è ora considerato come normale e naturale, e solo il lavoro che vada oltre quel livello dovrebbe essere notato particolarmente.

Con questo non voglio dire che i contributi della persona non dovrebbero essere riconosciuti, certo. Ma ricordate che se il progetto è messo su bene, ogni cosa che quello persona fa è già visibile comunque, e così il gruppo saprà (e la persona saprà che che il resto del gruppo sa) ogni cosa che fa. Ci sono anche modi per dare un riconoscimento al lavoro che uno fa per mezzo di altro al posto di lodi dirette. Potete menzionare di passaggio, mentre discutete un argomento correlato, che egli ha fatto un sacco di lavoro in un dato campo ed è l'esperto locale lì; potete pubblicamente consultarlo circa qualche questione sul codice; o magari, più efficacemente, potete fare un massiccio uso ulteriore del lavoro che ha fatto, in modo che veda che gli altri sono a proprio agio nel contare sul risultato del suo lavoro. Probabilmente non è necessario fare queste cose in modo calcolato. Qualcuno che regolarmente dà ampi contributi in un progetto lo saprà, e occuperà una funzione influente senza che faccia nulla di proposito. Di solito non c'è bisogno di fare passi espliciti per assicurare ciò, a meno che voi non abbiate la sensazione, per una qualsiasi ragione, che un collaboratore è sottostimato.

Fate attenzione a che i partecipanti non cerchino di esercitare una proprietà esclusiva su certe aree del progetto, e a coloro che sembrano voler fare tutto il lavoro in quelle aree, fino al punto di assumere la direzione del lavoro che altri incominciano. Tale comportamento può sembrare anche sano all'inizio. Dopotutto in superficie egli sembra una persona che si prede più responsabilità, e mostra una attività maggiore un una data area. Ma a lungo andare, ciò è distruttivo. Quando la gente ha la percezione di un segnale di “non sconfinamento” si astiene. Il risultato è una ridotta revisione in quell'area, e di una maggiore fragilità, perché lo sviluppatore solitario diventa un punto di fallimento che provoca il fallimento dell'intero progetto. Peggio, ciò infrange la collaborazione, lo spirito egualitario del progetto. La teoria dovrebbe essere sempre quella che ogni sviluppatore deve essere il benvenuto nell'essere di aiuto in ogni operazione in ogni momento. Certo, in pratica le cose vanno un po' diversamente: le persona hanno aree in cui sono più o meno influenti, e i non esperti rinviano agli esperti in certi domini del progetto. Ma la chiave è che ciò sia tutto volontario: l'autorità informale è data per scontata se basata sulla competenza e sul giudizio dimostrato, ma non dovrebbe mai essere acquisita volontariamente. Anche se la persona che desidera l'autorità e effettivamente competente, è cruciale che eserciti quell'autorità informalmente, attraverso il consenso del gruppo, e che non sia la causa dell'escussione di altri dal lavoro in quel gruppo.

Respingere o modificare il lavoro di qualcuno, è una roba completamente differente. Lì, il fattore decisivo è il contenuto del lavoro, non chi è sembrato agire come custode. Può avvenire che una stessa persona sembra fare la maggior parte del lavoro di revisione per una data area, ma fino a quando egli non cerca di impedire a qualcun altro di fare anche lo stesso lavoro, le cose stanno probabilmente a posto.

Per combattere un incipiente territorialismo, o anche l'apparenza di esso, molto progetti hanno fatto il passo di bandire l'introduzione nei file sorgenti dei nomi degli autori e quelli dei manutentori designati. Io sono francamente d'accordo con questa pratica: noi la seguiamo nel progetto Subversion, ed è più o meno la politica ufficiale nella Apache Software Foundation. Il membro della ASF la presenta in questo modo:

I files sorgente di codice di un progetto sono il cuore della sua identità. Essi dovrebbero rispecchiare il fatto che la comunità degli sviluppatori è nel complesso responsabile per essi, e non è divisa in piccoli feudi.

La gente talvolta parla in favore dei tags author o mantainer nei files sorgente sulla base del fatto che essi danno un riconoscimento visibile a quelli che hanno fatto la maggior parte del lavoro lì. Ci sono due problemi su questo argomento. Primo, i tags inevitabilmente sollevano la imbarazzante questione di quanto lavoro uno debba fare per vedere il suo nome elencato lì pure. Secondo, essi aggiungono il problema del riconoscimento a quello della paternità: aver fatto il lavoro in passato, non implica la paternità dell'aerea in cui il lavoro fu fatto, ma è difficile se non impossibile una tale conclusione quando i nomi individuali sono elencati in cima ai files sorgenti. In ogni caso l'informazione dei riconoscimenti può essere ottenuta dai logs del controllo di versione e per mezzo di altri meccanismi messi al-di-fuori-della-banda, come gli archivi delle mailing lists, in modo tale che non si perda nessuna informazione bandendola dai files sorgente stessi.

Se il vostro progetto decide di bandire i nomi individuali dai file sorgenti, cercate di non debordare. Per esempio, molti progetti hanno un'area contrib/ in cui sono tenuti piccoli strumenti e scripts di aiuto, spesso scritti da gente che non è per altra via associata al progetto. E' bene che quei files contengano i i nomi degli autori, perché essi non sono effettivamente in manutenzione al progetto nel suo intero. D'altra parte, se uno strumento dato come contributo incomincia ad essere modificato da altre persone nel progetto, alla fine voi potete volerlo spostare in un una locazione meno isolata, e facendo il caso che l'autore originale approvi, rimuovere il nome dell'autore, di modo che il codice appaia come ogni altra risorsa in manutenzione da parte dalla comunità. Se l'autore è permaloso su questo, sono accettabili soluzioni di compromesso, per esempio:

Ma è meglio evitare tali compromessi, se possibile, e molti autori si stanno persuadendo, perché sono felici del fatto che si sta facendo del loro contributo una parte più integrale del progetto.

La cosa importante è ricordare che c'è una continuità fra il cuore e la periferia di ogni progetto. I principali files di codice sorgente del software sono chiaramente parte del cuore, e dovrebbero essere essere considerati in manutenzione da parte della comunità. D'altra parte, strumenti di accompagnamento o pezzi di documentazione possono essere il lavoro di singoli individui, che li hanno in manutenzione essenzialmente da soli, anche se i lavori possono essere associati, o anche distribuiti, dal progetto. Non c'è bisogno di applicare una regola di taglia unica a ogni file, finché vale il principio che non è permesso che le risorse in manutenzione alla comunità diventino territori personali.

Cercare di non consentire agli uomini ciò che invece potrebbero fare le macchine. Come regola pratica, automatizzare una operazione comune vale dieci volte almeno lo sforzo che uno sviluppatore dovrebbe impiegare a fare manualmente quella operazione una volta. Per operazioni molto frequenti o molto complesse, il rapporto potrebbe arrivare facilmente a venti o anche di più.

Il pensare a voi stessi come “gestori di progetto”, piuttosto che solo come ad un altro sviluppatore, potrebbe essere un utile atteggiamento qui. A volte gli sviluppatori individuali sono tropo infagottati in lavori di basso livello per vedere il quadro grande e rendersi conto che ognuno sta sprecando un sacco di energie ad eseguire manualmente operazioni automatizzabili. Anche quelli che se ne rendono conto possono non avere il tempo di risolvere il problema: perché ogni esecuzione individuale dell'operazione non è percepita come un enorme carico, nessuno si secca abbastanza di fare qualcosa che la riguarda. Ciò che rende convincente l'automazione è che quel piccolo carico è moltiplicato per il numero di volte che ogni sviluppatore incorre in essa, e quindi quel numero è moltiplicato per il numero degli sviluppatori.

Qui sto usando il termine “automazione” in senso largo, per indicare non solo le ripetute azioni nelle quali una o due variabili cambiano ogni volta, ma ogni tipo di infrastruttura tecnica che assiste gli uomini. Il minimo standard di automazione richiesta per far girare un progetto in questi giorni è descritto in Capitolo 3, L'Infrastruttura Tecnica , ma ogni progetto può avere i suoi particolari problemi anche. Per esempio un gruppo che sta lavorando sulla documentazione, potrebbe volere un sito che mostri le più aggiornate versioni dei documenti in ogni momento. Siccome la documentazione è scritta in un linguaggio di markup come l'XML, ci può essere un passo della compilazione, spesso piuttosto intricato, relativo alla creazione di documenti che si possano esporre e che si possano scaricare. Adattare un sito in modo che tale compilazione avvenga automaticamente ad ogni invio può essere complicato e dispendioso come tempo impiegato ma ne vale la pena, anche se vi costa un giorno o più ad allestirlo. Il beneficio complessivo di avere pagine aggiornate in ogni momento è enorme, anche se il costo di non non averlo potrebbe sembrare solo un piccolo incomodo in ogni singolo momento, ad ogni singolo sviluppatore.

Fare tali passi non solo elimina tempo sprecato, ma l'oppressione e la frustrazione che ne deriva quando gli uomini fanno dei passi sbagliati (come li faranno inevitabilmente) nel cercare di portare a termine complicate procedure manualmente. Le operazioni dai molteplici passi, deterministiche sono ciò per cui i computers sono stati inventati; riservate agli uomini cose più interessanti.

Ogni interazione con un utilizzatore è un'opportunità per procurarsi un nuovo volontario. Quando un utilizzatore si concede il tempo di scrivere ad una delle mailing lists del progetto o di mettere un archivio un rapporto di bug, ha già indicato se stesso come possessore di un maggiore potenziale per un coinvolgimento rispetto alla maggior parte degli utilizzatori (dai quali il progetto non avrà mai notizie). Seguite questo potenziale: se egli ha descritto un bug, ringraziatelo per il report e chiedetegli de vuole correggerlo. Se egli ha scritto per dire che che una domanda importante manca nelle FAQ, o che la documentazione del programma è insufficiente in qualche modo, allora ammettete apertamente l'esistenza del problema (ammesso che esso esista realmente), e chiedetegli se è interessato a scrivere il materiale mancante. Naturalmente molte volte l'utilizzatore farà obiezione. Ma non costa molto chiedere, e ogni volta che lo fate, ciò ricorda agli altri ascoltatori in quel forum che essere coinvolti nel progetto è qualcosa che ognuno può fare.

Non limitate i vostri obiettivi ad acquisire nuovi sviluppatori e gente che scriva la documentazione. Per esempio, anche l'addestramento della gente a scrivere buoni rapporti di bugs dà buoni risultati a lungo andare, se non impiegate troppo tempo per persona, e se essi procedono ad inviare più report di bugs in futuro—cosa a cui sono molto propensi se ottengono una costruttiva reazione al loro primo rapporto. Una costruttiva reazione non è necessario che sia una correzione del bug, sebbene questo sia sempre l'ideale; essa può essere anche un sollecitazione per maggiori informazioni, o solamente la conferma che quel comportamento è un bug. La gente vuole essere ascoltata. Secondariamente essi vogliono che il loro bug sia corretto. Voi potrete non essere in grado di dare loro la seconda cosa in modo opportuno, ma (o il progetto intero) potete dare loro la prima cosa.

Un corollario di questo è che gli sviluppatori non dovrebbero esprimere collera a persone che archiviano ben comprensibili ma vaghi report di bug. Questo è uno dei miei fastidi ricorrenti; vedo farlo su varie mailing lists open source, è il male che fa è palpabile. Alcuni sventurati principianti scriveranno un inuutile report:

che hanno visto questo tipo di report centinaia di volte, e che non si sono trattenuti dal pensare che il principiante non li hanno visti centinaia di volte risponderanno all'incirca così:

Lo sviluppatore ha mancato di vedere le cose dal punto di vista dell'utilizzatore, ed ha mancato anche di considerare l'effetto che una tale reazione potrebbe avere sul tutte le altre altre persone che stanno osservando lo scambio. Naturalmente un utilizzatore che non ha una esperienza di report di bugs, non saprà come scrivere un report di bug. Quale è il modo giusto di trattare questa persona? Educatelo! E fatelo in modo che egli ritorni per maggiori ragguagli:

Questo modo di rispondere è molto più efficace per ottenere le necessarie informazione dagli utilizzatori, perché sono scritte dal punto di vista dell'utilizzatore. Primo, esso esprime simpatia: Voi avevate un problema; non sentivamo il vostro disappunto.. (Ciò non è necessario in ogni risposta a ogni rapporto di bug; dipende dalla serietà del problema e da quanto è sembrato sconvolto l'utilizzatore. Secondo, invece di disprezzarlo perché no sa come riportare un bug, gli dice come, e abbastanza in dettaglio per essere veramente utile per esempio molti utilizzatori non si rendono conto che “mostraci l'errore” significa “mostraci l'esatto testo dell'errore, senza omissioni o riassunti.” La prima volta che lavorate con tale utilizzatore, bisogna che siate precisi su questo. Alla fine ciò offre un puntatore a molte più dettagliate e complete istruzioni per l'invio dei rapporti sui bugs. Se avete stabilito con successo un contatto con l'utilizzatore, egli si prenderà spesso il tempo di leggere quel documento e fare ciò che dice. Ciò vuol dire che voi, certamente, dovete aver preparato quel documento in anticipo. Esso dovrebbe dare chiare istruzioni su che tipo di informazioni vuole vedere in ogni rapporto il vostro team di sviluppo. Idealmente, esso dovrebbe evolversi nel tempo in risposta a ai tipi pericolari di omissioni e di cattivi report che l'utilizzatore tende a a fare per il vostro progetto.

Le istruzioni sui report di Subversion sono un esempio standard alla lettera della forma (vedere Appendice D, Istruzioni di Esempio per Segnalare un Bug). Notate come essi rispondono ad un invito a fornire una patch per correggere il bug. Ciò non avviene perché un tale invito porterà a un rapporto patch/report più grande la maggior parte degli utilizzatori sono in grado di correggere bugs di cui già sanno che una patch sarebbe la benvenuta, e non hanno bisogno che gli venga detto. Il reale proposito di un invito è quello di porre l'accento per tutti gli utilizzatori, specialmente quelli nuovi nel progetto, o nuovi al software libero in generale, sul fatto che che il progetto va avanti con contributi di volontari. In un certo senso, gli attuali sviluppatori del progetto non sono più responsabili della correzione dei bugs di quanto non lo siano quelli che li hanno segnalati nei report. Questo è un punto importante con il quale molti nuovi utilizzatori non avranno familiarità. Una volta che se ne rendono conto essi probabilmente contribuiranno a fa si che la correzione al bug avvenga, se non contribuendo col codice allora fornendo un più completa ricetta per la riproduzione, o offrendosi per tests di bugs che le altre persone postano. L'obiettivo è far si che ogni utilizzatore si renda conto che non c'è una innata differenza fra se stessi e la gente che lavora al progetto è una questione di quanto tempo uno ci mette dentro, non di chi uno sia.

L'ammonizione a non rispondere in modo irritato non vale per gli utilizzatori sgarbati. Occasionalmente gli utilizzatori postano reports o rimostranze che, indipendentemente dal loro contenuto di informazione, mostrano un disprezzo con derisione nei confronti di alcune manchevolezze del progetto. Spesso tali persone alternativamente insultano e fanno complimenti, come la persona che postò alla mailing list di Subversion:

La risposta iniziale a questa infiammatorio post fu sorprendentemente contenuta: la gente fece notare che il progetto aveva un politica esplicita di non fornire binari, e disse, con vari gradi di irritazione, che sarebbe stato compito dei volontari di produrli essi stessi se erano tanto importanti per loro. Ci credete o no, il suo post successivo partiva con queste righe:

...e quindi ritornò a redarguire il progetto di nuovo perché non forniva i binari, mentre non ancora si offriva volontario per fare qualcosa a proposito. Dopodiché, circa 50 persone gli saltarono addosso, e non so dire se veramente ci feci caso. La politica di “zero tolleranza” verso la maleducazione sostenuta in sezione chiamata «Stroncate sul Nascere la Scortesia» in Capitolo 2, Partenza si applica a persone con cui il progetto ha una prolungata interazione (o vorrebbe averla). Ma quando qualcuno rende chiaro dall'inizio che sta diventando una fontana di bile, non vale la pena di farlo sentire il benvenuto.

Tali situazioni sono fortunatamente piuttosto rare, e sono notevolmente rare in progetti e che fanno uno sforzo per ingaggiare utilizzatori con cortesia e costruttivamente sin dalla loro prima interazione.

In un progetto si software libero che riceve un sacco di patch, tener traccia di quali patch sono arrivate, e cosa si è deciso su esse può essere un incubo, specialmente se lo si fa un modo decentralizzato. La maggior parte delle patch arrivano come posts alla mailing list di sviluppo (sebbene alcune possano apparire nel tracciatore di bug, o su siti esterni), e quindi ci sono un numero di differenti itinerari che la patch può percorrere dopo l'arrivo.

A volte qualcuno revisiona le patch, trova i problemi, e li rimanda all'autore originario per la ripulita. Ciò, di solito, porta a un processo iterativo tutto visibile sulla mailing list in cui l'autore originario posta le versioni revisionate della patch fino a quando il revisore non ha nient'altro da criticare. Non è sempre facile dire quando il processo è terminato: se il revisore fa l'invio della patch, allora chiaramente il ciclo è completo. Ma se non lo fa, potrebbe essere semplicemente perché non ha tempo, o perché non ha l'accesso all'invio e non potrebbe unirsi alla cordata degli altri sviluppatori nel farlo.

Un'altra frequente risposta a una patch è una discussione a ruota libera, non necessariamente sulla patch stessa, ma sul fatto se il concetto che sta dietro la patch è buono. Per esempio, la patch può correggere un bug, ma il progetto preferisce correggere quel bug in un altro modo, come parte della risoluzione di una classe più generale di problemi. Spesso questa non è nota in anticipo, ed è la patch che ne stimola la scoperta.

Occasionalmente, una patch postata è accolta con assoluto silenzio. Ciò, di solito, è dovuto al fatto che al momento nessuno sviluppatore ha il tempo di revisionare la patch. Poiché non c'è un limite particolare per quanto riguarda il tempo che ogni persona aspetta che qualcun altro raccolga la palla, e nel frattempo altre priorità stanno arrivando, è molto facile che una patch sfugga tra le crepe senza che una singola persona abbia intenzione che avvenga. Il progetto potrebbe perdere una utile patch in questo modo, e ci sono anche altri dannosi effetti collaterali anche: ciò è scoraggiante per l'autore, che ha impiegato lavoro per la patch, e fa apparire il progetto nell'insieme come se abbia perso i contatti, specialmente agli altri che stanno prendendo in considerazione la scrittura di patch.

Il lavoro del manager di patch è quello di assicurare che le patch non “scivolino fra le crepe”. Ciò si ottiene seguendo ogni patch attraverso una sorta di stato stabile. Il manager di patch esamina ogni discussione della mailing list che consegua ad un post di patch. Se essa finisce con un invio, egli non fa niente. Se essa va in un' iterazione revisione/correzione, che termina con una versione finale della patch senza che ci sia l'invio, egli archivia un problema che punti alla versione finale, e alla mailing lista che tratta di esso, di modo che ci sia una registrazione permanente che gli sviluppatori possono seguire in seguito. Se la patch si indirizza ad un problema esistente, egli annota il problema con ricche informazioni, invece di aprire un nuovo problema.

Quando una patch non riscuote per niente una reazione, il manager di patch aspetta pochi giorni, quindi dà seguito alla cosa chiedendo se qualcuno sta per revisionarla. Questo, di solito, riceve una reazione: uno sviluppatore può spiegare che non pensa che la patch debba essere applicata, e ne dà le ragioni, o può revisionarla, nel qual caso viene fatto uno dei precedenti percorsi. Se non c'è ancora risposta, il manager di patch può o non può archiviare un problema per la patch, a sua discrezione, ma almeno chi originariamente ha fatto l'invio ha ricevuto qualche reaction.

L'avere un manager di patch ha salvato il team di sviluppo di Subversion un sacco di volte, ed fatto risparmiare energie mentali. Senza una persona designata che si prenda la responsabilità, ogni sviluppatore avrebbe da preoccuparsi continuamente “Se non ho il tempo di rispondere a questa patch subito, posso contare sul fatto che qualche altro lo faccia? Dovrei cercare di dargli un'occhiata. Ma se altre persone stanno anche tenendola d'occhio, per le stesse ragioni, noi avremmo inutilmente duplicato lo sforzo.” Il manager di patch rimuove la seconda congettura dalla situazione. Ciascuno sviluppatore può prendere la decisione giusta per lui dal primo momento che vede la patch. Se vuole dargli seguito con una revisione, può farlo il manager di patch adatterà il suo comportamento di conseguenza. Se vuole ignorare la patch completamente, andrà anche bene; il manager di patch dovrà assicurarsi che essa non sia dimenticata.

Siccome il sistema funziona solo se la gente può far conto sul fatto che il manager di patch sia là senza errore, il ruolo dovrebbe essere detenuto formalmente. In Subversion noi facemmo richiesta per esso mediate annuncio pubblicitario sulla mailing list dello sviluppo e degli utilizzatori, raccogliemmo molti volontari, e prendemmo il primo che ci rispose. Quando quella persona dovette ritirarsi (vedere sezione chiamata «Gli avvicendamenti» più avanti in questo capitolo), facemmo di nuovo la stessa cosa. Non cercammo mai di avere più persone ad detenere in comune il ruolo a causa delle informazioni addizionali che sarebbero state richiesta fra loro, ma forse a un volume molto alto di invii di patch, potrebbe aver senso un manager di patch a più teste.

Nei progetti di software “traduzione” può riferirsi a due cose molto differenti. Può significare tradurre la documentazione del software in altre lingue, o può significare tradurre il software stesso cioè ottenere le segnalazioni dei errore o dei messaggi di aiuto in altre lingue preferite dall'utente. Ambedue sono complesse operazioni, ma una volta che la giusta infrastruttura è allestita, esse sono largamente separabili dall'altro sviluppo. Poiché le operazioni sono simili in qualche modo, ha senso (a seconda del vostro progetto), avere un solo manager delle traduzioni che le gestisca ambedue, o può essere meglio avere due differenti manager.

Nel progetto di Subversion noi avevamo un manager di traduzione che gestiva ambedue le cose. Egli non deve scrivere le traduzioni egli stesso, certo, egli può dare una mano a uno o due, ma mentre questo scrive, egli dovrebbe aver bisogno di parlare dieci lingue (venti contando i dialetti) per lavorare a tutte le traduzioni. Invece, egli gestisce dei team di traduttori volontari: egli li aiuta a coordinarsi fra loro, e coordina i team fra loro e il resto del progetto.

Una parte delle ragioni per cui il manager delle traduzioni è necessario è che i traduttori sono una entità demografica differente da quella degli sviluppatori. Essi a volte hanno qualche o nessuna esperienza nel lavorare con deposito del controllo di versione, o certamente proprio nel lavorare come parte del team di volontari distribuito. Ma sotto altri aspetti essi sono spesso la miglior specie di volontari: persone proprio con una specifica conoscenza del dominio che videro una necessità e scelsero di essere coinvolti. Essi di solito sono desiderosi di imparare, ed entusiasti di mettersi al lavoro. Tutto ciò di cui hanno bisogno è uno che gli dica come. Il manager delle traduzioni assicura che la traduzione avvenga in modo da non interferire senza necessità col regolare sviluppo. Egli anche funziona come come sorta di rappresentanza dei traduttori come corpo unificato, ogni volta che gli sviluppatori devono essere informati di cambiamenti tecnici richiesti per supportare lo sforzo di traduzione.

Così, le abilità più importanti della posizione sono diplomatiche, non tecniche. Per esempio, in Subversion noi avevamo la politica che tutte le traduzioni dovevano avere almeno due persone a lavorarvi, perché altrimenti non c'è modo di revisionare il testo. Quando un nuovo volontario si offre per tradurre Subversion in, diciamo, Malgascio, il manager delle traduzioni deve agganciargli qualcuno che postò sei mesi prima esprimendo interesse a tradurre in Malgascio, o anche politicamente chiedere al volontario di andare a trovare un altro traduttore in Malgascio per lavorare come suo partner. Una volta che abbastanza persone sono disponibili, il manager li sistema per un proprio tipo di accesso all'invio, li informa delle convenzioni del progetto (come per esempio scrivere i messaggi di log), e quindi tiene un occhio ad assicurarsi che essi aderiscano a queste convenzioni.

Le conversazioni fra il manager delle traduzioni e gli sviluppatori, o fra il manager delle traduzioni e i team delle traduzioni, sono di solito tenute nel linguaggio originale del progetto cioè la lingua da cui tutte le traduzioni sono fatte. Per molti progetti di software libero, questa è l'inglese, ma non importa quale sia fino a quando il progetto è d'accordo su ciò. (L'inglese comunque è probabilmente il meglio per progetti che vogliono attrarre una larga comunità internazionale di sviluppatori).

Le conversazioni all'interno di un particolare team di traduzione avvengono nella loro lingua comune, comunque, è uno dei compiti del manager delle traduzioni quello di mettere su una mailing list dedicata per ogni team. In questo modo i traduttori possono discutere il loro lavoro liberamente, senza distrarre la gente su altre liste principali, la maggior parte delle quali non sarebbero in grado di capire il linguaggio di traduzione, comunque.

Il tenere aggiornata la documentazione è un compito senza fine. Anche nuove funzionalità o miglioramenti che entrano nel codice hanno la possibilità di causare un cambiamento nella documentazione. Anche, una volta che la documentazione del progetto raggiunge un certo livello di completezza, voi troverete che un sacco di patch che la gente manda sono per la documentazione, non per il codice. Questo perché ci sono molte più persone competenti a correggere i bug nella prosa più che nel codice: tutti gli utilizzatori sono lettori, ma solo pochi sono programmatori.

Le patch sulla documentazione sono di solito molto più facili da revisionare e da applicare che le patch sul codice. C'è poco testing o nessun testing da fare, e la qualità dal cambiamento può essere valutata rapidamente giusto con una revisione. Poiché la quantità è alta, ma il carico di revisione abbastanza basso il rapporto informazioni addizionali amministrative-lavoro produttivo è più grande per le patch di documentazione di quello delle patch di codice. Inoltre, la maggior parte delle patch avranno probabilmente la necessità di qualche ritocco per mantenere una coerenza di voce d'autore nella documentazione. In molti casi le patch si sovrapporranno o intaccheranno altre patch, e necessiteranno di essere ritoccate una rispetto all'altra prima di essere inviate alla mailing list a e al deposito.

Date le esigenze di gestire le patch sulla documentazione, e il fatto che il codice base ha bisogno di essere monitorato, in modo che la documentazione sia aggiornata, ha senso avere una persona, o un piccolo team, dedicato al compito. Essi possono tenere una registrazione di come e dove esattamente la documentazione resta indietro al software, ed possono avere delle procedure collaudate per gestire grandi quantità di patch in un modo integrato.

Certo, questo non preclude ad altra gente nel progetto di applicare patch di documentazione al volo, specialmente quelle piccole, quando il tempo lo permette. E lo stesso manager di patch (vedere sezione chiamata «Il Manager delle Patch» prima in questo capitolo) può tener traccia sia di patch del codice si di patch di documentazione, archiviandole dove i team della documentazione e il team di sviluppo rispettivamente vogliono. (Se la quantità totale di patch supera la capacità di una persona di tenerne traccia, tuttavia, passare a separati manager di codice e documentazione, è probabilmente un buon primo passo. Il punto del team della documentazione è avere persone che si ritengano responsabili del mantenere la documentazione organizzata, aggiornata, e coerente. In pratica, ciò significa conoscere la documentazione profondamente con l'osservare in codice base, osservare i cambiamenti che gli altri inviano alla documentazione, osservare le patch di documentazione che arrivano, e usare tutte queste sorgenti di informazioni per mantenere in salute la documentazione.

Il numero dei problemi nel tracciatore di bug del progetto cresce in proporzione al numero di persone che usano il software. Quindi, anche se correggete i bug e sistemate un programma sempre più robusto, vi dovreste aspettare che tuttavia che il numero di problemi aperti cresca essenzialmente senza limiti. La frequenza di problemi duplicati anche cresce, come crescerà la frequenza di problemi descritti in modo incompleto e con pochi particolari.

I manager dei problemi sono di aiuto nell'alleviare questi problemi con l'osservazione di ciò che va nel database, facendovi periodicamente la rivista per vedere se ci sono problemi specifici. Il loro atto più comune probabilmente è correggere i problemi che arrivano, o perché chi ha fatto il report non riempì correttamente alcuni campi del form, o perché il problema è un duplicato di uno esistente nel database. Ovviamente, più un manager di problemi è familiare con il database dei bug del progetto, con più efficienza sarà capace di trovare i problemi duplicati. Questo è uno dei principali vantaggi di avere poche persone che si specializzino nel database dei bug, invece che chiunque cerchi di farlo ad hoc. Quando il gruppo cerca di farlo in maniera decentralizzata, nessun singolo acquisisce una profonda esperienza nel contenuto del database.

I manager di problemi possono servire da mappa fra i problemi e i singoli sviluppatori. Quando ci sono un sacco di reports di bug che arrivano, non tutti gli sviluppatori possono leggere le mailing lists di notifica dei problemi con uguale attenzione. Comunque, se qualcuno che conosce il team degli sviluppatori sta tenendo d'occhio tutti i problemi che arrivano, allora può con discrezione dirigere l'attenzione di certi sviluppatori verso specifici bugs quando è opportuno. Certo, questo deve essere fatto con sensibilità verso chiunque altro vada avanti nello sviluppo, e ai desideri e al temperamento del destinatario. Quindi, è spesso la miglior cosa che il manager di problemi sia uno sviluppatore egli stesso.

A seconda di come il vostro progetto usa il tracciatore di bug, il manager di problemi può anche modellare il database in modo da riflettere le priorità del progetto. Per esempio, in Subversion, noi programmavamo i problemi in relaeses future specifiche, in modo che quando qualcuno chiedeva “Quando sarà corretto il bug X?, noi eravamo in grado si rispondere “Fra due releases”, anche se non gli potevamo dare la data esatta. Le releases sono rappresentate nel tracciatore di problemi come pietre miliari obiettivo, un campo disponibile in IssueZilla^[24] As a rule, every Subversion release has one major new feature and a list of specific bug fixes. We assign the appropriate target milestone to all the issues planned for that release (including the new feature—it gets an issue too), so that people can view the bug database through the lens of release scheduling. These targets rarely remain static, however. As new bugs come in, priorities sometimes get shifted around, and issues must be moved from one milestone to another so that each release remains manageable. This, again, is best done by people who have an overall sense of what's in the database, and how various issues relate to each other.

Un'altra cosa che i manager di problemi fanno è segnalare quando i problemi diventano obsoleti. A volte un bug è corretto accidentalmente come parte di in cambiamento al software non correlato, o a volte il progetto cambia la sua mentalità su fatto che un certo comportamento sia un errore. Trovare i problemi obsoleti non è facile: il solo modo di farlo sistematicamente è di fare una spazzata a tutti i problemi nel database. Intere spazzate diventano sempre meno fattibili col tempo, nella misura in cui cresce il numero dei problemi. Dopo un certo limite, il solo modo di mantenere in salute il database è quello di usare un approccio dividi-e-conquista: classificare immediatamente i problemi all'arrivo e dirigerli all'attenzione dello sviluppatore o del team. Il destinatario allora si prende carico del problema per il resto della sua vita, custodendolo verso la risoluzione o verso l'oblio se necessario. Quando il database è così grande, il manager dei problemi diventa più che un coordinatore complessivo, spedendo meno tempo a guardare ad ogni problema da sé, e più tempo a metterlo nelle mani della persona giusta.

La manutenzione delle FAQ è sorprendentemente un problema difficile. Diversamente dalla maggior parte dei documenti in un progetto, il cui contenuto è pianificato in anticipo dagli autori, una FAQ è un documento del tutto reattivo (vedere Manutenzione di una sezione FAQ). Non importa quanto grosso diventi, voi tuttavia non sapete quale sarà la nuova aggiunta. E poiché esso e costruito pezzo per pezzo, è molto facile che il documento nella sua interezza diventi incoerente e disorganizzato, e contenente anche voci duplicate o semi duplicate. Anche quando non ha nessun ovvio problema come questi, ci sono spesso interdipendenze non notate fra le voci link che dovrebbero essere creati e non lo sono perché la relativa voce fu inserita un anno lontano.

Il ruolo del manager delle FAQ è duplice. Primo, egli mantiene la qualità complessiva delle FAQ in quanto rimanere familiare con almeno gli argomenti di tutte le domande in esse, in modo che quando la gente aggiunge nuove voci che sono un duplicato o sono correlate alle voci esistenti, possa essere fatto l'appropriato adattamento. Secondo, egli osserva la mailing list del progetto e gli altri forum per altri problemi o domande e per scrivere nuove voci delle FAQ basate su queste informazioni. Questo secondo compito può essere piuttosto complesso: uno deve essere capace di seguire un argomento, riconoscere le domande base sollevate in esso, postare una voce nuova nelle FAQ, incorporarvi i commenti da parte di altri (poiché è impossibile che il manager delle FAQ essere un esperto in ogni argomento trattato nelle FAQ), e avvertire quando il processo è finito in modo che la voce sia alla fine aggiunta.

Il manager delle FAQ diventa anche l'esperto naturale nel formattare le FAQ. Ci sono un sacco di piccoli dettagli coinvolti nel tenere una FAQ nella forma giusta (vedere sezione chiamata «Trattate Tutte le Risorse Come un Archivio» in Capitolo 6, Comunicazione); quando gente a caso modifica le FAQ, a volte dimentica alcuni di questi dettagli. Questo va bene finché il manager delle FAQ è li a pulire dopo di loro.

Sono disponibili vari software per essere di aiuto nella manutenzione delle FAQ. E' bene fare uso di essi, finché non compromettono la qualità delle FAQ, ma guardatevi dal sovra-automazione. Alcuni progetti cercano di automatizzare completamente il processo di manutenzione delle FAQ, permettendo a chiunque di contribuire e modificare le voci delle FAQ in modo simile alle wiki (vedere sezione chiamata «Wiki» in Capitolo 3, L'Infrastruttura Tecnica ). Ho visto che questo accade particolarmente con le Faq-O-Matic (http://faqomatic.sourceforge.net/), sebbene può essere che che i casi che ho visto fossero semplici abusi che andavano oltre ciò per cui le Faq-O-Matic erano state concepite. In ogni caso, mentre la decentralizzazione completa della manutenzione delle FAQ riduce il carico di lavoro per il progetto, ha come risultato delle FAQ più trasandate. Non c'è una persona con una larga vedute di tutte le FAQ, nessuno che avvisa quando certe voci necessitano di aggiornamento o diventano obsolete completamente, e nessuno che osservi le interdipendenze tra le voci. Il risultato sono delle FAQ che spesso non riescono a fornire agli utilizzatori quello che stanno cercando, e nei casi peggiori li ingannano. Usate qualunque strumento di cui avete bisogno per fare la manutenzione alle vostre FAQ, ma non permettete mai alla convenienza degli strumenti di sedurvi a compromettere la qualità delle FAQ.

Vedere l'articolo di Sean Michael Kerner, Le FAQ sule FAQ, a http://osdir.com/Article1722.phtml, per la descrizione e la valutazione degli strumenti di manutenzione delle FAQ.

Nel progetto di Subversion noi sceglievamo coloro che dovevano far gli invio sulla base del principio Ippocratico: primo non fare danni. Il nostro criterio principale non è l'abilità tecnica oppure la conoscenza del codice, ma soltanto il fatto che chi fa gli invii mostri buon giudizio. Giudizio può significare semplicemente sapere cosa non intraprendere. Una persona potrebbe postare solo piccole patch, risolvendo onestamente piccoli problemi nel codice; ma se le patch si applicano un modo pulito, non contengono bug, e sono prevalentemente in accordo con i messaggi di log del progetto e col codice, con le convenzioni, e ci sono sufficienti patch a mostrare una chiara linea di comportamento, allora uno che fa già gli invii di solito propone quella persona per l'accesso all'invio. Se almeno tre persone dicono si, e nessuno obietta, allora viene fatta la proposta. Giusto, voi non potreste avere l'evidenza che è capace di risolvere problemi complessi in tutte le aree del codice base, ma questo non ha importanza: la persona ha reso chiaro che almeno è capace di giudicare le sue abilità. Le capacità tecniche possono essere imparate (e insegnate), ma il giudizio, per la maggior parte, no. Quindi, è la sola cosa che volete assicurarvi la persona abbia, prima di dargli l'accesso all'invio.

Quando la proposta di un nuovo accesso all'invio provoca discussioni, non è riguardo alle capacità tecniche, ma riguardo al comportamento della persona nella mailing list o in IRC. A volte qualcuno mostra abilità tecniche e capacità di lavorare all'interno delle linee guida formali del progetto, eppure è sostanzialmente bellicoso e non collaborativo nei forum pubblici. Questa è una faccenda seria; se la persona non sembra darsi da fare col tempo, anche in risposata ai consigli, allora noi non lo aggiungeremo come persona che fa gli invii non importa quanto capace sia. In un gruppo di volontari, capacità di socializzazione, o l'abilità di “giocare bene in un ambiente di prova”, sono importanti quanto le pure abilità tecniche. Siccome ogni cosa è sotto il controllo di versione, la penalità per l'aggiunta di uno che fa gli invii che voi non dovreste avere non è è tanto quanti problemi potrebbe causare al codice (la revisione li individuerebbe ad ogni modo), ma il fatto che potrebbe alla fine obbligare il progetto a revocare l'accesso agli invii alla persona—un atto che non è mai piacevole e che potrebbe a volte dar luogo a polemiche.

Molti progetti insistono sul fatto che la persona che potenzialmente potrebbe fare gli invii dimostri un certo livello di esperienza tecnica e sia tenace, inviando un certo numero di patch non secondarie; cioè, non solo questi progetti vogliono sapere che la persona non procurerà danni, vogliono sapere se possibilmente è brava nel codice base. Ciò è bene, ma siate attenti a che ciò non incominci a cambiare l'appartenenza a quelli che fanno gli invii in appartenenza ad un club esclusivo. La domanda da tenere a mente dovrebbe essere ”Cosa porterà i migliori risultati per il codice?” non “Dobbiamo svalutare lo stato sociale associato alla facoltà di fare gli invii ammettendo questa persona?” Il punto dell'accesso agli invii non è rafforzare l'autostima della gente, è consentire che buoni cambiamenti entrino nel codice senza un minimo di agitazione. Se voi avete 100 persone che fanno gli invii, 10 dei quali fanno cambiamenti su base regolare, e 90 dei quali correggono solo degli errori di stampa o dei piccoli bugs poche volte all'anno, questo è ancora meglio che avere solo i 10.

La prima cosa da dire sulla revoca dell'accesso all'invio è: cercate di non essere in quella situazione in primo luogo. A seconda delle persone il cui accesso all'invio sta venendo revocato, le discussioni su una tale azione possono essere molto divisive. Anche quando non fossero divisive, esse sarebbero causa di perdita di tempo ai danni del lavoro produttivo.

Comunque, se dovete farlo, la discussione dovrebbe tenersi privatamente fra le stesse persone che sarebbero nella posizione di votare per concedere a quella persona qualunque gusto dell'accesso all'invio che correntemente ha. La persona stessa non dovrebbe essere inclusa. Questo contraddice la solita ingiunzione contro la segretezza, ma in questo caso è necessario. Primo, nessuno sarebbe in grado di parlare liberamente altrimenti. Secondo, se la mozione non va a termine, voi non necessariamente volete che la persona sappia che ciò sia stato mai preso in considerazione, perché ciò potrebbe aprire domande (“Chi era dalla mia parte? Chi contro di me?) che portano al peggior tipo di faziosità. In certe rare circostanze, il gruppo può volere che qualcuno sappia che la revoca dell'acceso all'invio è stata o sta venendo considerata, come un avviso, ma questa apertura dovrebbe essere una decisione che prende il gruppo. Nessuno dovrebbe mai, di sua iniziativa, rivelare informazioni su una discussione e su un voto che gli altri presumono che siano segreti.

Once someone's access is revoked, that fact is unavoidably public (see sezione chiamata «Evitare Misteri» later in this chapter), so try to be as tactful as you can in how it is presented to the outside world.

Alcuni progetti presentano gradazioni dell'accesso all'invio. Per esempio, ci possono essere collaboratori il cui accesso all'invio dà loro libere redini nella documentazione, ma essi non possono fare gli invii per quanto riguarda il codice stesso. Aree comuni di invio parziale sono la documentazione, le traduzioni, l'adattare il codice ad altri linguaggi di programmazione, i file di specificazione per i pacchetti (per es. i file di specificazione per RedHat RPM) ed altre aree in cui un errore non dà luogo a un problema per la base del progetto.

Poiché l'accesso all'invio non è solo accesso all'invio ma significa anche far parte di un elettorato (vedere sezione chiamata «Chi Vota?» in Capitolo 4, L'Infrastruttura Sociale e Politica), nasce naturalmente la domanda: su cosa possono votare quelli che hanno l'invio parziale? Qui non c'è una singola risposta giusta; dipende da che tipo di dominio di invio parziale ha il vostro progetto. In Subversion noi abbiamo mantenuto le cose abbastanza semplici: uno che ha l'accesso all'invio parziale, può votare solo su questioni confinate al dominio di colui che fa gli invii, e non su ogni altro dominio. Importante, noi abbiamo meccanismi per dare voto consultivo (essenzialmente colui che fa gli invii scrive "+0" o "+1 (non impegnativo) invece che solo “+1” sulla scheda. Non c'è motivo di silenziare completamente la gente solo perché il loro voto non è formalmente impegnativo.

Coloro che hanno il pieno invio possono votare su ogni cosa, e solo coloro che hanno il pieno invio possono votare sull'ammissione di nuove persone con diritto di voto di ogni specie. Nella pratica, tuttavia, la competenza ad ammettere nuove persone con l'invio parziale è di solito delegata: ogni persona con invio pieno può “sponsorizzare” una nuova persona con invio parziale, e quest'ultimo in un dominio può in affetti scegliere nuove persone con diritto di invio per quello stesso dominio (questo è particolarmente utile nel far si che il lavoro di traduzione funzioni regolarmente).

Il vostro progetto può aver bisogno di piccoli differenti aggiustamenti, a seconda della natura del lavoro, ma a ogni progetto si applicano gli stessi principi generali. Ogni persona che ha l'invio dovrebbe poter votare su questioni che cadono entro la portata del suo accesso all'invio, e non su questioni all'infuori di esso, e i voti su questioni procedurali dovrebbero essere concessi solo a quelli che hanno il pieno invio, a meno che non ci sia qualche ragione (come deciso da coloro che hanno il pieno invio) di allargare l'elettorato.

Riguardo all'applicazione dell'accesso parziale all'invio: è spesso meglio non avere che il sistema di controllo di versione faccia rispettare i domini dell'invio parziale, anche se lo può. Vedere sezione chiamata «Autorizzazione» in Capitolo 3, L'Infrastruttura Tecnica le ragioni del perché.

Alcuni progetti rimuovono automaticamente le persone dall'accesso all'invio se essi per un certo tempo (diciamo, un anno) non fanno invii. Penso che questo non sia di aiuto e anche controproducente, per due ragioni.

Primo, ciò può tentare alcuni ad inviare cambiamenti accettabili ma non necessari, solo per impedire che il loro accesso all'invio si estingua. Secondo, non serve veramente a niente. Se il criterio principale per la concessione dell'accesso all'invio è il buon giudizio, allora perché presumere che il giudizio di qualcuno si deteriorerebbe solo perché egli è via dal progetto per un certo tempo? Anche se egli svanisce completamente per anni, non guardando il codice o non seguendo le discussioni dello sviluppo, quando riappare saprà quanto ha perso il contatto, ed agirà di conseguenza. Avete avuto fiducia nel suo giudizio prima, allora perché non averla sempre? Se i diplomi della scuola superiore non si estinguono, allora l'accesso all'invio certamente non lo dovrebbe.

A volte colui che ha un accesso all'invio può chiedere di essere rimosso, o di essere esplicitamente segnalato come dormiente nella liste di quelli che fanno gli invii (vedere sezione chiamata «Evitare Misteri» sotto per maggiori dettagli su questa lista). In quei casi, il progetto dovrebbe acconsentire ai desideri della persona, certamente.

Anche se la discussioni sull'ammissione di un nuova particolare persona all'invio deve essere confidenziale, i ruoli e le stesse procedure non c'è bisogno che siano segreti. Infatti, è meglio renderli pubblici, così la gente si rende conto che quelli che fanno gli invii non sono delle Camere da Star chiuse ai solo mortali, ma che chiunque può raggiungerli semplicemente postando delle buone patch e conoscendo come comportarsi nella comunità. Nel progetto di Subversion, noi mettiamo questa informazione giusto nel documento delle linee guida, dal momento la gente più adatta ad essere interessata a come l'accesso agli invii viene concesso è quella che pensa di contribuire codice al progetto.

Oltre a pubblicare le procedure, pubblicate la lista attuale di coloro che hanno accesso all'invio . Il posto tradizionale per fare questo è un file chiamato MAINTAINERS o COMMITTERS in cima all'albero del codice sorgente del progetto. Esso dovrebbe elencare prima tutti coloro che hanno l'invio pieno, seguiti dai vari domini con accesso parziale e dai membri di ciascun dominio. Ogni persona dovrebbe essere elencata col nome e con l'indirizzo email, sebbene l'email potrebbe essere codificata per evitare spam (vedere sezione chiamata «Nascondere gli indirizzi presenti negli archivi» in Capitolo 3, L'Infrastruttura Tecnica ) se la persona preferisce così

Poichè la distinzione fra accesso all'invio pieno e all'invio parziale è chiara e ben definita, è proprio dell'elenco fare la distinzione anche. Oltre a ciò l'elenco non dovrebbe cercare di indicare le distinzioni non formali che inevitabilmente si presentano in un progetto, come chi è influente e come. E' una registrazione pubblica, non un file di riconoscimenti. Elencate quelli che hanno accesso all'invio in ordine alfabetico, o nell'ordine in cui sono arrivati.

Se qualcuno minaccia una diramazione nel vostro progetto, mantenete la calma e ricordate gli obiettivi a lungo termine. La sola esistenza di una diramazione non è ciò che fa male a un progetto; piuttosto è la perdita di sviluppatori e utilizzatori. Il vostro vero scopo non è schiacciare la diramazione, ma minimizzare i suoi effetti dannosi. Potete essere furiosi, potete ritenere che la diramazione fu ingiusta e non necessaria, ma esprimere questo pubblicamente può solo alienare gli sviluppatori indecisi. Invece non obbligate la gente a fare scelte esclusive, e siate collaborativi e pratici con la diramazione. Per iniziare, non togliete l'accesso all'invio a qualcuno nel vostro progetto solo perché ha deciso di lavorare alla diramazione. Lavorare sulla diramazione non significa che la persona ha improvvisamente perso la sua competenza a lavorare al progetto originale; coloro che fanno gli invii prima dovrebbero rimanere quelli che fanno gli invii dopo. Oltre a ciò voi dovreste esprimere il desiderio di restare quanto più compatibili possibile con la diramazione, e dire che sperate che gli sviluppatori trasferiranno i cambiamenti fra il progetto e la diramazione quando è opportuno. Se avete l'accesso amministrativo ai servers, offrite a quelli della diramazione l'aiuto delle sovrastrutture al momento dell'avvio. Per esempio, offrite loro una copia completa con la storia profonda del deposito del controllo di versione, se essi non hanno altro modo di ottenerla, cosicché essi non abbiano a partire senza dati storici (ciò può essere non necessario a seconda del sistema di controllo della versione). Chiedete loro se c'è qualcos'altro di cui abbiano bisogno, e fornitelo se potete. Chinatevi all'indietro per mostrare che non state fra i piedi e per mostrare che la diramazione avrà successo o fallirà per i suoi meriti e nient'altro.

Il motivo per fare tutto ciò e farlo pubblicamente non è in verità quello di aiutare la diramazione, ma convincere gli sviluppatori che la vostra parte è una scommessa sul sicuro, apparendo quanto meno vendicativi possibile. In guerra talvolta ha senso (senso strategico, non umano) costringere la gente a scegliere una parte, ma nel software libero quasi sempre non lo ha. Infatti, dopo una diramazione, alcuni sviluppatori spesso lavorano apertamente ad ambedue i progetti e fanno del loro meglio per tenere le due cose compatibili. Questi sviluppatori aiutano a tenere aperte le linee di comunicazione dopo la diramazione. Essi permettono al vostro progetto di beneficiare di nuove interessanti funzionalità della diramazione (si, la diramazione può avere cose che volete), e anche accrescere le possibilità di una fusione per strada.

A volte una diramazione ha così successo, che anche se era considerata dai suoi stessi istigatori come diramazione dall'inizio, diventa la versione che ognuno preferisce, e alla fine soppianta l'originale per richiesta popolare. Un esempio famoso di ciò fu la diramazione GCC/EGCS. La GNU Compiler Collection (GCC, prima la GNU C Compiler) è il codice nativo di compiler open source più popolare, e anche uno dei più portabili compilatori del mondo. Dovuto al disaccordo fra i manutentori ufficiali del GCC e la Cygnus Software.,^[26] uno dei gruppi di sviluppatori più attivi, Cygnus creò una diramazione di GCC chiamata EGCS. La diramazione era deliberatamente non antagonistica: gli sviluppatori EGCS , in qualunque momento, non cercavano di descrivere la loro versione di GCC come una nuova versione. Invece si concentrarono sul fatto di rendere EGCS quanto migliore possibile, incorporando patch ad un ritmo superiore a quello dei manutentori dello GCC ufficiale. EGCS guadagnò in popolarità, e alla fine alcuni principali distributori di sistemi operativi decisero di impacchettare EGCS come loro compilatore di default invece di GCC. A questo punto, diventò chiaro ai manutentori di GCC che insistendo sulla denominazione "GCC" mentre ognuno passava alla diramazione EGCS avrebbe caricato ognuno con un inutile cambiamento di nome, ma non avrebbe fatto niente per impedire la migrazione. Così GCC adottò il codice base di EGCS, e c'è ancora un solo GCC, ma grandemente migliorato con la diramazione.

Questo esempio mostra perché non potete sempre considerare una diramazione come una assoluta cosa brutta. Una diramazione può essere dolorosa e non benvenuta al momento, ma voi non potete sapere se avrà successo. Quindi, voi e il resto del progetto dovete tenerci un occhio su, ed essere preparati non solo ad assorbirne il codice e le funzionalità quando possibile, ma nei casi più estremi, anche ad unirvi alla diramazione se essa raggiunge le dimensioni di popolarità del progetto. Certo, sarete spesso in grado di predire la probabilità di successo di una diramazione guardando chi si unisce ad essa. Se la diramazione è partita dai più grandi lamentosi del progetto e ad essa si è aggiunta una manciata di sviluppatori scontenti che non si stavano comportando costruttivamente comunque, essi hanno sostanzialmente risolto il problema con voi con la diramazione, e voi probabilmente non dovete preoccuparvi della diramazione portando via slancio al progetto originale. Ma se vedete sviluppatori influenti ed rispettati che sostengono la diramazione, ve ne dovrete chiedere il perché. Magari il progetto stava essendo eccessivamente restrittivo, e la migliore soluzione è adottare nella linea principale del progetto alcuni o tutti gli atti contemplati dalla diramazione—in sostanza evitare che la diramazione diventi tale.

Tutto il consiglio qui è nell'ipotesi che stiate facendo una diramazione come ultima risorsa. Esaurite tutte le altre possibilità prima di iniziare una diramazione. Fare una diramazione significa quasi sempre perdere sviluppatori, con solo una incerta promessa di acquisirne di nuovi dopo. Essa significa anche iniziare una competizione per l'attenzione degli utilizzatori: chiunque stia per scaricare ha da chiedere a se stesso: “Hmm, voglio questo o l'altro?” Qualunque dei due voi siate, la situazione è sporca, perché è stata introdotta una domanda che non c'era prima. Alcune persone sostengono che la diramazione è salutare per l'ecosistema del software nella sua interezza, per il classico argomento della selezione naturale: sopravviverà il più adatto, che significa che, alla fine, ognuno ottiene il software migliore. Questo può essere vero dal punto di vista degli ecosistemi, ma non è vero dal punto di vista di un singolo progetto. La maggior parte delle diramazioni non riescono, e la maggior parte dei progetti non sono contenti di essere biforcati.

Un corollario è che non dovreste usare la minaccia di una diramazione come tecnica estremistica di una discussione—“Fate le cose come dico io o io biforcherò il progetto!”—poiché chiunque è al corrente che un diramazione ch non riesce ad attrarre sviluppatori dal progetto originale è improbabile che viva a lungo. Tutti gli osservatori—non solo gli sviluppatori, ma utilizzatori e impacchettatori del sistema operativo anche—si faranno la loro idea su che parte scegliere. Voi dunque dovreste apparire estremamente riluttanti a un diramazione, così se alla fine la fate, possiate reclamare che era l'ultima via rimasta.

Non trascurate di tenere in conto tutti i fattori nel valutare il potenziale successo della vostra diramazione. Per esempio, se molti degli sviluppatori in un progetto hanno lo stesso datore di lavoro, allora anche se sono scontenti e privatamente favorevoli alla diramazione, è improbabile che lo dicano così a voce alta se il loro datore di lavoro è contro di essa. Molti programmatori di software libero amano pensare che avere una licenza libera sul codice significa che nessuna compagnia può dominare lo sviluppo. E vero che la licenza, in un senso definitivo, è un garante di libertà—se gli altri vogliono abbastanza fortemente biforcare il progetto, ed hanno le risorse per farlo, essi possono. Ma in pratica, alcuni team di progetti furono in gran parte finanziati da una entità, e non c'è motivo di pretendere che non interessi quel supporto dell'entità. Se essa si oppone alla diramazione, è improbabile che i suoi sviluppatori vi prendano parte, anche se segretamente lo vogliono.

Se tuttavia concludete che dovete fare la diramazione, allineatevi privatamente col supporto prima, quindi annunciate la diramazione in un modo non ostile. Anche se siete arrabbiati, o in disappunto, con i proprietari correnti, non dite questo nel messaggio. Giusto spassionatamente dichiarate ciò che vi ha portato alla decisione di una diramazione, e che non volete significare nessuna intenzione malevola verso il progetto da cui vi diramate. Dando per ipotesi che voi la considerate una diramazione (come opposta a una conservazione di emergenza del progetto originale), mettete l'accento sul fatto che non state diramando il nome ma il codice, e scegliete un nome che no vada in conflitto col nome del progetto. Potete usare un nome che contiene o si riferisce al nome originale, finché ciò non apre la porta a una confusione di identità. Certo è bene spiegare in modo prominente sulla pagina web della diramazione che essa discende dal programma originale, e anche che essa spera di soppiantarlo. Solo non fate si che la vita degli utilizzatori sia più difficile obbligandoli a sbrogliare una disputa di identità.

Infine, potete ottenere che le cose partano con il piede giusto concedendo automaticamente a tutti coloro che avevano l'invio nel progetto originale l'accesso all'invio nella diramazione, inclusi quelli che erano apertamente in disaccordo con la necessità di una diramazione. Anche se essi non usano mai l'accesso all'invio, il vostro messaggio è chiaro: ci sono disaccordi qui, ma non nemici, e date il benvenuto ai contributi di codice provenienti da ogni origine competente.

Se il vostro obiettivo è quello che il vostro codice sia accessibile dal più grande numero di sviluppatori e di lavori derivati e non date importanza al fatto che sia usato in programmi proprietari, scegliete la licenza MIT / X Window System (così chiamata perché è la licenza sotto la quale il Massachusetts Institute of Technology rilasciò il codice del sistema X Window). Il messaggio fondamentale di questa licenza è “Siete liberi di usare questo codice in qualunque modo vogliate”. Essa è compatibile con la GNU GPL, ed è breve, semplice e facile da capire:

        Copyright (c) <anno> <detentori del copyright>

        Il permesso è così garantito, gratuito, a qualunque persona che ottenga
        una copia di questo software e i file associati di documentazione (il
        “Software”), per commerciare col Software senza restrizioni, inclusi
        i diritti illimitati all'uso, alla copia, alla modifica, all'unione, alla pubblicazione,
        alle sotto licenze e/o a vendere copie del Software, e a
        permettere a persone alle quali il Software è fornito a fare lo stesso,
        soggetto alle seguenti condizioni:

        L'avviso di copyright summenzionato e questo avviso di permesso devono essere inclusi
        in tutte le copie o porzioni del Software sottostante.

        IL SOFTWARE E' FORNITO “COSI' COM'E'”, SENZA GARANZIA DI ALCUN GENERE,
        ESPRESSA O IMPLICITA, INCLUDENDO E SENZA ESSERE LIMITATO ALLE GARANZIE
        DI POTER ESSERE VENDUTO, L'IDONEITA' A UN PARTICOLARE FINE E
        LA NON VIOLAZIONE DEI DIRITTI ALTRUI. IN NESSUN CASO GLI AUTORI O I DETENTORI DEL COPYRIGHT
        SARANNO RESPONSABILI PER QUALSIASI RECLAMO, DANNO O ALTRA RESPONSABILITA', SIA IN FORZA
        DEL CONTRATTO, IN SITUAZIONE NON CONTEMPLATE NEL CONTRATTO O ALTRO, CHE NASCA DA, AL DI FUORI
        O IN RIFERIMENTO AL SOFTWARE O ALL'USO O AD ALTRE QUESTIONI RIGUARDANTI IL SOFTWARE.
      

(Presa da http://www.opensource.org/licenses/mit-license.php.)

Se preferite che il codice del vostro progetto non sia usato in programmi proprietari o se almeno non vi interessa se venga usato o no in programmi proprietari, scegliete la GNU General Public License (http://www.fsf.org/licensing/licenses/gpl.html). La GPL è probabilmente la licenza più largamente usata nel mondo oggi. Questo fatto di essere riconosciuta all'istante è di per se stesso uno dei più importanti vantaggi della GPL.

Quando scrivete una libreria con l'intendimento che sia usata come parte di altri programmi, considerate attentamente se le restrizioni imposte dalla GPL siano in linea con gli obiettivi del vostro progetto. In alcuni casi—per esempio, quando state cercando di sostituire una libreria proprietaria concorrente che fa le stesse cose—può essere molto più strategico licenziare il vostro codice in modo che possa essere mescolato con programmi proprietari, anche se invece non vorreste ciò. La Free Software Foundation ha anche foggiato una alternativa alla GPL in queste circostanze: la GNU GPL per librerie, più avanti rinominata GNU GPL Minore (la maggior parte della gente usa l'acronimo LGPL, in ogni caso). La LGPL ha meno stringenti restrizioni della GPL, e può essere mescolata facilmente con codice non libero. Comunque, è un po' più complessa e ha bisogno di qualche tempo per essere compresa, cosicché se vi state orientando per usare la GPL, vi consiglio di usare la licenza tipo MIT/X.

Una discreta quantità di software open source è distribuito sotto la licenza BSD (o, a volte una licenza stile BSD). La licenza originale BSD fu usata dalla Berkeley Software Distribution, con essa l'Università della California rilasciò importanti parti dell'implementazione Unix. La licenza (il testo esatto può essere visto nella sezione 2.2.2. di http://www.xfree86.org/3.3.6/COPYRIGHT2.html#6) era simile nello spirito alla licenza MIT/X, eccetto che in una clausola:

La presenza di quella clausola non solo rese la licenza originale BSD incompatibile con la GPL, ma stabilì anche un pericoloso precedente: che altre organizzazioni mettono simili clausole pubblicitarie nel loro software libero—mettendo il nome della propria organizzazione al posto della "l'Università della California, Lawrence Berkeley Laboratory"—e i ridistributori di software furono investiti da un sempre crescente carico su quello che a loro era richiesto di esibire. Fortunatamente molti dei progetti che usarono quella licenza diventarono consci del problema, e semplicemente eliminarono la clausola pubblicitaria. Nel 1999 anche l'Università della California fece lo stesso.

Il risultato fu una licenza BSD rivisitata, che è semplicemente una licenza originale BSD con la clausola pubblicitaria rimossa. Comunque, questa storia rende la frase “licenza BSD” un po' ambigua: si riferisce alla licenza revisionata o alla originale? Questo è il motivo per i quale io preferisco la licenza MIT/X, che è essenzialmente equivalente, e che non soffre di nessuna ambiguità. Comunque c'è forse un motivo per preferire la licenza BSD alla MIT/X, ed è quello che la licenza BSD include questa clausola:

Non è chiaro il fatto che senza una tale clausola un destinatario avrebbe avuto i diritti di usare il nome del licenziatario in qualche modo, ma la clausola rimuove ogni possibile dubbio. Per organizzazioni preoccupate del controllo del marchio, quindi, la licenza BSD può essere di poco preferibile alla MIT/X. In generale, comunque, una licenza liberale di copyright non implica che il destinatario abbia il diritto di usare o indebolire il vostro marchio— la legge sul copyright e quella sul marchio sono due bestie differenti.

Se volete usare un licenza BSD revisionata, un modello è disponibile a http://www.opensource.org/licenses/bsd-license.php.

La maggior parte dei progetti non raccolgono CLA o assegnazione di copyright dai loro collaboratori. Invece, accettano codice, ogni qualvolta sembra ragionevolmente chiaro che il collaboratore abbia inteso che esso incorporato nel progetto.

In circostanze normali ciò è regolare. Ma ogni tanto, qualcuno può decidere per la citazione in giudizio per infrazione di copyright, adducendo il fatto che essi sono veri proprietari del codice in questione, e che non hanno mai convenuto che esso fosse distribuito dal progetto sotto una licenza open source. Per esempio il gruppo SCO fece qualcosa di simile per il progetto Linux, vedere http://en.wikipedia.org/wiki/SCO-Linux_controversies per i dettagli. Quando ciò avvenisse, il progetto non avrà la documentazione che mostri che il collaboratore ha formalmente dato il diritto di usare il codice, cosa che potrebbe rendere più difficile una difesa legale.

I CLA probabilmente offrono il miglior compromesso fra sicurezza e convenienza. Un CLA è un modulo elettronico che il collaboratore compila e invia al progetto. In molte giurisdizioni l'invio di una email è sufficiente. Una firma digitale sicura può o non può essere richiesta; consultate un legale per trovare quale metodo sarebbe migliore per il vostro progetto.

La maggior parte dei progetti usano due tipi di CLA leggermente differenti, uno per collaboratori individuali e uno per collaboratori associati. Ma in ambedue i tipi il linguaggio base è lo stesso: il collaboratore concede al progetto "...una licenza di copyright perpetua, per tutto il mondo, non esclusiva, a costo zero, senza l'onere di pagare un compenso al titolare del copyright, l'irrevocabile licenza di copyright a riprodurre, preparare lavori derivati, mostrare pubblicamente, eseguire pubblicamente, creare una sotto licenza, e distribuirne [i] Contributi come lavori derivati." In più, potreste ottenere che un legale ratifichi ogni CLA, ma se voi metteste tutti questi aggettivi in essi, potreste probabilmente far bene.

Quando richiedete i CLA dai collaboratori, assicuratevi di puntualizzare che non state richiedendo una assegnazione di copyright. In effetti, molti CLA partono col ricordare a chi legge questo:

Qui ci sono alcuni esempi:

Trasferimento del copyright significa che il collaboratore dà al progetto la proprietà del copyright sul suo contributo. Idealmente ciò viene fatto su carta e anche mediante fax o con invio per posta normale al progetto.

Alcuni progetti insistono sulla piena assegnazione, perché avendo una unica entità legale propria il copyright sull'intero codice base può essere utile se i termini della licenza open source hanno bisogno di essere fatti valere in una corte. Se nessuna unica entità ha il diritto di farlo, tutti i collaboratori potrebbero dover collaborare, ma qualcuno potrebbe non aver tempo o essere rintracciabile quando nasca il problema.

Differenti organizzazioni applicano differenti quantità di rigore nel raccogliere le assegnazioni. Alcune si procurano una dichiarazione informale da parte di un collaboratore su una mailing list di liste pubbliche—qualcosa dall'effetto di “Io in tal modo assegno il copyright in questo codice al progetto, di essere rilasciato in licenza sotto gli stessi termini del restante codice” Almeno un legale con cui ho parlato dice che ciò è in effetti sufficiente, presumibilmente perché avviene in un contesto in cui la concessione del copyright è normale prevista comunque, e perché rappresenta un tentativo bona fide da parte del progetto di accertare le vere intenzioni dello sviluppatore. D'altra parte la Free Software Foundation va dalla parte opposta: richiede ai collaboratori di sottoscrivere e mandare per posta un pezzo di carta contenente una formale dichiarazione, a volte per un solo contributo, a volte per il contributo corrente e futuro. Se il collaboratore è un impiegato la FSF richiede che anche il collaboratore lo sottoscriva.

La paranoia dell'FSF è incomprensibile. Se qualcuno viola i termini della GPL incorporando qualcuno del loro software in un programma proprietario, la FSF avrà bisogno di litigare su questo davanti al tribunale, e vuole che i suoi copyrights siano il più inattaccabili possibile quando ciò avviene. Siccome la FSF è la detentrice del copyright di una gran quantità di software popolari, vede ciò come una possibilità reale. Se la vostra organizzazione ha la necessità di essere scrupolosa, è un fatto che solo voi potete decidere, consultandovi con dei legali. In generale, a meno che non ci sia un motivo specifico per cui il vostro progetto abbia bisogno di una piena assegnazione del copyright, andate avanti con i CLA; essi sono più facili per tutti.