Usuario:Link58/Source

Traducción del ensayo original titulado: Open Source Community, Simplified; autor único y original: Max Kanat-Alexander

El crecimiento y mantenimiento de una comunidad de código abierto depende esencialmente de tres cosas:

1. Hacer que la gente se mantenga interesada en contribuir
2. Eliminar las barreras que suponen la incorporación al proyecto y la contribución a él
3. Retener a los colaboradores para que sigan contribuyendo

Si puedes conseguir que la gente se interese, luego hacerlos contribuir, para entonces lograr que se queden, entonces tienes una comunidad. De lo contrario, no.

Si apenas estás comenzando un proyecto o necesitas mejorar la comunidad de un proyecto existente, deberías tratar estos puntos en el orden inverso. Si logras que la gente se interese en un proyecto antes de que hagas los siguientes dos pasos, entonces esa gente será incapaz de entrar y no permanecerá mucho tiempo en el proyecto una vez que logren entrar. De hecho, no ampliarás tu comunidad. Así que, primeramente, queremos estar seguros de que podemos retener tanto a los colaboradores ya existentes como a los nuevos. Una vez que hemos hecho eso, entonces removeremos las barreras de entrada, con tal de que la gente interesada pueda comenzar a contribuir. Sólo entonces es cuando nos podemos empezar a preocupar porque las personas comiencen a interesarse.

Así que hablemos de cómo puedes lograr cada paso en orden inverso:

Retener colaboradores

Para el proyecto Bugzilla, este fue nuestro mayor reto. Una vez que alguien empezó a contribuir, ¿qué les hizo seguir contribuyendo? ¿Cómo logramos mantener a la gente en el proyecto?

Bueno, tuvimos una ventaja interesante como respuesta a estas preguntas, ya que somos uno de los más antiguos proyectos de código abierto, habiendo comenzado a finales de 1998. Así que contábamos con una gran riqueza de datos reales con los cuales trabajar. Extrajimos estos datos de dos maneras: en primer lugar, hicimos un estudio de todos nuestros desarrolladores pasados que habían dejado el proyecto, preguntándoles por qué se habían ido. Lo anterior fue sólo una encuesta de forma libre, permitiéndole a la gente responder de la manera que quería. Luego, creamos una gráfica del número de contribuyentes a través del tiempo, durante los diez años de todo el proyecto, y correlacionamos el ascenso y la caída de los gráficos con las distintas acciones que emprendimos o no con el paso del tiempo.

Una vez que todo esto se hizo, envié un correo electrónico a los desarrolladores del proyecto Bugzilla, donde describí los resultados de la investigación. Este correo lo puedes leer completo si así lo deseas, aunque voy a resumir aquí los resultados:

• No congele el tronco durante largos períodos.

El proyecto Bugzilla cuenta con un sistema bastante estándar que consiste en poseer ramas estables que reciben cambios menores (por ejemplo, la rama "3,4" donde nos comprometemos a corregir errores y hacer versiones menores como 3,4,1, 3,4,2, etc), y un "tronco" principal repositorio a donde van todas las nuevas características, y que a la larga se convierte en nuestro próximo lanzamiento principal.

En el pasado, antes de un lanzamiento importante, "congelábamos" el tronco. Esto significó que no se podían desarrollar nuevas características por varias semanas o meses hasta que sintíeramos que el tronco era lo suficientemente estable como para llamar a un "candidato a lanzarse". Entonces, crearíamos una nueva rama estable a partir del tronco y reabriríamos el tronco principal para las características. Sin embargo, mientras el tronco estaba congelado, no se desarrollaba ninguna característica nueva en el proyecto Bugzilla.

El análisis gráfico muestra claramente que cada vez que nos congelaramos, la comunidad se reduciría drásticamente y nos llevaría varios meses descongelarnos y recuperarnos debido al tamaño de la comunidad. Esto ocurrió de manera uniforme cada vez que nos congelábamos, durante muchos años y muchos lanzamientos.

La sabiduría tradicional en el código abierto radica en que a la gente le gusta trabajar en las características y no les gusta, por otra parte, arreglar los errores. Yo no diría que esto es exactamente una verdad irrefutable, pero si me animaría a decir que si solamente le permites arreglar errores a la gente, entonces la mayoría de ellos no permanecerán más en el proyecto.

Abordamos esta cuestión con la solución de nunca congelar el tronco. En cambio, concluimos inmediatamente en que de manera normal habíamos "congelado" al tronco. El tronco siempre permanece abierto para el desarrollo de nuevas características. Sí, esto significa que por un tiempo, nuestra atención se divide entre el tronco y la rama más reciente. Estamos cometiendo las mismas correcciones de errores a la rama y al tronco. Asimismo, estamos incorporando el desarrollo de las características en el tronco de manera simultánea con esas correcciones de errores. No obstante, hemos observado que no solamente la comunidad se expande más rápidamente de esta forma, sino que también podemos contar con nuestros lanzamientos más rápidamente de lo que solíamos hacerlo antes. Así que es una situación de ganar-ganar.

• La rotación es inevitable.

La encuesta arrojó que la razón principal por la que los colaboradores se van es que porque ya no tienen tiempo para contribuir, o estuvieron contribuyendo como parte de su trabajo y ahora han cambiado de empleo. En esencia, es inevitable que la mayoría de los colaboradores se vayan eventualmente del proyecto.

Así que si los miembros de la comunidad se van a ir definitivamente, la única manera de ampliar constantemente la comunidad es descifrando cómo retener a los nuevos colaboradores.

Si no obtienes nuevos miembros para que se queden, entonces la comunidad continuamente se irá encogiendo mientras los contribuyentes más viejos se marchan, sin importar lo que hagas al respecto.

Así que mientras que mantener a los colaboradores existentes es importante después de todo, por otro lado quieres que la gente se quede y contribuya el mayor tiempo razonablemente posible —lo que importa más es retener a los colaboradores nuevos—. ¿Cómo logras eso? Bueno, gran parte de eso es tratado en los siguientes puntos.

• Responder a las contribuciones de inmediato.

El proyecto Bugzilla cuenta con un sistema de revisiones de código que requiere que todas las nuevas aportaciones sean revisadas por un desarrollador con experiencia antes de que puedan formar parte de Bugzilla. Ha habido varias quejas sobre el sistema a lo largo de los años, pero el análisis de los datos de la encuesta mostraron que las personas dejan el proyecto porque conseguir una revisión tarda demasiado tiempo, no tanto porque las mismas resulten muy difíciles. De hecho, las revisiones pueden ser tan fuertes como tú quieras, siempre y cuando ocurran casi inmediatamente después de que alguien presente una contribución.

A la gente (por lo general) no le importa tener que revisar una contribución. Incluso por lo general no les importa revisarla varias veces. Pero les importa si publican un parche, o si no obtienen una revisión por tres meses, y entonces tienen que revisarlo, sólo para esperar otros tres meses para que se les diga que tienen que revisarlo de nuevo. Es el retraso lo que importa, no el nivel del control de calidad.

Hay otras maneras de responder rápidamente a las contribuciones. Por ejemplo, el agradecer inmediatamente a alguien por la publicación de un parche puede ser un gran paso hacia la retención de nuevos contribuyentes y la "conversión" de éstos en los nuevos desarrolladores a largo plazo.

• Sé extremadamente amable y visiblemente agradecido.

Para casi todas las personas que respondieron a nuestra encuesta, los factores que intervienen en no permanecer más allá de "mi trabajo ha cambiado" o "No tenía tiempo", fueron sorprendentemente personales. Yo sé que todos trabajamos con los ordenadores, y tal vez nos gustaría pensar que la ingeniería debe ser una profesión científica totalmente fría donde todos hacemos nuestros trabajos correctamente de acuerdo a los requerimientos de la máquina, y no preocuparnos por nuestra implicación emocional o personal. Sin embargo, nada podría estar más lejos de la verdad —las interacciones personales que la gente tiene con los miembros de la comunidad, lo tanto que se sienten apreciados, y lo poco o mucho que sienten heridos, en realidad son los aspectos más importantes a la hora de retener a los miembros de la comunidad.

Cuando las personas contribuyen de manera voluntaria, no se les paga en efectivo, sino que cobran con la admiración, el aprecio, el sentido de un trabajo bien hecho, y el saber que están ayudando a crear un producto que afecta a millones de personas. Cuando alguien ha contribuido con un parche, es necesario darle las gracias. No importa si el parche es una mierda total y tiene que ser re-escrito completamente, tienes que darles las gracias. Han puesto algo de trabajo en esto, y si no se los agradeces, se irán antes de que siquiera comiencen. Después de todo, la mayoría de la gente obtiene un poco de apreciación suficiente en sus lugares de trabajo —¡ellos permanecen ahí sólo porque obtienen una paga económica!— No tienen que trabajar de forma gratuita con alguna otra organización si esta tampoco aprecia su trabajo, o peor aún, critica cada aspecto de su contribución antes siquiera de agradecerles la aportación.

Por supuesto, todavía tienes que corregir a las personas sobre las fallas en sus contribuciones. La "amabilidad" no incluye poner un código mal en tu sistema. Eso no es bueno para nadie, incluido el contribuyente cuyas habilidades probablemente necesiten mejorar, y que puede darse el caso que siga creyendo que el error que cometieron en realidad era algo correcto. Hay que ser revisores cuidadosos e inclusive muy buenos codificadores.

Lo que esto significa es que, además de decirle a la gente lo que está mal con su contribución, es importante tener en cuenta lo que está bien sobre su contribución, aunque sea simplemente el hecho de que se tomaron el tiempo para contribuir. Y hay que decirle al colaborador que aprecias la contribución que hizo. Entre más frecuente y genuina sea la forma en que hagas lo anterior, será lo más probable que logres conservar al colaborador.

• Fomenta una ausencia total de la negatividad personal.

Una cosa que aparta a la gente de un proyecto con la velocidad de la luz es cuando son personalmente atacados por tratar de hacer algo positivo. Un "ataque personal" puede ir desde una pequeña broma desagradable sobre su código, en lugar de una simple descripción técnica de lo que está mal. Esto es decir algo como: "¿Qué te pasa?", en lugar de realmente dejar algún comentario útil. Disfrazar la crítica personal como "un intento de ayudarlos a codificar mejor" o "ayudarlos a llevarse bien con otros." No importa qué tan bien justificadas estas acciones pueden parecer, todas son ataques personales que son extremadamente peligrosos para tu comunidad.

Ahora, la codificación y el trabajo en un proyecto de colaboración con personas que tienen diferentes puntos de vista se puede volver muy frustrante a veces, y he sido un delincuente en este ámbito tanto como nadie lo ha sido. Pero todos tenemos que aprender que no está bien para los desarrolladores insultar a otras personas sólo porque estamos frustrados personalmente con ellos.

Sin embargo, la solución no es sólo para decir "todos, contengan sus frustraciones hasta que exploten". Hay un montón de soluciones prácticas. Una de las mejores es la creación de algún sistema específico para la manipulación de los contribuyentes problemáticos. Si hay algún factor con el que Bob no puede lidiar (por ejemplo), es necesario que haya alguien en la comunidad al cual Bob pueda recurrir para intentar que las cosas funcionen. Llamaremos a estas personas como los "moderadores de la comunidad". Así que Bob le cuenta al moderador sobre el problema, y tal vez el moderador ve que el otro contribuyente era realmente una persona terrible o un mal codificador, por lo que este "moderador de la comunidad" corrige suavemente al contribuyente. Pero también es posible que haya habido algún problema de comunicación entre Bob y el otro contribuyente que el moderador sólo tiene que ayudar a resolver.

Este sistema de "moderador" no es la única manera de lidiar con el problema. Puedes resolver el problema de muchas maneras, lo más importante es que logres resolverlo. Sin algún canal o método para hacer frente a las frustraciones personales, los contribuyentes individuales cargarán estas frustraciones sobre los demás. En este caso, fomentarás un entorno en el que está bien para un contribuyente atacar personalmente a otro contribuyente, porque esa es la única vía que tienen para resolver sus problemas, y nadie lo detendrá.

Básicamente, los dos últimos puntos se pueden resumir como: sé real y anormalmente muy amable, y no seas malo.

Hemos estado aplicando todos estos principios en el proyecto Bugzilla en los últimos meses, y hemos visto un aumento en el número de contribuyentes retenidos casi inmediatamente después de haber comenzado su aplicación. Por fin estoy empezando a sentir que la comunidad está creciendo de nuevo, tras una contracción casi continua desde 2005, debido a las violaciones de todos los puntos anteriores.

Remover las barreras

El siguiente paso es eliminar las barreras de entrada. ¿Qué impide a las personas comenzar en el proyecto?

Por lo general, la mayor barrera es la falta de documentación y la dirección. Cuando la gente ya quiere contribuir, su siguiente paso es encontrar la manera de contribuir. Van a ir a la página web de su proyecto y echarle un vistazo. Se preguntarán: "¿A quién debo hablar acerca de esto? ¿Cómo puedo empezar a contribuir? ¿Qué es lo que ustedes quieren que yo haga?"

Para el proyecto Bugzilla, resolvimos este problema de varias maneras:

1. Una lista de proyectos de fácil comienzo. Siempre que vemos un informe de error o característica que parece que sería fácil resolver para un recién llegado, lo etiquetamos como un "error de buena introducción" en nuestro gestor de fallos. Esto nos da una lista de buenos proyectos de introducción que cualquiera puede venir y ver sin tener que preguntarnos "¿por dónde empezar?"
2. Crear y documentar los canales de comunicación. La gente casi de inmediato quiere hablar con alguien sobre el proyecto. Debes contar con listas de correo electrónico y también con algún método de comunicación instantánea, como un canal de IRC. Por ejemplo, tenemos una lista de correo para desarrolladores de Bugzilla y también un canal de IRC en el que casi todos nuestros colaboradores pasan el rato. De hecho, no sólo contamos con un canal de IRC normal, pues también tenemos una página web que la gente puede usar para chatear en el canal de IRC. De esta manera, la gente no tiene que instalar un cliente IRC sólo para venir a hablar con nosotros. La creación de esa página web, ha aumentado enormemente el número de nuevas personas que entran en el canal y se comunican con nosotros (y el aumento fue del todo positivo, no puedo recordar una sola persona que utilice el portal web para causarnos problemas.) Entonces, una vez que tienes estos canales, ¡ellos necesitan ser documentados! La gente tiene que saber cómo llegar a ellos, necesitan saber que existen. Tenemos una página wiki que explica cómo hablar con nosotros si desean contribuir (tén en cuenta que esto es independiente de nuestra página de soporte que describe cómo obtener apoyo para el proyecto.) Además, como punto final aunque también lógico, la comunidad existente tiene que usar los canales de comunicación. Si los principales contribuyentes hacen todo su trabajo en una oficina y sólo le hablan a la gente que está a su lado y tú no utilizas las listas de correo o canales de IRC, entonces los miembros de la comunidad no van a querer utilizar los sistemas de comunicación tampoco. Después de todo, los nuevos contribuyentes que no están ahí para hablar unos con otros, ¡están ahí para hablar con usted!
3. Documentación simple, excelente y completa que describe exactamente cómo se puede hacer una contribución. Documentar totalmente cada paso de tu proceso de desarrollo, y poner dicha documentación en un sitio web público. No inventar un nuevo proceso, sólo documentar de lo que trata el proceso real existente. ¿Cómo se contrae el código? ¿Cómo te pueden enviar parches u otras contribuciones? ¿Cómo dichas contribuciones pasan a formar parte oficial del sistema? Nosotros tenemos una página muy simple que describe los pasos básicos de nuestro proceso completo, y enlaces a los documentos que describen cada paso con más detalle. También alienta a las personas específicamente para entrar en comunicación con nosotros, así que sabemos que están ahí y quieren ayudar.
4. Haz que toda esa documentación sea fácil de encontrar. Este es un paso final simple, pero a veces los proyectos ¡lo olvidan! Puedes tener toda la maravillosa documentación de desarrollo del mundo, pero si los nuevos contribuyentes no pueden encontrarla de forma sencilla, entonces ¡no estás en realidad eliminando ninguna barrera de entrada! Tenemos un gran botón de "¡Contribuir!" situado en nuestra página web que describe las diferentes maneras en que las personas pueden contribuir (¡no sólo con códigos!) y enlaces a más información sobre cada uno de estas.

Hemos presenciado una recuperación definitiva en el número y la calidad de las contribuciones una vez que hemos completado todos estos pasos. Además, tener todo documentado e indicado claramente en un sitio web público significó que ya no teniamos que explicar todo personalmente, cada vez, a cada nuevo colaborador.

La dirección y la documentación no son las únicas cosas que puedes hacer al respecto. Pregúntate: "¿Qué está impediéndole a la gente contribuir?" y elimina todos los obstáculos que razonablemente seas capaz de eliminar.

Hacer que la gente se interese

¿Cómo hacer que la gente piense: 'Caramba, quiero contribuir a este proyecto'? Ese es el primer paso que tienen que tomar antes de que puedan convertirse en contribuyentes. Bueno, la sabiduría tradicional dice que las personas contribuyen a los proyectos de código abierto debido a que:

• Les gusta ayudar.
• Les gusta ser parte de una comunidad.
• Quieren hacer algo en compensación.
• Piensan que algo está mal y que necesitan/quieren arreglarlo.

Así que tú podrías querer hacer aparente que cualquier ayuda es necesaria, que existe una comunidad agradable, que contribuir es apropiado y apreciado, y que hay problemas que necesitan solución.

Ahora, para ser justos, esta es una área que no tengo completamente trazada y descubierta para el proyecto de Bugzilla, aún. Así que no tengo mucha experiencia personal para recurrir. Pero si analizamos otros proyectos, podemos ver que algunas buenas formas de conseguir colaboradores son:

• Ser un producto súper popular.

Esto puede parecer obvio, pero es la principal forma de conseguir nuevos colaboradores. Si una población de chorrocientas personas usa tu producto, es estadísticamente probable que muchos de ellos querrán contribuir. Linux Kernel y WordPress son buenos ejemplos de esto (ambos tienen millones de usuarios), por lo que sólo está destinada a ser una gran cantidad de contribuyentes, eso siempre y cuando los conceptos de "barreras de entrada" y de "retención de colaboradores" del proyecto también se han manejado.

Una manera de convertirse en un producto súper popular, incluso si estás empezando, es ser muy necesario. Linux Kernel fue muy necesario cuando fue escrito por primera vez, la cual es probablemente una de las razones por las que se hizo popular tan rápidamente tal y como lo hizo. Necesitaba desesperadamente existir y no existía todavía.

• Estar escrito en un lenguaje de programación popular.

Generalmente, las personas son más propensas a contribuir a un proyecto si está escrito en un lenguaje que ya conocen. WordPress tiene una gran comunidad de contribuyentes, y viene en PHP. Di lo que quieras sobre PHP, pero es muy popular. Hay un gran número de personas que ya conocen el lenguaje, lo que aumenta la probabilidad de que algunos de ellos empezarán a suministrar parches para tu código.

Esta no la única razón por la que deberías elegir un lenguaje de programación en particular, pero sin duda es un motivador importante si vamos a tener un proyecto de código abierto. Yo creo que Eiffel es un lenguaje extraordinario, pero si escribiera un proyecto de código abierto en el mismo, me ls vería negras para conseguir a los contribuyentes.

Más allá de esos puntos, hay un montón de maneras inteligentes de hacer que las personas se interesen en contribuir a sus proyectos, incluyendo el hablar en conferencias, publicación de blogs, animando a la gente sobre una base de uno a uno, y otros métodos que, básicamente, se suman a "contactar y fomentar".

No obstante, me gustaría escuchar algunas de sus ideas en esta área. ¿Cómo atraes a nuevas personas y las mantienes interesadas en contribuir a tu proyecto? ¿Ha sido particularmente exitoso en algo?

Resumen

Una comunidad de código abierto es una especie de cosa fluida —siempre van a ser personas que van y vienen por una razón u otra—. Lo importante es que la tasa de personas que entran y se quedan sea mayor que la tasa de personas que se marchan. Todos estos puntos ayudan a garantizar eso, y es de esperar también que con estos nuestras comunidades se vuelvan unos lugares productivos y agradables para todos, ¡incluso para nosotros mismos!