Fin qui abbiamo esaminato il compiti che non ripetuti che voi assolvete durante l'organizzazione di un progetto: scegliere una licenza, mettere e posto il sito iniziale, ecc.. Ma gli aspetti più importanti dell'avvio di un nuovo progetto sono dinamici. Scegliere l'indirizzo della mailing list è facile; assicurarsi che le conversazioni nelle lista rimangano in argomento e siano produttive è completamente un'altra cosa. Se il progetto sta per essere aperto dopo anni di chiusura, di sviluppo in casa, il suo processo di sviluppo cambierà e voi dovrete preparare gli sviluppatori per questo cambiamento.
I primi passi sono i più difficili perchè i diritti comuni e le aspettative per una condotta futura non sono stati ancora stabiliti. La stabilità per un progetto non viene da linee di condotta formali, ma da una saggezza condivisa difficile-da-definire che si sviluppa nel corso del tempo. Ci sono spesso regole scritte, ma esse tendono ad essere essenzialmente un distillato degli intangibile sempre evolventisi accordi che veramente guidano il progetto. Le linee di condotta scritte non definiscono la cultura del progetto finchè lo descrivono, e anche allora lo fanno solo approssimativamente.
Ci sono poche ragioni per le quali le cose trovano una soluzione in questo modo. La crescita e il grande cambiamento non sono così dannosi per l'accumulazione di norme sociali come uno potrebbe pensare. Finchè i cambiamenti non avvengono troppo rapidamente, c'è tempo per in nuovi arrivati di imparare come vanno fatte le cose, e dopo che hanno imparato, contribuiranno a rafforzare quei modi stessi. Considerate come le canzoni dei bambini sopravvivono nei secoli. Ci sono bambini oggi che cantano le stesse rime che i bambini cantavano centinaia di anni fa, anche se ora non ci sono bambini vivi che erano vivi allora. I bambini più giovani sentono le canzoni dai più vecchi e quando sono più vecchi, a loro volta le canteranno davanti ai più giovani. I bambini non si impegnano in un consapevole programma di trasmissione, certamente, ma il motivo per cui le canzoni sopravvivono è tuttavia il fatto che esse vengono trasmesse regolarmente e ripetutamente. La scala di tempo dei progetti di software libero non può essere misurata in secoli (non lo sappiamo ancora), ma le dinamiche della trasmissione sono le stesse. La velocità del cambiamento è molto alta, comunque, e può essere compensata da uno impegno nella trasmissione più attivo e intenzionale.
Questo impegno è favorito dal fatto che la gente generalmente evidenzia aspettativa e ricerca di norme sociali. Ed e proprio così che la gente è fatta. In un gruppo unificato dall'impegno comune, la gente che si unisce istintivamente ricerca comportamenti che li segnalerà come parte del gruppo. L'obiettivo di stabilire diritti comuni prima è quello di fare in modo che questi comportamenti “in gruppo” siano gli unici utili al progetto. Una volta stabiliti essi si auto- perpetueranno in gran parte.
Seguono alcuni esempi di cose specifiche che voi potete fare per stabilire buoni diritti comuni. Essi non sono interpretati come un elenco esaustivo, giusto come illustrazioni dell'idea che stabilire un modo collaborativo in principio favorisce un progetto moltissimo. Fisicamente ogni sviluppatore può essere al lavoro da solo in una stanza, ma voi potete fare molto perchè egli si senta come se stesse lavorando insieme agli altri in una sola stanza. Più essi avvertiranno ciò più vorranno spendere tempo per il progetto. Scelgo questi particolari esempi perchè essi si presentarono nel progetto di Subversion(http://subversion.tigris.org/), al quale io partecipai e osservai in esso all'inizio. Ma essi non sono singolari della Subversion; situazioni come queste si presentano in molti progetti open source, e dovrebbero essere viste come opportunità per iniziare a fare le cose col piede giusto.
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:
La discussione favorirà l'addestramento e l'educazione dei nuovi sviluppatori. Voi non sapete mai quanti occhi sono attenti alla conversazione; anche se la maggioranza della gente non parteciperà, molti seguiranno in silenzio racimolando informazioni sul software.
nell'arte di spiegare le questioni a persone che non hanno familiarità con le questioni tecniche come l'avete voi. Questa è una capacità che richiede pratica, e voi non potete acquisire questa pratica parlando a gente che già sa quello che sapete voi.
La discussione e le sue conclusioni saranno disponibili nel pubblico archivio per sempre dopo, dando la possibilità alle future discussioni di evitare di rifare gli stessi passi. Vedere sezione chiamata «Uso Ben Visibile degli Archivi» in Capitolo 6, Comunicazione .
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:
Prima prego limitiamoci ai (potenziali) commenti sulla persona; per esempio, il definire il progetto di J sul livello di sicurezza “ingenuo e ignorante dei principi base della sicurezza del computer.” Ciò può essere vero o no, ma in ogni caso non è un modo con il quale si ha la discussione. J ha fatto la sua proposta in buona fede. Se questa ha delle manchevolezze facciamole notare, e noi le correggeremo o troveremo un altro abbozzo. Io sono sicuro che M non volesse insultare personalmente J, ma il modo di parlare non ha avuto fortuna, e cerchiamo di mantenere le cose costruttive qui da noi.
Ora sulla proposta. Penso che M avesse ragione quando diceva...
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.
[10] Non siamo ancora arrivati alla sezione dei crediti, ma giusto alla pratica che io sosterrò più tardi: il nome dell'osservatore era Brian Behlendorf, e fu lui che richiamò l'attenzione sull'importanza di mantenere le discussioni pubbliche, amenochè non ci fosse uno specifico bisogno di privatezza.
[11] Questo è il modo in cui vene realizzata la revisione del codice nei progetti open source, in ogni caso. In progetti più centralizzati “revisione del codice” può anche significare più persone che si siedono insieme per esaminare accuratamente una stampa del codice, per cercare specifici problemi e modelli.