Siate aperti verso gli obiettivi della vostra organizzazione quanto potete senza compromettere i segreti del business. Se volete che il vostro progetto acquisisca una certa funzionalità perchè, per esempio, i vostri clienti la hanno chiesta a gran voce, ditelo apertamente sulla maliling list. Se i clienti vogliono restare anonimi, come a volte è il caso, allora chiedete loro se vogliono essere usati come esempi non nominati. Quanto più pubblicamente la comunità di sviluppo conoscerà sul perchè volete ciò che volete, tanto più essa sarà accomodante su qualunque cosa stiate proponendo.

Ciò va contro l'istinto—così facile ad acquisire così facile a scrollarsi di dosso—che la conoscenza è potere e quanto più gli altri conoscono dei vostri obiettivi, tanto più controllo hanno su di voi. Sostenendo pubblicamente la funzionalità (una correzione di un bug, o qualcos'altro) voi avete già gettato la carte sul tavolo. La sola questione ora è se avrete successo nel guidare la vostra comunità nel condividere il vostro obiettivo. Se voi semplicemente stabilite ciò che volete, ma non fornite esempi concreti sul perché, il vostro argomento è fiacco, e la gente comincerà a sospettare una agenda nascosta. Ma se voi fornite uno scenario di poche parole che mostri perché la nuova funzionalità è importante, allora potete avere un sensazionale effetto sul dibattito.

Per vedere perché la cosa sta così, considerate l'alternativa. Troppo frequentemente il dibattito sulle nuove funzionalità è lungo e noioso. Gli argomenti che le persone avanzano spesso si riducono a “Io personalmente voglio X” o il sempre popolare “Nei miei anni di esperienza come progettista di software X è estremamente importate per gli utenti / un inutile fronzolo che non piacerà a nessuno”. Prevedibilmente l'assenza di informazione nelle parole reali né accorciano né moderano tali dibattiti, ma invece permettono che essi vadano ala deriva lontano lontano da ogni ormeggio nella reale esperienza dell'utente. Senza una forza controbilanciante, il risultato finale molto verosimilmente non viene determinato da una persona che era la più chiara, o la più tenace, o la più anziana.

Come organizzazione con abbondanti dati disponibili sui clienti, avete la opportunità di fornire giusto questa forza bilanciante. Voi potete essere come una condotta per le informazione che potrebbero avere diversamente nessun mezzo per raggiungere la comunità di sviluppo. Il fatto che quella informazione può supportare i vostri desideri non costituisce nulla di imbarazzante. La maggior parte degli sviluppatori individualmente non ha una larga esperienza su come il codice che essi hanno scritto viene usato. Ogni sviluppatore usa il suo software nel suo modo caratteristico. Fin dove i modelli degli altri vanno, lui fa affidamento sull'intuizione e sulle ipotesi, e nel profondo del suo cuore, lui sa questo. Ma, fornendo dati credibili su un gran numero di utenti, voi date alla comunità di sviluppo pubblico qualcosa di simile all'ossigeno. Finché presenterete ciò nel modo giusto, essi gradiranno ciò entusiasticamente, e muoveranno le cose nella direzione che voi volete.

La chiave, certamente, è presentare la cosa ne modo giusto. Non lo fate mai insistendo che semplicemente per il fatto che avete a che fare con un gran numero di utenti e poiché essi hanno bisogno di una data funzionalità (o così voi credete), allora la vostra soluzione dovrebbe essere implementata. Invece voi dovreste focalizzare i vostri post iniziali sul problema, piuttosto che su una particolare soluzione. Descrivete in gran dettaglio l'esperienza che i vostri clienti stanno facendo, offrite quanta più analisi vi è possibile, e quante soluzioni voi potete pensare. Quando la gente incomincia a far congetture sull'efficacia delle varie soluzioni, voi potete continuare ad utilizzare i vostri dati per sostenere o rifiutare quello che dicono. Voi potete avere una soluzione in mente per tutto il tempo, ma non sceglietela per speciali considerazioni all'inizio. Questo non è inganno, questo è il comportamento standard dell'onesto mediatore. Dopotutto il vostro vero obiettivo è risolvere il problema; una soluzione è solo un mezzo per quel fine. Se la soluzione che voi preferite è veramente la migliore, gli altri sviluppatori lo riconosceranno dal loro canto alla fine—e allora vi andranno dietro di loro spontanea volontà, che è molto meglio che se voi li minacciaste a implementarla. (C'è anche la possibilità che essi abbiano in mente un soluzione migliore)

Con questo non si vuole dire che non potete mai dichiararvi a favore di una specifica soluzione. Ma dovete avere la pazienza di vedere l'analisi che avete già fatto internamente ripetuta nella mailing list dello sviluppo pubblico. Non postate “Noi abbiamo discusso ogni aspetto di questo problema , ma non funziona per il motivo A, B e C. Una volta che pensate realmente al problema, l'unico modo per risolverlo è...” Il problema non è tanto che ciò suona arrogante tanto da dare l'impressione che avete già edicato alcune sconosciute (me, la gente presumerà, grandi) quantità di risorse analitiche al problema, a porte chiuse. Esso fa sembrare ciò come se comunque gli sforzi sono stati fatti, forse le decisioni sono state prese, che il pubblico non è informato, e che è una ricetta per il risentimento.

Naturalmente, voi sapete quanto sforzo avete internamente dedicato al problema, e quella consapevolezza è, in un cero modo, uno svantaggio. Ciò mette i vostri sviluppatori un uno spazio un pochino differente rispetto ad ogni altro nella mailing list, riducendo la loro abilità a vedere le cose dal punto di vista che non hanno ancora tanto pensato al problema. Prima potete indurre ogni altro a pensare alle cose negli stesi termini in cui lo fate voi, più piccolo sarà l'effetto di questa distanza. Questa logica non si applica solo a individuali situazioni tecniche, ma al più largo mandato di rendere i vostri obiettivi più chiari che potete. L'ignoto è sempre più destabilizzante del noto. E la gente capisce perché volete ciò che volete, essi si sentiranno a loro agio parlandovi anche quando sono in disaccordo. Se essi non possono capire ciò che vi fa fare tic, presupporranno il peggio, almeno alcune volte.

Non sarete capaci di pubblicare ogni cosa, e la gente non si aspetterà ciò. Tutte le organizzazioni hanno segreti, forse quelle con fini di profitto ne hanno di più, ma quelle noprofit ne hanno pure. Se dovete difendere un certo corso, ma non rivelate nulla sul perché, allora semplicemente offrite i migliori argomenti che potete impediti da quello svantaggio e accettate il fatto che non potete avere l'influenza che volete in quella discussione. Questo è uno dei compromessi che dovete fare per non avere la comunità di sviluppo sul vostro libro paga.