Se tan abierto sobre los objetivos de tu organización como puedas sin comprometer tus secretos industriales. Si quieres que el proyecto adopte cierta funcionalidad por que, digamos, tus clientes lo han solicitado, simplemente manifiestalo en la lista de correo. Si los clientes prefieren permanecerr anónimos, como es en algunos casos, entonces por lo menos pregúntale si pueden proveer casos anónimos como ejemplo. Entre más sepa la comunidad de desarrollo por qué quieres lo que quieres, más tolerante será de lo que propongas.
Al contrario del instinto—tan fácil de adquirir, tan difícil de de soltar—la información es poder, y entre más otras personas sepan de tus metas, más control tendrán sobre ti. Sin embargo, esa creencia es erronea aquí. Al públicamente solicitar una funcionalidad ( o arreglo del bug, o lo que sea), ya has puesto tus cartas sobre la mesa. La única pregunta ahora es si tendrá éxito guiando a la comunidad a compartir tus metas. Si solo quieres decir lo que quieres, pero no puedes proveer un ejemplo concreto del por que, tu argumento será débil y las personas comenzarán a sospechar de una agenda oculta. Pero si das algunos escenarios concretos mostrando porque la funcionalidad es importante, se puede alcanzar un efecto dramático en el debate.
Para ver por que esto es así, considera las alternativas. Muy frecuentemente, debates sobre nuevas funcionalidades o nuevas direcciones son largos y tediosos. Los argumentos que la gente proclama, usualmente, se reducen a "Yo quiero X", o el muy popular "En mis años de experiencia como diseñador de software, X es extremadamente importante a los usuarios / es algo inútil que no convencerá a nadie." La predictabilidad, de ausencia de datos del mundo real afecta estos debates, pero en vez de permitir que se aparten más y más de cualquier vínculo debe realizarse con usuarios de verdad. Sin ninguna fuerza de contrapeso, el resultado final probablemente no será determinado por quien sea más articulado, o persistente o el que tenga más antiguedad.
Como una organización con datos disponibles de muchos clientes, tienes la oportunidad de proveer solo como una fuerza de contrapeso. Puede ser un conducto para información que puede de otra manera no tener medios de alcanzar a la comunidad de desarrollo. El hecho es que la información le dará soporte a tus deseos y no hay que sentir verguenza por esto. Muchos desarrolladores no cuentan con mucha experiencia individual sobre como su software es usado. Cada desarrollador usa el software en su propia idiosincracia; tanto como sus patrones de uso vayan, ellos se apoyan en la intuición y adivinanza, y muy en el fondo están concientes de esto. Al proveer con datos factibles sobre una cantidad amplia de usuarios, está dando a la comunidad de desarrollo algo que ellos necesitan como el oxígeno. Mientrás sea presentado de la forma correcta, ellos permitirán de forma entusiasta, y empujarán en el camino al que quieras ir.
La clave, desde luego, es presentarlo correctamente. Nunca ayudará insistir que simplemente porque tratas con una gran cantidad de usuarios, y porque ellos necesitan (o piensas que necesitan) cierta funcionalidad, por eso tu solución deberá ser implementada. Al contrario, deberás enfocar tus publicaciones iniciales en el problema, en vez de una solución particular. Describe en gran detalle la experiencia que tus clientes están encontrando, ofrece todos los análisis que tengas, y todas aquellas soluciones razonables que se te puedan ocurrir. Cuando las personas comiencen a especular sobre la eficiencia de diversas soluciones, puedes continuar indicando con tus datos como apoyar o rechazar lo que se comente. Podrás tener una solución particular en mente desde el inicio, pero no la aisles como si se debiera dar consideración especial. Esto no es manipulación, simplemente comportamiento de "corredor honesto". Después de todo, tu verdadera meta es resolver el problema; una solucion es solamente los méritos a un fin. Si la solución que prefieras realmente es superior, otros desarrolladores reconocerán que en su propia eventualidad—y lo apoyarán en propio convencimiento, de que es mejor que forzar a que todos implementen tu solución. (También está la posibilidad que ellos piensen en una mejor solución.)
Esto no significa que nunca podrás salir en defensa de una solución específica. Pero deberás tener la paciencia para ver que el análisis que has hecho internamente se repetirá en las listas de desarrollo público. No envies mensajes diciendo "Sí, eso ya lo probamos, pero no funciona por que A, B, y C. Al final, la única forma de resolverlo es ..." El problema no es tanto que suene arrogante sino que da la impresión de que ya se ha dedicado algún tiempo a lo desconocido pero, la gente pensará que una gran cantidad de recursos analíticos al problema, fue realizado a puertas cerradas. Esto hace que parezca que el esfuerzo ya se hizo y la decisión fue tomada, que el público no es digno de saberlo y esto puede dar un sentido de resentimiento.
Naturalmente, usted sabrá que tanto esfuerzo habrá dedicado al problema internamente, y que el saberlo es, en cierta forma una desventaja. Esto pone a sus dearrolladores en un pensamiento diferente al de los demás en la lista de correo, reduciendo sus habilidades para darse cuenta de otros puntos de vista que no han tenido tiempo de reflexionar sobre el problema. Entre más rápido pueda usted ponerse a pensar de la misma manera, menor será la variación de efectos que tendrá. Esta lógica aplica no solo a las situaciones técnicas individuales, pero también al mandato tan claras como sea posible. Lo desconocido es siempre más desestabilizador que lo conocido. Si la gente entiende el por que lo desea, se sentirán mas comodos hablando con usted aun cuando no esten de acuerdo. Si no pueden entender lo que lo motiva, ellos asumiran lo peor en ciertos momentos por lo menos.
Probabemente no podrá publicar todo, desde luego, y las personas no esperan que lo haga. Todas las organizaciones tienen secretos; quizas las de lucro tengan más, pero las sin fines de lucro, tambien las tienen. Si debes promover un cierto curso, pero no puede revelar sus razones, entonces simplemente ofrezca los mejores argumentos bajo esta desventaja, y acepte el hecho que quizás no tenga tanta influencia como penso que tenía en la discusión. Esto es uno de los compromisos que tendrá que hacer por haber desarrollado una comunidad fuera de su lista de empleados.