Trabajo: Cómo formar parte de proyectos de Software Libre
Contenido
Trabajo realizado por
- Fátima Rojo del Prado (Grado Ingeniería Informática - 4ºA)
¿Por qué participar en proyectos de Software Libre?
Aunque de primeras no parezca lo más importante, a la hora de redactar nuestro CV, se valora positivamente que en él aparezcan participaciones de voluntariado. ¿Y qué es sino participar en proyectos Open Source o de Software Libre? Participar en organizaciones sin ánimo de lucro, las cuales no tiene como propósito un beneficio económico sino social, altruista, humanitario, artístico y/o comunitario.
Además, como programador, las ventajas de participar en estos proyectos son numerosas, pues proporcionan una mejora del trabajo en equipo, enfoque en el nivel del código, aprendizaje de nuevas tecnologías y la contribución a la mejora social del software.
Diferencias entre Open Source y Software Libre
Según ha ido creciendo el uso de internet, los proyectos Open Source y Software Libre han ido aumentando exponencialmente, pues implican un menor coste y mayor innovación. Pero, ¿qué los diferencia?
Software Libre es aquel software que puede ser copiado, estudiado, modificado y redistribuido con o sin mejoras. Su objetivo es luchar por la libertad del usuario haciendo uso de programas sin restricciones sin que sus datos se vean comprometidos por terceros.
Por otro lado, Open Source es software distribuido y desarrollado libremente enfocado más en los beneficios prácticos que en los aspectos éticos o de libertad que tiene el Software Libre.
Es decir, Open Source hace hincapié en el aspecto más técnico del software. Además, mientras que todo lo que derive del Software Libre sigue siendo libre, en Open Source no tiene porqué.
Algunos consejos para participar en proyectos de Software Libre
Una de las ventajas de participar en este tipo de proyectos es que las comunidades se estructuran como una meritocracia, es decir, basándose en el mérito personal obtenido. A su vez, esto puede dificultar mucho la entrada en un proyecto.
Es por eso que para entrar, hay que hacerlo poco a poco y siguiendo los pasos correctos. Aquí se muestran algunos consejos:
1. Elegir proyecto
- Por supuesto, involucrarse en algo que verdaderamente nos interese y nos motive, o se abandonará. La idea es trabajar en algo que usas, conoces y has visto fallos/bugs/deficiencias/posibilidades de mejora. La mejor parte del software libre es que, si ves algo que se puede mejorar, puedes mejorarlo.
- Buenas listas de proyectos por los que empezar son:
- Google Summer of Code y sus organizaciones.
- Awesome First PR Opportunities
- Lista de proyectos de Mozilla.
- GitHub Explore. Miles de proyectos de todas las formas y colores.
2. Conocer el proyecto.
- Los desarrolladores que colaboran en dichos proyectos se comunican con la comunidad a través de blogs, foros, listas de correo o IRC. Por tanto es necesario:
- Escuchar a la comunidad indagando en estos medios.
- Conocer el repositorio. Lee el código y las instrucciones de compilación. Intenta compilar la rama estable para familiarizarte con el proceso.
- Familiarizarte con sus buenas maneras y consejos de uso
3. No meterse a enviar código como un loco, sino empieza por “lurkear”
- Leer mensajes, peticiones, respuestas, para conocer el ambiente y cómo funcionan las cosas.
4. Participar
- a) Toma de contacto:
- Responder cuestiones en los foros
- Ayudar por IRC a personas más novatas
- Documentar errores reportados
- Crear ejemplos de uso
- Antes de preguntar, asegúrate de que la respuesta no está en la documentación del proyecto. Por lo general no importa que preguntes, pero preguntar cosas que se pueden resolver con una búsqueda se considera de mala educación. Al fin y al cabo, si tú no estás dispuestx a tomarte el tiempo para resolver tu duda, por qué debería el resto? Cómo hacer buenas preguntas (Inglés)
- Cuando obtengas la respuesta, tomate el tiempo para documentarla, así lxs que vengan detrás no tendrán que preguntar.
- b) Trabajar en el código del proyecto: antes de empezar a escribir código, es importante que aprendamos el estilo en que se escribe y la forma en que se una en el proyecto para hacer los commits oportunos. Para esto, lo más recomendable es elegir una tarea trivial, como añadir una pequeña función, para familiarizarte con el proceso de compilación y la arquitectura en general del proyecto. En una codebase de decenas de miles de líneas, lo más difícil para alguien recién llegadx suele ser saber dónde hacer un cambio sin romper nada.
- Mirar la lista de bugs del proyecto. Muchos marcan estos cambios triviales como "beginner friendly".
- Preguntar por el IRC.
- Probar versiones beta en distintas plataformas para adaptar lo que no funcione correctamente
- Aportar soluciones a los bugs
- Cerrar incidencias ya resueltas
- Crear más tests. Siempre hacen falta más tests.
- c) Si te gusta más la parte del diseño, puede ayudar a mejorar el sitio web.
- d) Si sabes más de un idioma, puede traducir el proyecto en sí o su sitio web.
- a) Toma de contacto:
- Si ves que hay aceptación, comienza a meterte en temas más serios para “hacerte un nombre”. Al principio tus parches serán ignorados hasta que acabes siendo aceptado.
- Conforme vayas aprendiendo el programa y la comunidad, y la comunidad te conozca a ti y a tu código, iras “escalando puestos” en la meritocracia, se irán fiando de ti y te irán dando responsabilidades. Dado que para la mayoría de nosotrxs esto será un trabajo voluntario, las organizaciones no tienen ninguna garantía de que, si aceptan uno de tus parches, estarás ahí para arreglar los problemas que surjan. Por lo tanto, algo que da mucha credibilidad, incluso por encima de la calidad de tu código, es que estés ahí cuando surjan problemas. Cuando una organización sepa que puede contar contigo es cuando tus parches serán más aceptados.
Conclusión
- Ir demostrando poco a poco lo que vales en tus aportaciones. No basta con programar bien, hay que seguir las reglas de la comunidad y mostrárselo a la gente que tiene que descubrirte.
Licencias Open Source más populares
En la gráfica se muestra cómo el porcentaje de licencias Copyleft en SoruceForge se encuentra por encima del 80%, mientras que para GitHub es inferior al 30%. Sus resultados también indican que la licencia MIT es el más popular en GitHub seguido por la GPL. En SoruceForge, sin embargo, la licencia más común para los proyectos es la GPL.
