I riconoscimenti sono la moneta principale nel mondo del software libero. Qualunque cosa una persona possa dire sulle sue motivazioni della partecipazione a un progetto, non conosco sviluppatori che sarebbero felici di fare tutto il loro lavoro anonimamente, o sotto il nome di qualcun altro. Ci sono ragioni tangibili per questo: la reputazione di uno nel progetto approssimativamente determina quanta influenza ha, e la partecipazione a un progetto open source può anche avere indirettamente un valore monetario, perché alcuni datori di lavoro guardano a questo nel curriculum. Ci sono anche ragioni non tangibili, magari anche più forti: la gente semplicemente vuole essere apprezzata, e istintivamente guarda a segni che il loro lavoro è stato riconosciuto dagli altri. La promessa di riconoscimenti è quindi è una delle migliori motivazioni che il progetto abbia. Quando sono riconosciuti piccoli contributi, la gente ritorna per fare di più.
Una delle più importanti caratteristiche dello sviluppo in collaborazione (vedere Capitolo 3, L'Infrastruttura Tecnica ) è quella che esso tiene accurate registrazioni di chi fece cosa, quando. Dovunque è possibile, usate questi meccanismi esistenti per assicurarvi che i riconoscimenti siano distribuiti accuratamente, e siano specifici sulla natura del contributo. Non scrivete solo “Grazie a J. Random <jrandom@example.com>" se invece potete scrivere “Grazie a J. Casuale <jrandom@example.com> per il rapporto di bug e per la ricetta per la riproduzione" in un messaggio di log.
In Subversion, noi abbiamo la informale ma costante politica di riconoscere a chi fa un rapporto di bug o nel problema archiviato, se ce n'è uno, o nel messaggio di log dell'invio che corregge il bug, se no. Un rapido controllo dei logs di invio fino all'invio 14525 mostra che circa il 10% degli invii dà il riconoscimento a qualcuno per nome ed email, di solito la persona che ha analizzato e ha riportato il bug corretto da quell'invio. Notate che questa persona è differente dallo sviluppatore che in realtà fece l'invio, il cui nome è registrato automaticamente dal sistema di controllo della versione. Delle 80 e rotte persone che hanno il pieno o parziale invio in Subversion, 50 avevano i riconoscimenti nei log di invio (di solito molte volte) prima di diventare persone con l'invio essi stessi. Ciò, certo, non prova che l'essere riconosciuto è un fattore del loro coinvolgimento continuato, ma ciò almeno stabilisce una atmosfera in cui la gente può contare sul fatto che i suoi contributi vengono riconosciuti.
Bisogna distinguere fra riconoscimenti di routine e ringraziamenti speciali. Quando si discute un pezzo particolare di codice, o qualche altro contributo che qualcuno ha dato, è bene riconoscere il suo lavoro. Per esempio, dicendo “I recenti cambiamenti di Daniel al codice delta significano che ora noi possiamo implementare la funzionalità X” contemporaneamente aiuta la gente a identificare di quali cambiamenti state parlando e riconosce il lavoro di Daniel. D'altra parte, postare solamente per ringraziare Daniel per i cambiamenti al codice delta non serve ad uno scopo immediato. Non aggiunge nessuna informazione, perché il sistemi di controllo della versione e altri meccanismi hanno già registrato il fatto che egli ha fatto dei cambiamenti. Ringraziare ciascuno per ogni cosa può distrarre e in ultimo può essere senza informazione, perché i ringraziamenti sono in gran parte effettivi, nela misura in cui stanno fuori dal comune, livello di base di un commento favorevole che avvenga tutte le volte. Questo non significa, certo, che voi non dovreste ringraziare la gente. Solo assicuratevi di farlo in modo che non tenda a portare ad una inflazione di riconoscimenti. Seguire queste linee guida aiuterà:
Più è effimero il forum, più vi sentirete liberi di esprimere i ringraziamenti lì. Per esempio, ringraziando qualcuno per la correzione di un bug incidentalmente durante una conversazione in IRC è cosa buona, come lo è una divagazione in una email dedicata principalmente ad altri argomenti. Ma non postate una email solo per ringraziare qualcuno, a meno che ciò non sia per una impresa eroica non solita. Nello stesso modo, non intasate le pagine web del progetto con espressioni di gratitudine. Una volta che iniziate a farlo, non sarà mai chiaro quando e dove fermarsi. E non mettete mai ingraziamenti nei commenti al codice; ciò sarebbe solo una distrazione dal proposito principale dei commenti, che è aiutare il lettore a capire il codice.
Meno qualcuno è coinvolto nel progetto, più è appropriato ringrazialo per qualcosa che ha fatto. Ciò potrebbe suonare contrario all'intuito, ma è in linea con l'opinione che l'esprimere ringraziamenti è qualcosa che voi fate quando qualcuno contribuisce ancora di più di quanto voi pensavate che facesse. Così, ringraziare costantemente i collaboratori regolari perché fanno ciò che regolarmente fanno significherebbe esprimere una minore aspettativa su di loro di quanto essi la hanno di se stessi. Se mai, voi volete puntare all'effetto opposto!
Ci sono eccezioni occasionali a questa regola. E' accettabile ringraziare qualcuno perché occupa soddisfacentemente il suo ruolo previsto quando quel ruolo comporta fatiche temporanee intense di volta in volta. L'esempio canonico è il manager di release che va a velocità più elevata per quanto riguarda il tempo di ciascuna release, ma altrimenti rimane dormiente (dormiente come manager di release in ogni caso egli può essere anche un attivo sviluppatore, ma questa è un'altra questione).
Come per il criticismo e per i riconoscimenti, la gratitudine dovrebbe essere specifica. Non ringraziate la gente solo perché è grande, anche se lo è. Ringraziatela per qualcosa che ha fatto che era fuori dell'ordinario e per il buon punteggio, dite esattamente perché ciò che fecero era così grande.
n generale c'è sempre una tensione fra l'assicurarsi che i contributi individuali della gente siano riconosciuti, e l'assicurarsi che che il progetto sia una fatica pubblica invece che un insieme di glorie individuali. Giusto rimanete al corrente di questa tensione e cercate di sbagliare dalla parte del gruppo, e le cose non vi scapperanno di mano.