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.