A menudo, la primera pregunta que se hace alguien que quiere empezar a colaborar en un desarrollo de software libre es cómo hacerlo.

Al comenzar a programar en una empresa o cualquier clase de proyecto con una estructura jerárquica tradicional, simplemente llegas y alguien te muestra una silla y te dice lo que tienes que hacer y cómo tienes que hacerlo. En una comunidad de software libre las cosas son muy distintas.

El desarrollo de software libre tiene un componente social muy importante, y las comunidades se estructuran, de forma deliberada o espontánea, como una meritocracia.

Esto tiene muchas ventajas de cara al desarrollo en sí mismo, pero puede dificultar mucho entrar en un proyecto.

Además, cada proyecto es un ecosistema en sí mismo y funciona de forma autónoma y distinta a todos los demás. Lo que vale para uno no tiene necesariamente que valer para otro. Lo que pongo aquí son unas reglas básicas, meramente orientativas, en base a lo que cuentan miembros de distintas comunidades (En especial recomiendo esta magnífica presentación de Plablo Neira, que es miembro del Core Team de Netfilter).

En algunos casos, sobre todo proyectos pequeños o incluso unipersonales con poca o ninguna comunidad, te bastará con escribir un correo al administrador para que te dé permisos de escritura en el repositorio, pero aquí vamos a suponer que estás pensando en un proyecto «grande», en el que no va a ser fácil que te hagan caso o incluso la recepción sea más que fría.

En un proyecto grande, un administrador puede recibir cada día cientos de parches de desconocidos que, directamente, no puede pararse a leer para ver siquiera si son simplemente válidos. Lo más probable es que los descarte directamente. Para entrar hay que hacerlo poco a poco, siguiendo los pasos correctos.

Insisto en que esto está escrito pensando en el caso más «difícil»: No quiero asustar a nadie XD

Para empezar, ármate de paciencia.

Elegir proyecto

Naturalmente, tiene que ser algo que te guste, porque no tiene mucho sentido meterte en algo que te aburra y que seguro que vas a abandonar más pronto que tarde.

Además debes buscar algo más o menos concreto. «Quiero trabajar en GNU/Linux» no es decir mucho.

Siempre es mucho mejor, si es posible, que trabajes en algo que usas, conoces y a lo que le has visto fallos/bugs/deficiencias/posibilidades de mejora.

Los proyectos pequeños con pocos miembros suelen ser más receptivos a la hora de admitir nuevos miembros, y más dados a ponértelo fácil, explicarte cada cosa, etc.

Conocerlo

Una vez que has decidido en qué quieres participar, tienes que buscar tres cosas principales (que, a menudo, van juntas) y darte de alta en ellas:

1. Los foros/listas de correo de desarrolladores (no los de usuarios, ni howtos, aunque también conviene conocerlos).
2. El bus tracería.
3. El repositorio (cómo se usa el CVS que tenga, y bajarte el código, claro).

En los tres puntos de arriba, además, debes leerte los consejos de uso, buenas maneras y esas cosas.

Una vez hecho esto, meterse a enviar código como un loco es un error. Es el momento de «lurkear». Lee los mensajes, las peticiones, las respuestas…

La idea es que veas «el ambiente», cómo pregunta y responde la gente y cómo funcionan las cosas en general.

Empezando a participar

Cuando te sientas cómodo, puedes empezar a responder cuestiones en los foros o aportar soluciones a los bugs. Es mejor empezar con cuestiones simples, aunque sean tonterías o demasiado simples para tus conocimientos. Es probable que sean cosas de uso o configuración, que no requiera código. También es bueno que vayas viendo los parches que sube la gente, probándolos tú mismo, etc.

Si ves que hay buena recepción, ya podrás meterte en temas más serios y empezar a aportar soluciones a bugs reales (para estas alturas, ya deberías saber manejar la herramienta «diff»). Si todo va bien y confiando en tu habilidad y dedicación, para estas alturas ya te estás «haciendo un nombre» (o sea, que ya no eres un desconocido que acaba de aparecer). La mayoría de estos parches van a ser ignorados o descartados por la razón que sea (porque el formato no es el correcto, porque están demasiado/demasiado poco comentados, porque hay oro parche mejor…) pero, en algún momento, uno de tus parches acabará siendo aceptado. Enhorabuena.

Probablemente pases mucho tiempo escribiendo parches y, conforme tú aprendas a conocer el programa y la comunidad, y la comunidad aprenda a conocerte a ti y a tu código, irás «escalando puestos» en la meritocracia (que es una forma «chic» de decir que se irán fiando de ti e incluso te irán dando responsabilidades).

Básicamente, se trata de ir demostrando poco a poco lo que vales en base a tus aportaciones. No puedes llegar gritando «Aceptad mis commits, que soy un genio programador«, porque no serás bien recibido. No basta con programar bien, también hay que seguir las reglas de la comunidad y ponérselo a la gente que tiene que descubrir que programas bien.