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.