Prácticas profesionales Open Source

«Talk is cheap. Show me the code», Linus Torvalds

Hechos, no palabras. El software libre nos da la oportunidad de poner sobre la mesa algo más que la fotocopia de un CV.

En el artículo anterior vimos algunas formas de empezar a mejorar nuestras habilidades gracias al código abierto. Aunque posiblemente se trate de las más importantes, no son las únicas y dado su nivel de éxito podemos inferir que tampoco las más divertidas.

A continuación veremos algunas que implican mayor nivel de interacción.

Criticar.

Este tipo de aportación es una de las más comunes al entrar a un proyecto de software libre. No es la mejor bienvenida en todos ellos por motivos evidentes, ya que el concepto de “crítica constructiva” suele ser visto de manera distinta por quienes las hacen y quienes las reciben.

¿Cómo criticar un proyecto de software libre?

Distinguir entre problemas de soporte como usuario, errores críticos, posibles mejoras de cara al futuro y otras categorías nos da la capacidad de entender mejor el enfoque del proyecto.

Para hacer críticas útiles, debemos ser concretos, especificar claramente, de manera inequívoca, cuál es el problema y cómo reproducirlo. Si quien lo lee no es capaz de replicarlo en su entorno, es muy difícil que pueda saber siquiera cómo empezar a solucionarlo.

Visita la pestaña de issues, donde se listan las incidencias que se han ido reportando, y haz algunas búsquedas para comprobar que no hay una abierta o ya cerrada con lo que quieres plantear. Si nada se ajusta, expón el problema con la mayor claridad posible. Evita títulos poco descriptivos y frases como “ayuda, ¡es urgente!”. Está feo llegar el último y meter prisa a los veteranos.

¿Qué vamos a aprender criticando?

Aprenderemos sobre el flujo de detección-resolución de incidencias. Esta cadena puede ser muy delicada si no se gestiona correctamente y muchos proyectos se ven ahogados en montañas de errores que no están bien descritos, quejas de usuarios que realmente se deben a una falta de formación y otros asuntos cuya mera labor de clasificación puede acabar desmotivando a los desarrolladores.

Aprenderemos cuáles son las áreas más conflictivas del proyecto, pudiendo sacar conclusiones sobre prioridades y sobre puntos que necesitan más trabajo o un replanteamiento más profundo.

¿Cómo se traduce en competencias profesionales?

La identificación de problemas es crucial para su resolución y para poder enfocar el desarrollo orientándolo a código más fácil de verificar de manera automatizada mediante test suites.

Ser capaces de entender qué es lo que hace un bug verificable o testeable y diseñar cómo comprobar su erradicación de manera automatizada es la competencia básica para el puesto de Ingeniero de Calidad (QA), de gran importancia en empresas donde el ciclo de desarrollo del código es vertiginoso y la calidad del código se vuelve un asunto de supervivencia.

Contribuir.

No hay que tener miedo, experimentar es la base de todo este tinglado. Clona el proyecto en tu máquina de desarrollo y haz los cambios que quieras.

Una vez estés en la dinámica del proyecto el ciclo puede ser muy gratificante e incluso adictivo, pero sé paciente, nadie nace aprendido y para entrar en un equipo hay que adaptarse a su forma de trabajar. Acepta las críticas y tómalas como lecciones GRATUITAS impartidas por profesores muy cualificados.

¿Cómo contribuir a un proyecto de software libre?

Una cualidad clave del código abierto es que es NUESTRO. En el momento que uses o te intereses por un proyecto, hazte con una copia de su código fuente y, a poder ser, ejecútalo directamente en lugar de usar los paquetes de tu distribución (busca en la documentación el texto “running from source” para saber cómo). Tendrás más a mano la posibilidad de modificarlo cuando detectes la necesidad de un cambio. Llegado el momento, trastea cuanto creas necesario y, si crees que puede ser de utilidad para otros, haz un Pull Request.

Algunos proyectos muy bien planteados organizan las incidencias por niveles de dificultad o áreas técnicas, permitiendo filtrar y sirviendo de punto de partida para nuevos miembros del equipo de desarrollo. Un ejemplo brillante es la sección de Easy Hacks de LibreOffice,  del que destacaremos la sección de python.

¿Qué vamos a aprender contribuyendo?

El software libre es trabajo en equipo, es su propósito principal y lo que lo hace tan potente. En cada contribución debemos tener en cuenta que nuestro trabajo debe ser leído por otros. Aprenderemos a seguir guías de estilo y mejorar la legibilidad de nuestras aportaciones.

Aunque sea obvio, merece ser destacado, aprenderemos a colaborar en un proyecto al que nos hemos incorporado tarde y tendremos pruebas fehacientes de la veracidad y calidad de esa experiencia profesional.

¿Cómo se traduce en competencias profesionales?

Demostraremos cómo nos enfrentamos a las propuestas de cambios, una piedra con la que es fácil tropezar como desarrolladores y en la que el orgullo sólo nos hace caer con más fuerza. Manejar la frustración que supone ser el objeto de las críticas y convertirlo en algo útil es un valor muy importante.

Las contribuciones en código son en sí mismas la competencia profesional principal por la que, en teoría, se nos contratará como desarrolladores, por lo que cada una de ellas sumará un cuantioso valor que enlazar desde el CV de tus candidaturas.

Gestionar proyectos.

¿Quieres ser Project Manager? Tienes la oportunidad de hacer un máster gracias al Open Source.

A menudo se ha utilizado la expresión “dictador benevolente” para hacer referencia a los administradores de los proyectos libres. No hace falta decir mucho más para resumir que hay un inmenso margen de mejora en cómo se aceptan las propuestas y, especialmente, en cómo se rechazan y proponen cambios.

¿Cómo gestionar proyectos de software libre?

Esta tarea es la evolución de las anteriores, una vez conozcas el funcionamiento de la plataforma de tu elección (github, bitbucket, launchpat, gitlab…), utiliza sus herramientas como sea necesario para conseguir que las contribuciones sigan llegando. Es así de sencillo de resumir pero muy complicado de conseguir.

Para este menester es necesario cierto bagaje como desarrollador o al menos un amplio conocimiento de las guías de estilo y objetivos del proyecto, pues con mucha frecuencia deberemos corregir a otros desarrolladores e indicarles cómo mejorar sus propuestas. Si nos limitamos a señalar errores pero no aportamos alternativas o posibles soluciones, es fácil que pierdan el interés, así que, como dicen que dijo Miguel Ángel Buonarroti: «Critica creando».

¿Qué vamos a aprender gestionando un proyecto de software libre?

Por si a estas alturas no ha quedado lo bastante claro, haciendo la labor de gestores de proyectos tendremos muy presente que el software libre no es gratis, sino que tiene un coste muy elevado, pues los recursos humanos son el factor limitante.

Si ya es difícil para grandes corporaciones mantener la motivación en sus empleados, gestionar el talento y motivar al personal en un proyecto donde las contribuciones de los desarrolladores son voluntarias es otro nivel.

¿Cómo se traduce en competencias profesionales?

De todas las tareas, esta puede ser la más frustrante. Desarrolladores que desaparecen antes de terminar un Pull Request, discusiones que pueden tornarse airadas y diferencias de enfoque que pueden desmembrar un proyecto. Estas y muchas otras dificultades son el día a día de quien administra qué pasa a formar parte de la rama principal de desarrollo y qué es desechado o necesita mejorarse. Afrontarlas y resolverlas sin incentivos monetarios cualifica a quien lo logre para ser Jefe de Proyecto. Sin título, sin corbata, únicamente por el mérito que tus compañeros de viaje te reconocerán por el hecho de seguir en el barco contigo.

Ya no hay excusas, no necesitas experiencia para adquirir experiencia. Como en cualquier otra labor profesional, el camino no siempre será el más cómodo, por lo que enfocar estos consejos con paciencia y filosofía nos llevará más lejos que las prisas. Y no lo olvides, si necesitas ayuda, ¡pídela!