Tabla de contenidos
Conseguir que la gente se ponga de acuerdo sobre cuales son las necesidades de un proyecto, y trabajar en la misma dirección para llevarlas a cabo, requiere de algo más que un ambiente de trabajo genial sin disfunciones visibles. Requiere una, o varias personas, que coordinen diligentemente a toda la gente involucrada en el proyecto. Es posible que coordinar voluntarios no sea un arte tecnológico como lo pueda ser la programación, pero como cualquier arte puede mejorarse a través del estudio y la práctica.
Este capítulo es un cajón de sastre de técnicas para coordinar voluntarios. Se nutre, quizá más intensamente que capítulos anteriores, en el proyecto Subversion, en parte porque yo trabajaba en dicho proyecto mientras escribía esto y tenía información de primera mano, y en parte porque es más aceptable tirar piedras sobre mi propio tejado que sobre el tejado de otro. No obstante, también he sido testigo de las consecuencias que ha tenido aplicar sobre otros proyectos (y las consecuencias de no hacerlo) las recomendaciones que se exponen a continuación. Siempre que sea políticamente correcto dar detalles de otros proyectos, así lo haré.
Hablando de política, este momento es tan bueno como cualquier otro para inspeccionar en detalle la susodicha palabra maldita. Muchos ingenieros hablan de política como si no fuera con ellos; "Yo me centro en la mejor para el proyecto, pero Ella no deja de poner pegas por razones políticas." Pienso que dicho distanciamiento de la política (o por lo que se piensa que es la política) es especialmente significativo entre los ingenieros, porque se los educa para pensar que siempre hay razones objetivas para determinar que unas soluciones son superiores a otras. Por tanto, cuando alguien actúa con motivaciones aparentemente externas al proyecto (p.ej. solidificar la propia posición de influencia en el proyecto, disminuir la influencia de otros, chalaneos descarados, o evitar herir los sentimientos de alguien) otros participantes del proyecto pueden molestarse. Por supuesto, esto raramente evita que ellos se comporten de la misma manera cuando sus propios intereses se ven amenazados.
Si consideras que la "política" es una palabra sucia, y tienes esperanzas de mantener tu proyecto libre de ella, mejor que abandones ahora mismo. La política es algo que surge inevitablemente cada vez que un grupo de personas han de cooperar en la gestión de recursos compartidos. Es de lógica que, cada vez que una persona toma una decisión, ésta se vea influenciada por cómo va a afectar a su futuro personal en el proyecto. Después de todo, si tienes confianza en tu juicio y habilidades, como sucede con la mayoría de programadores, entonces una posible pérdida de influencia sobre el proyecto podría ser considerada, en cierta manera, como un aspecto técnico a tener en cuenta. Razonamientos similares se pueden aplicar a comportamientos que, en apariencia, sean "pura" política. De hecho, no existe tal cosa como la "pura política"; para empezar, porque como todas las acciones tienen múltiples consecuencias en la vida real la gente adquiere conciencia política. La política, al final, simplemente reconoce que todas las consecuencias de nuestras decisiones han de tenerse en cuenta. Si decisiones concretas llevan el proyecto por un camino que la mayoría considera técnicamente correcto, pero dicha decisión conlleva un cambio en el equilibrio de influencias del proyecto aislando a figuras clave del mismo, entonces hemos de dar igual grado de importancia a ambas consecuencias. No hacerlo así, no sólo no sería juicioso, sino que sería una actitud corta de miras.
Por tanto, mientras leas los consejos que siguen a continuación, y mientras trabajas en tu propio proyecto, recuerda que no hay nadie que esté por encima de la política. Dar la impresión que se está por encima de ella es simplemente otra estrategia política más y, por cierto, en ocasiones una muy útil, pero nunca refleja la realidad. La política es sencillamente lo que sucede cuando la gente no está de acuerdo en algo, y los proyectos que acaban con éxito son aquellos capaces de desarrollar un mecanismo político para gestionar los desacuerdos de forma constructiva.
Por qué los voluntarios trabajan en proyectos de software libre? [34]
Cuando se les pregunta, muchos dicen que lo hace por que quieren producir buen software, o por que quieren involucrarse en arreglar errores que son importantes para ellos. Pero estas razones no acostumbran a ser toda la verdad. Después de todo ¿podrías imaginarte a un voluntario permaneciendo en un proyecto a pesar de que nadie, nunca, le dirigiera un palabra de aprecio por su trabajo, o se le escuchara en las discusiones? Claro que no. Claramente, la gente gasta su tiempo en el software libre por razones que van más allá del deseo abstracto de producir buen código. Comprender las verdaderas motivaciones de los voluntarios te ayudará a organizar las cosas de manera que puedas atraerlos y que no se vayan. El deseo de producir buen código puede estar entre esas motivaciones, junto con el desafío y valor educativo que supone trabajar en problemas difíciles, pero los seres humanos tienen el deseo natural de trabajar con otros humanos, y el de dar y recibir respeto a través de actividades colectivas. Grupos cooperando en tareas colectivas deben desarrollar normas de comportamiento tales que el prestigio sea adquirido ,y mantenido, a través de acciones que ayuden a la consecución de las metas del grupo.
Esas normas no aparecen por sí solas. Por ejemplo, en algunos proyectos (desarrolladores con experiencia en código abierto podrían mencionar varias de memoria) la gente piensa que se gana prestigio por enviar largos mensajes frecuentemente. No llegan a esta conclusión por casualidad, llegan a ella porque son recompensados con respeto por crear largos e intrincados argumentos, independientemente de que estos ayuden al proyecto. A continuación se explican algunas técnicas para crear una atmósfera en la que se pueda adquirir prestigio a través de acciones constructivas.
Delegar no simplemente una forma de distribuir la carga de trabajo, sino que también es una herramienta política y social. Piensa en todas las consecuencias que tiene pedir a alguien que haga algo. El efecto más evidente es que, si acepta, esa persona hace el trabajo y tú no. Pero otro efecto es que esa persona toma consciencia de que tú confías en él para realizar la tarea. Además, si haces la petición en un foro público, también aprecia que el resto de participantes son conscientes de la confianza que ha sido depositada en él. También es posible que se sienta presionado a aceptar, por tanto has de preguntar de manera que le sea fácil declinar la oferta si realmente no quiere aceptarla. Si la tarea requiere coordinarse con otros participantes del proyecto, entonces le estás pidiendo un mayor grado de compromiso con el proyecto, crear lazos que no se hubieran creado de otra forma y, quizá, convertirse en una fuente de autoridad y algunos subdominios del proyecto. La responsabilidad adquirida puede ser agobiante, o puede llevarle a involucrarse en más áreas del proyecto gracias a un renovado sentimiento de compromiso.
Debido a todos estos posibles efectos, a menudo tiene sentido pedir a otro que haga algo incluso cuando sabes que tú lo podrías hacer mejor o más rápido. Por supuesto, siempre hay momentos en que delegarás únicamente por motivos de eficiencia; quizá el coste de oportunidad de hacer una tarea tú mismo es demasiado alto debido a que podrías dedicarte a hacer algo más importante para el proyecto. Pero incluso cuando el argumento del coste de oportunidad no existe, aún así es posible que pidas a otro hacer una tarea simplemente porque quieres involucrar más a una determinada persona en el proyecto, incluso si eso significa que has de supervisar su trabajo al principio. Esta técnica también funciona al revés; si ocasionalmente te presentas voluntario para hacer un trabajo que alguien no quiere, o no tiene tiempo de hacer, te ganarás su confianza y su respeto. Delegar y sustituir no tiene que ver simplemente con finalizar tareas; tiene mucho que ver también con aumentar el grado de compromiso de la gente con el proyecto.
En ocasiones es lógico esperar que una persona aceptará de buen grado una tarea en particular. Por ejemplo, si alguien introduce un error en el código, o envía código que incumple de forma clara con las directrices del proyecto, debería ser suficiente con mencionar el problema y esperar que el responsable de dicho código se haga cargo. Pero hay otras situaciones donde no está nada claro que puedas esperar que alguien haga cargo. La persona podría hacer lo que le pides, o quizá no. Como a nadie le gusta que se dé por hecho que va a obedecer, has de ser consciente en todo momento de cual de estas dos situaciones estás tratando y, en función de la misma, medir tus palabras a la hora de solicitar una tarea.
Algo que casi siempre sienta mal es que te pidan hacer algo como si fuera tu responsabilidad cuanto tu piensas que no es así. Por ejemplo, asignar nuevos problemas en el código es terreno abonado para este tipo de situaciones. Los participantes de un proyecto normalmente saben quien es experto en cada área, así que cuando un error en el código aparece, habrá normalmente una o dos personas en las que todo el mundo piensa que podrían arreglar el problema rápidamente. No obstante, si asignas la tarea a una de estas personas sin pedirles permiso, dicha persona podría sentirse incómoda y forzada a encargarse de la tarea, podría sentir que se espera mucho de ella y que, de alguna forma, está siendo castigada por sus conocimientos y experiencia. Después de todo, la forma en la que uno adquiere dichas habilidades es corrigiendo código, así que ¡quizá debería ser otro el que lo corrija esta vez! (Cabe mencionar que los gestores automáticos de errores que asignan tareas en función del tipo de error, reducen este tipo de conflictos porque todo el mundo sabe que las tareas se asignan de forma automática y que nadie espera nada de la persona a la que se ha asignado la tarea.)
Aunque lo deseable sería distribuir la carga de trabajo tan equitativamente como fuera posible, hay ocasiones en las que simplemente quieres que puede arreglar el problema más rápidamente haga el trabajo. Dado que no puedes permitirte establecer un diálogo para todas y cada una de las tareas que se han de asignar ("¿Te importaría echarle un vistazo a este error?" "Sí." "Vale, entonces te asigno la tarea a ti." "Vale."), deberías siempre asignar tareas en forma de petición, sin ejercer presión alguna. Casi todos los gestores de errores permiten asociar comentarios a la tarea asignada. En dicho comentario podrías decir algo así:
Tarea asignada a ti, jaleatorio, porque tu eres la persona más familiarizada con este código. No te preocupes si no puedes hacerte cargo de la tarea por el motivo que sea. (En cualquier caso hazme saber si preferirías no recibir más tareas en el futuro.)
Así se distingue claramente la petición de la tarea de la aceptación de la misma. El mensaje no sólo va dirigido a la persona a la que se pide la tarea; informa a todo el grupo del área de experiencia de dicho miembro y, además, deja claro a todos que dicha persona es libre de aceptar o rechazar la tarea.
Cuando le pidas a alguien que haga algo, recuerda que los has hecho y supervisa con él la tarea pase lo que pase. La mayoría de peticiones se hace en foros públicos más o menos de la siguiente manera "¿Podrías encargarte de X? Dinos algo en cualquier caso. En caso de que no puedas no pasa nada, pero háznoslo saber." Pueden responder, o no, a tu petición, pero si te responden, y la respuesta es negativa, el proceso se cierra y tendrás que buscar alternativas para llevar a cabo la tarea X. Si la respuesta es positiva entonces vigila como progresa el trabajo y haz comentarios sobre el mismo (todo el mundo trabaja mejor cuando sabe que hay alguien que aprecia su trabajo). Si no hay respuesta después de unos días, pregunta de nuevo, o comenta en el foro que nadie a respondido y que buscas a alguien que ses encargue de la tarea, o simplemente hazlo tú pero, en cualquier caso, asegúrate de comentar que no recibiste respuesta alguna a tu petición"
El motivo de hacer pública la falta de respuesta no es para humillar a la persona a la que se le hizo la petición, y cuando menciones el tema lo has de hacer de forma que esto quede claro. El propósito es de dejar claro que sigues la pista de todo lo que pides, y que reaccionas ante las respuestas que recibes, o no, a tus peticiones. Esta actitud hace que sea más probable que la gente acepta la tarea la próxima vez, y esto es así porque se darán cuenta (aunque sea inconscientemente) que es probable que aprecies cualquier trabajo que hagan debido a que prestas atención a detalles tan pequeños como el que alguien no responda a una petición.
Otra cosa que pone a la gente contenta es que te fijes en sus intereses; en general, cuantos más aspectos recuerdas de la personalidad de alguien, más a gusto se encontrará dicha persona, y se interesará más por trabajar en grupos de los que tú seas parte.
Por ejemplo, había una clara diferencia en el proyecto Subversion entre la gente que quería llegar pronto a una versión final 1.0 (cosa que finalmente hicimos), y la gente que principalmente quería añadir nuevas funcionalidades y trabajar en problemas interesantes sin importarles mucho cuando estaría lista la versión 1.0. Ninguna de estas dos posturas es mejor o peor que la otra; simplemente reflejan dos tipos distintos de desarrolladores, y ambos realizan mucho trabajo en el proyecto. Pero aprendimos rápidamente que era vital no asumir que el interés por tener una versión 1.0 era compartido por todos. Las comunicaciones electrónicas pueden ser muy engañosos; puedes pensar que hay un ambiente de propósito común cuando, en realidad, dicho propósito sólo es compartido por la gente con la que tú has estado hablando, mientras otras personas tienen prioridades completamente distintas
Cuanto más consciente seas de lo que la gente quiere sacar del proyecto, más eficientemente podrás pedirles cosas. Simplemente demostrando comprensión por lo que quieren, sin demandar nada por ello, tiene una utilidad per se, puesto que confirma a cada uno que no es una simple partícula de una masa informe.
Halago y crítica no son antónimos, de hecho, en muchos aspectos son muy similares. Ambas son muestras de atención, y son más efectivas cuando son específicas que cuando son genéricas. Ambas deben hacerse con metas específicas en mente. Ambas pueden diluirse por el abuso; halaga mucho o demasiado y tus halagos perderán valor, y lo mismo sirve para las críticas aunque, en la práctica, las críticas provocan reacciones que las hacen mucho más resistentes a la devaluación.
Un importante aspecto de la cultura tecnológica es que la detallada y desapasionada crítica a menudo se toma como una especia de alago (como se vio en “Reconociendo la grosería” en Capítulo 6, Comunicaciones), esto se debe a la implicación de que el trabajo en cuestión vale la pena ser analizado. En cualquier caso, ambos aspectos; detallada y desapasionada han de cumplirse para que esto se cumpla. Por ejemplo, si alguien hace algún cambio chapucero en el código, es inútil (y de hecho perjudicial) comentar el asunto simplemente diciendo "Eso es una chapuza". El ser un chapuzas es, al final, una característica de la persona, no de su trabajo, y es importante mantener tu atención enfocada en el trabajo hecho. Es mucho más eficiente describir todas las cosas equivocadas que se han introducido al realizar el cambio, y hay que hacerlo con tacto y sin malicia. Si fuera el tercer o cuarto cambio descuidado de la misma persona, entonces lo más apropiado mencionar el hecho, después de la crítica sobre el trabajo realizado, y de nuevo sin ningún signo de enfado, para así dejar claro que dicho patrón de comportamiento es evidente.
Si alguien no mejora después de las críticas, la solución no es criticar más, o hacerlo más duramente. La solución consiste en que el grupo retire a dicha persona del trabajo en el que es incompetente de forma que se hiera lo menos posible los sentimientos de la misma, leed “Transiciones” al final del capítulo unos ejemplos. En cualquier caso, este no es un hecho frecuente. La mayoría de gente responde muy bien a las críticas que son específicas, detalladas, y que contienen una clara (aunque sea entre líneas) indicación de que se espera una mejora.
Las alabanzas no herirá la sensibilidad de nadie, por supuesto, pero eso no significa que se deba usar con menos cuidado que las críticas. Las alabanzas son una herramienta; antes de usarla pregúntate por qué quieres usarla. Como regla, no es una buena idea alabar a alguien por hacer lo que normalmente hace, o por acciones que son habituales y esperadas de alguien que trabaja en grupo. Si hicieras eso, no será fácil saber cuando parar; ¿deberías alabar a todo el mundo por hacer lo habitual? Al fin y al cabo, si te dejas a alguien se preguntarán por qué. Es mucho mejor expresar alabanzas y gratitud ocasionalmente en respuesta a un esfuerzo inusual, o inesperado, con la intención de fomentar dichos esfuerzos. Cuando un participante parece haberse trasladado permanentemente a un estado de alta productividad, debes ajustar tu nivel de alabanzas consecuentemente. Repetidas alabanzas se acaban convirtiendo en algo sin significado alguno. En su lugar, dicha persona deber sentir que su alto nivel de productividad se considera normal y natural, y sólo trabajo que sobrepasa ese nivel debe ser significado.
Por supuesto, esto no quiere decir que las contribuciones de dicha persona no deban ser reconocidas. Pero recuerda que si el proyecto se organiza correctamente, todo lo que hace una persona es visible de todas formas, y por tanto el grupo verá (y la persona implicada sabrá que el resto de miembros lo ven también) todo lo que ella hace. También hay otras maneras de reconocer el trabajo de alguien además de las alabanzas. Podrías mencionar de pasada, al debatir sobre un tema, que dicha persona ha trabajado mucho en ese área y que es experta en la misma. Podrías realizar consultas públicas a dicha persona sobre el código o, quizá mejor, podrías utilizar su trabajo de forma ostensible para que la persona pueda apreciar que la gente tiene confianza en los resultados de su trabajo. Probablemente no es necesario hacer todas estas cosas de forma calculada. Las personas que contribuyen notablemente lo saben y ocuparán una posición de influencia de forma natural. Normalmente no hay que tomar medidas explícitas para asegurar esto, a menos que sientas que, por cualquier motivo, un miembro del grupo es poco valorado.
Ten cuidado con los participantes que intentan apropiarse la exclusividad en ciertas áreas del proyecto, y con aquellos que parecen querer hacer todo el trabajo en esas áreas hasta el punto de apropiarse del trabajo que otros han comenzado. Dicho comportamiento puede parecer saludable al principio, después de todo, a primera vista parece como si el individuo en cuestión simplemente está tomando más responsabilidad, y mostrando una mayor actividad en dichas áreas. A la larga, no obstante, dicho comportamiento es destructivo. Cuando la gente ve señales de "no pasar" se apartan del proyecto. Esto conlleva una visión más estrecha de esa área, y una mayor fragilidad de la misma puesto se depende de la disponibilidad e un único desarrollador. Todavía peor, rompe el espíritu de cooperación igualitaria del proyecto. En teoría, la ayuda de cualquier desarrollador debe ser bienvenida en cualquier momento, y sobre cualquier área. Por supuesto, en la práctica las cosas funciona de manera algo diferente; la gente tiene áreas donde es más o menos influyente, y los inexpertos habitualmente dejan que los expertos tomen las riendas en ciertos dominios del proyecto. Pero la clave es que todo esto es algo voluntario; la autoridad se gana mediante la competencia y conocimiento probado, y nunca debe ser conquistada activamente. Incluso si la persona deseando la autoridad es realmente competente, aún así es crucial que maneje esa autoridad de manera informal, a través del consenso del grupo, y sin apartar a nadie de colaborar en su área de influencia.
Por supuesto, rechazar o editar el trabajo de otro por motivos técnicos es un asusto totalmente distinto. En este caso, el factor decisivo es el contenido del trabajo, no quien actúa como portero. Podría suceder que la misma persona realice la mayor parte de revisiones para un área particular, pero mientras no evite que otros hagan su trabajo, las cosas deberían ir bien.
Para combatir cualquier territorialismo incipiente, o incluso la mera apariencia del mismo, muchos proyectos han tomado medidas como la de prohibir la inclusión del nombre del autor, o de los encargados elegidos, en el código fuente. Yo estoy de acuerdo de todo corazón con esta práctica; la utilizamos en el proyecto Subversion y es, más o menos, la política oficial en la Apache Software Foundation. El miembro del ASF Sander Striker lo explica de esta forma:
en la Apache Software Foundation desaconsejamos el uso de entradas con el nombre del autor en el código fuente. Hay varias razones para esto además de motivos legales. En el desarrollo en equipo se trata de trabajar en grupo y tratar al proyecto en grupo. Dar crédito es bueno, y debe hacerse, pero de alguna manera esta forma de actuar evita falsas atribuciones, incluso cuando sólo son implícitas. No hay una directriz clara de cuando se ha de añadir o quitar entradas con el nombre del autor; ¿Añades tu nombre si cambias un comentario? ¿Cuando arreglas una sola línea de código? ¿Has de borrar el nombre de alguien cuando reestructuras el código y es diferente al anterior en un 95%? ¿Qué haces con la gente que va tocando cada archivo, cambiando lo mínimo para que su nombre aparezca en todas partes?
Hay mejores formas de dar crédito, y nosotros preferimos usar esas. Desde un punto de vista técnico las entradas con el nombre del autor son innecesarias; si quieres saber quién escribió una determinada línea de código se puede consultar el sistema de control de versiones para averiguarlo. Además, las entradas de autor acostumbran a estar caducadas; ¿Realmente quieres que se pongan en contacto contigo por unas líneas de código que programaste hace cinco años y estás contento de haberlas olvidado?
El corazón de la identidad de un proyecto lo forman los archivos con el código fuente. Estos deben reflejar que la comunidad, como un todo, es responsable de los mismos, y no deben dividirse en pequeños feudos.
La gente a veces defiende las entradas de autor en el código fuente argumentando que dan crédito de forma visible a aquellos que han realizado más trabajo. Hay dos problemas con este argumento. Primero, las entradas de autor traen consigo la incómoda pregunta de cuánto trabajo se ha de realizar para que tu nombre también aparezca en el archivo. Segundo, las entradas fusiona la autoridad en un área con el crédito en la misma; haber hecho la mayor parte del trabajo en un área no implica que se posea dicha área, pero es difícil, sino imposible, evitar dicha implicación cuando hay nombres de personas al comienzo de un archivo de código fuente. En cualquier caso, se puede saber el autor del código a través del sistema de control de versiones u otros métodos alternativos como los archivos de las listas de correos, de esta forma no se pierde ninguna información al no permitir las entradas de autor en el código fuente.
Si en tu proyecto se decide no permitir incluir entradas de autores
en el código fuente, asegúrate de no pasarte de la raya. Por ejemplo,
muchos proyectos tienen un área contrib/ donde se
almacenan pequeñas herramientas y scripts de ayuda, a menudo escritos
por gente que no están asociados con el proyecto de ninguna otra manera.
Para ese tipo de archivos está bien que se introduzca los nombres de los
autores porque ellos no están desarrollando el proyecto en sí. Por otro
lado, si una de estas herramientas comienza a ser alterada por otros
miembros del proyecto, puede que al final quieras trasladar dicha herramienta
a un lugar menos aislado y, suponiendo que el autor original aceptara,
borrar los nombres de los autores para que el archivo siga la política
del resto de archivos del proyecto. Si el autor original no se siente
a gusto con esta iniciativa se pueden alcanzar acuerdos, por ejemplo:
# indexclean.py: Borrar datos viejos del índice Scanley. # # Autor Original: K. Maru <kobayashi@yetanotheremailservice.com> # Gestionado Ahora Por: The Scanley Project <http://www.scanley.org/> # and K. Maru. # # ...
Pero, dentro de lo posible, es mejor evitar dichos compromisos, además, la mayoría de autores están dispuestos a ser persuadidos puesto que se sienten felices de que su contribución pase a ser parte integral del proyecto.
Lo importante es recordar que hay una continuidad entre el centro y la periferia de cualquier proyecto. Los archivos del código fuente del software son claramente centrales en el proyecto, y deben ser gestionados por la comunidad en su conjunto. Por otro lado, herramientas accesorias, o documentación, pueden ser el resultado del trabajo de un solo individuo, y lo puede gestionar él solo aunque su trabajo esté asociado, en incluso distribuido, con el proyecto. En cualquier caso, no hay necesidad de aplicar la misma regla a todos los archivos siempre y cuando los recursos comunitarios sean gestionados por todos, y no puedan convertirse en conto privado de nadie.
Intenta evitar que los humanos hagan lo que pueden hacer las máquinas en su lugar. Como regla general, automatizar una tarea común supone un esfuerzo diez veces menor al esfuerzo que le supondría al desarrollador realizar la tarea a mano. Para tareas muy frecuentes, o muy complejas, el ratio puede ser veinte veces superior e incluso mayor.
Verte a ti mismo como a un "Director de Proyecto", en lugar de como a un desarrollador, puede llegar a ser una actitud positiva. A veces, algunos desarrolladores están demasiado enfrascados en su trabajo a bajo nivel, esto no les permite tener una visión general del proyecto y darse cuenta de que todo el mundo está desperdiciando mucho esfuerzo en realizar tareas manualmente que podrían muy bien automatizarse. Incluso aquellos que sí se dan cuenta, pueden no tomarse el tiempo para resolver el problema, al fin el al cabo, el rendimiento de cada individuo para realizar dicha tarea no es una carga demasiada onerosa, nadie se siente lo suficientemente molesto como para hacer algo al respecto. La automatización se hace atractiva cuando se tiene en cuenta que, esa pequeña carga, se multiplica por el número de veces que cada desarrollador ha de realizarla, y entonces ese número se múltiplica por el número de desarrolladores.
Aquí estoy utilizando la palabra "automatización" con un sentido muy amplio queriendo dar a entender, no sólo acciones repetitivas donde una o dos variables cambian cada vez, sino también cualquier tipo de infraestructura técnica que ayude a los humanos. La mínima automatización estándar necesaria para llevar a cabo un proyecto en nuestros días fue descrita en Capítulo 3, Infraestructura Técnica, pero cada proyecto puede tener sus propios problemas especiales. Por ejemplo, un grupo trabajando en la documentación quizá quiera una página web que muestre las versiones más actualizadas del documento en todo momento. Como la documentación se redacta normalmente en lenguajes del estilo de XML, puede haber un paso de compilación, a menudo bastante intrincado, relacionado con la creación de documentos para que puedan ser mostrados o bajados de la red. Crear un página web donde esa compilación tenga lugar automáticamente en cada envío puede ser bastante complejo y llevar mucho tiempo—pero vale la pena, incluso si te lleva uno o más días configurarla. Los beneficios globales de tener páginas actualizadas disponibles en todo momento son enormes, incluso si el coste de no tenerlas pueda parecer una simple molestia en un momento dado, para un desarrollador cualquiera.
Seguir estos pasos no sólo elimina las pérdidas de tiempo, sino también las obsesiones y frustraciones que aparecen cuando los humanos cometen errores (inevitablemente lo harán) al intentar realizar procedimientos complicados manualmente. Las tareas con múltiples pasos y operaciones deterministas son el tipo de cosas para las que se inventaron las computadoras, y así dejamos que los humanos hagan cosas más interesantes.
Ejecutar pruebas automáticas es muy útil para cualquier proyecto de software, pero especialmente para proyectos de código abierto porque las pruebas automáticas (especialmente las pruebas de regresión) permiten que los desarrolladores se encuentren a gusto a la hora de cambiara código en áreas en las que no están familiarizados y, así, se favorece el desarrollo de exploración. Como es muy difícil detectar fallos a simple vista—básicamente has de adivinar dónde alguien puede haberse equivocado y realizar varios experimentos para asegurarte de que no lo hizo—tener métodos automáticos para detectar dichos errores ahorra muchísimo tiempo. También hace que la gente se relaje a la hora de refactorizar grandes franjas de código y, por lo tanto, contribuye a que el software pueda ser gestionado a largo plazo.
Las pruebas de regresión no son un panacea. Por un lado funciona bien para programas que tienen un estilo de interfaz de lineas de comando. El software que se utiliza principalmente através de una interfaz gráfica es mucho más difícil de utilizar mediante otro programa. Otro problema radica en que la estructura misma de la colección de pruebas puede ser muy compleja, con una curva de aprendizaje y cargas de mantenimiento propias. Reducir esta complejidad es una de las cosas más útilies que puedes hacer, incluso si ello implica una cantidad de tiempo considerable. Cuanto más fácil sea añadir nuevas pruebas a la colección, más desarrolladores lo harán, y menos errores sobrevivirán a la versión final. Cualquier esfuerzo empleado en que la creación de pruebas sea sencilla redundará con intereses en el desarrollo del proyecto.
Muchos proyectos siguen la regla "¡No rompas el código!" , queriendo decir: no envíes cambios que hagan que sea imposible compilar o ejecutar el software. Ser la persona que rompe el código es normalmente causa de cierta vergüenza y burla. Proyectos con colecciones de pruebas de regresión tienen amenudo una nueva regla a modo de corolario: no envíes ningún cambio que hagan fallar las pruebas. Dichos fallos son más fáciles de identificar si se realizan ejecuciones automáticas cada noche de toda la colección de pruebas, con los resultados enviados por email a los desrrolladores o a listas de correo dedicadas al efecto; este es otro ejemplo de automatización que vale la pena.
La mayoría de los desarrolladores voluntarios están dispuestos a tomar el tiempo adicional para escribir pruebas de regresión, cuando el sistema de pruebas es comprensible y fácil de trabajar. Acompañar modificaciones con pruebas es entendido como una responsabilidad de hacerlo, y es también una oportunidad fácil para la colaboración: a menudo los desarrolladores dividen el trabajo para corregir un fallo, uno de ellos corrige, y el otro escribe el ejemplo de prueba. El segundo desarrollador puede terminar con más trabajo, y aunque escribir un ejemplo de prueba es menos satisfactorio que corregir realmente el fallo, es imprescindible que el conjunto de pruebas no haga la experiencia más dolorosa de lo que debe ser.
Some projects go even further, requiring that a new test
accompany every bugfix or new feature. Whether
this is a good idea or not depends on many factors: the nature of the
software, the makeup of the development team, and the difficulty of
writing new tests. The CVS (cvs.nongnu.org/)
project has long had such a rule. It is a good policy in theory,
since CVS is version control software and therefore very risk-averse
about the possibility of munging or mishandling the user's data. The
problem in practice is that CVS's regression test suite is a single
huge shell script (amusingly named sanity.sh),
hard to read and hard to modify or extend. The difficulty of adding
new tests, combined with the requirement that patches be accompanied
by new tests, means that CVS effectively discourages patches. When I
used to work on CVS, I sometimes saw people start on and even complete
a patch to CVS's own code, but give up when told of the requirement to
add a new test to sanity.sh.
It is normal to spend more time writing a new regression test than on fixing the original bug. But CVS carried this phenomenon to an extreme: one might spend hours trying to design one's test properly, and still get it wrong, because there are just too many unpredictable complexities involved in changing a 35,000-line Bourne shell script. Even longtime CVS developers often grumbled when they had to add a new test.
This situation was due to a failure on all our parts to consider the automation ratio. It is true that switching to a real test framework—whether custom-built or off-the-shelf—would have been a major effort.[35] But neglecting to do so has cost the project much more, over the years. How many bugfixes and new features are not in CVS today, because of the impediment of an awkward test suite? We cannot know the exact number, but it is surely many times greater than the number of bugfixes or new features the developers might forgo in order to develop a new test system (or integrate an off-the-shelf system). That task would only take a finite amount of time, while the penalty of using the current test suite will continue forever if nothing is done.
The point is not that having strict requirements to write tests is bad, nor that writing your test system as a Bourne shell script is necessarily bad. It might work fine, depending on how you design it and what it needs to test. The point is simply that when the test system becomes a significant impediment to development, something must be done. The same is true for any routine process that turns into a barrier or a bottleneck.
Each interaction with a user is an opportunity to get a new volunteer. When a user takes the time to post to one of the project's mailing lists, or to file a bug report, he has already tagged himself as having more potential for involvement than most users (from whom the project will never hear at all). Follow up on that potential: if he described a bug, thank him for the report and ask him if he wants to try fixing it. If he wrote to say that an important question was missing from the FAQ, or that the program's documentation was deficient in some way, then freely acknowledge the problem (assuming it really exists) and ask if he's interested in writing the missing material himself. Naturally, much of the time the user will demur. But it doesn't cost much to ask, and every time you do, it reminds the other listeners in that forum that getting involved in the project is something anyone can do.
Don't limit your goals to acquiring new developers and documentation writers. For example, even training people to write good bug reports pays off in the long run, if you don't spend too much time per person, and if they go on to submit more bug reports in the future—which they are more likely to do if they got a constructive reaction to their first report. A constructive reaction need not be a fix for the bug, although that's always the ideal; it can also be a solicitation for more information, or even just a confirmation that the behavior is a bug. People want to be listened to. Secondarily, they want their bugs fixed. You may not always be able to give them the latter in a timely fashion, but you (or rather, the project as a whole) can give them the former.
A corollary of this is that developers should not express anger at people who file well-intended but vague bug reports. This is one of my personal pet peeves; I see developers do it all the time on various open source mailing lists, and the harm it does is palpable. Some hapless newbie will post a useless report:
Hi, I can't get Scanley to run. Every time I start it up, it just errors. Is anyone else seeing this problem?
Some developer—who has seen this kind of report a thousand times, and hasn't stopped to think that the newbie has not—will respond like this:
What are we supposed to do with so little information? Sheesh. Give us at least some details, like the version of Scanley, your operating system, and the error.
This developer has failed to see things from the user's point of view, and also failed to consider the effect such a reaction might have on all the other people watching the exchange. Naturally a user who has no programming experience, and no prior experience reporting bugs, will not know how to write a bug report. What is the right way to handle such a person? Educate them! And do it in such a way that they come back for more:
Sorry you're having trouble. We'll need more information in order to figure out what's happening here. Please tell us the version of Scanley, your operating system, and the exact text of the error. The very best thing you can do is send a transcript showing the exact commands you ran, and the output they produced. See http://www.scanley.org/how_to_report_a_bug.html for more.
This way of responding is far more effective at extracting the needed information from the user, because it is written to the user's point of view. First, it expresses sympathy: You had a problem; we feel your pain. (This is not necessary in every bug report response; it depends on the severity of the problem and how upset the user seemed.) Second, instead of belittling her for not knowing how to report a bug, it tells her how, and in enough detail to be actually useful—for example, many users don't realize that "show us the error" means "show us the exact text of the error, with no omissions or abridgements." The first time you work with such a user, you need to be specific about that. Finally, it offers a pointer to much more detailed and complete instructions for reporting bugs. If you have successfully engaged with the user, she will often take the time to read that document and do what it says. This means, of course, that you have to have the document prepared in advance. It should give clear instructions about what kind of information your development team wants to see in every bug report. Ideally, it should also evolve over time in response to the particular sorts of omissions and misreports users tend to make for your project.
The Subversion project's bug reporting instructions are a fairly standard example of the form (see Apéndice D, Ejemplo de Instrucciones para Informar sobre Fallos). Notice how they close with an invitation to provide a patch to fix the bug. This is not because such an invitation will lead to a greater patch/report ratio—most users who are capable of fixing bugs already know that a patch would be welcome, and don't need to be told. The invitation's real purpose is to emphasize to all readers, especially those new to the project or new to free software in general, that the project runs on volunteer contributions. In a sense, the project's current developers are no more responsible for fixing the bug than is the person who reported it. This is an important point that many new users will not be familiar with. Once they realize it, they're more likely to help make the fix happen, if not by contributing code then by providing a more thorough reproduction recipe, or by offering to test fixes that other people post. The goal is to make every user realize that there is no innate difference between herself and the people who work on the project—that it's a question of how much time and effort one puts in, not a question of who one is.
The admonition against responding angrily does not apply to rude users. Occasionally people post bug reports or complaints that, regardless of their informational content, show a sneering contempt at the project for some failing. Often such people are alternately insulting and flattering, such as the person who posted this to a Subversion mailing list:
Why is it that after almost 6 days there still aren't any binaries posted for the windows platform?!? It's the same story every time and it's pretty frustrating. Why aren't these things automated so that they could be available immediately?? When you post an "RC" build, I think the idea is that you want users to test the build, but yet you don't provide any way of doing so. Why even have a soak period if you provide no means of testing??
Initial response to this rather inflammatory post was surprisingly restrained: people pointed out that the project had a published policy of not providing official binaries, and said, with varying degrees of annoyance, that he ought to volunteer to produce them himself if they were so important to him. Believe it or not, his next post started with these lines:
First of all, let me say that I think Subversion is awesome and I really appreciate the efforts of everyone involved. [...]
...and then he went on to berate the project again for not providing binaries, while still not volunteering to do anything about it. After that, about 50 people just jumped all over him, and I can't say I really minded. The "zero-tolerance" policy toward rudeness advocated in “Cortar de Raíz la Mala Educación” in Capítulo 2, Primeros Pasos applies to people with whom the project has (or would like to have) a sustained interaction. But when someone makes it clear from the start that he is going to be a fountain of bile, there is no point making him feel welcome.
Such situations are fortunately quite rare, and they are noticeably rarer in projects that make an effort to engage users constructively and courteously from their very first interaction.
24 March 2013: If you're reading this note, then you've encountered this section while it's undergoing substantial revision; see producingoss.com/v2.html for details.
poss2 tbd
Some examples to use: Ubuntu community sprints, Adam Hyde's flossmanuals doc sprints, and the Danese/Noel-style public hackathons. Distinguish between purely dev events and dev+user+funder+enterprise events — all are useful, but don't confuse audiences.
[34] Esta cuestión fue estudiada en detalle, arrojando interesantes resultados, en un ensayo de Karim Lakhani y Robert G. Wolf, tituladoPor qué los Hackers Hacen lo que Hacen: Comprensión de la Motivación y el Esfuerzo en Proyectos de Código Libre/Abierto. Ved http://freesoftware.mit.edu/papers/lakhaniwolf.pdf.
[35] Note that there would be no need to convert all the existing tests to the new framework; the two could happily exist side by side, with old tests converted over only as they needed to be changed.