Participando en Umami, un proyecto Open Source

Published on
3 minutos
thumbnail-image

¿Alguna vez has pensado en participar en algún proyecto open source? Llevo ya bastantes años en este mundillo y participar en algún proyecto open source siempre ha sido algo que me apetecía hacer, pero no tenía mucho tiempo y, sobre todo, no tenía claro en qué proyecto. Pero empecemos por el principio: ¿Qué es open source o código abierto?

Buscando un poco por la red, he encontrado esta definición:

Originalmente, la expresión open source (o código abierto) hacía referencia al software open source (OSS). El software open source es un código diseñado de manera que sea accesible al público: todos pueden ver, modificar y distribuir el código de la forma que consideren conveniente.

El software open source se desarrolla de manera descentralizada y colaborativa, así que depende de la revisión entre compañeros y la producción de la comunidad. Además, suele ser más económico, flexible y duradero que sus alternativas propietarias, ya que las encargadas de su desarrollo son las comunidades y no un solo autor o una sola empresa.

Hace ya algunos meses, empecé a usar Umami en el blog para sacar analíticas y datos sobre el uso que se da a la web, y sí, es un proyecto open source. Echando un ojo a una de sus últimas versiones, me fijé que les faltaban bastantes traducciones al español de los menús y otras partes, y me animé a completarlas en una PR super sencilla. En poco tiempo, la revisaron y la fusionaron con su rama principal. ¡Genial!

Aprovechando que estaba dando una vuelta por su GitHub, me di cuenta también de que su propia web también es de código abierto, y después de revisar un poco, vi un par de cosas que podía cambiar. La web está desarrollada en Next.js y TypeScript, no soy un experto, pero este blog está hecho con la misma tecnología y son cambios familiares.

Vi una issue que tenían abierta sobre la fecha del footer, que se mantenía en 2023, y la automatice para que cambie de manera automática. También el equipo de Umami la fusionó bastante rápido. Por último, hice esta PR, cambiando todas las referencias y logos que tienen en la web del antiguo Twitter por X. Esta PR aún no la han fusionado y lleva bastante tiempo, cada cierto tiempo, cuando se generan conflictos, tengo que actualizarla para que esté lista para fusionar. Hoy mismo se ha fusionado.

Como veis, son cambios simples; aportar ‘algo’ en este caso a Umami, un producto que uso a diario, es reconfortante. Si has llegado hasta aquí, es posible que te surja una pregunta: ¿Cómo es el proceso para crear una PR en un proyecto OSS?

Para colaborar en la mayoría de proyectos OSS, es necesario que forkees el proyecto. Forkear el proyecto no es más que hacerte una versión propia y la puedes alojar directamente en tu GitHub. A partir de ahí, puedes crear una rama, hacer tus cambios y, una vez terminado el trabajo, crear la PR contra la rama de referencia del repositorio, en este caso de Umami. Yo tampoco tenía claro cómo trabajan ellos, pero revisando sus PRs pude ver que, para el proyecto Umami, las PRs van contra la rama dev y cada cierto tiempo se hace un despliegue de dev a pro. Por otro lado, para la web, las PRs van directamente contra main. Al hacer la PR, se genera un despliegue en preview en Vercel (donde tienen alojada la web) que valida que no se rompe nada, pero siempre es necesaria la revisión de alguien del equipo para que tus cambios finalmente vayan a la rama principal.

Ahora mismo hay ‘algo’ de mi código en dos repositorios de Umami, algo anecdótico; si no lo hubiera hecho yo, seguramente otro lo hubiera hecho, pero participar en un proyecto OSS que uso mola. Yo creo que tiene más sentido participar en proyectos que conoces ya que tienes una visión más completa, que participar en proyectos OSS por decir que has participado, al menos es mi opinión.

Y hasta aquí llega mi post sobre cómo aportar en proyectos OSS. Espero que os haya resultado interesante, si es así, compartidlo, si tenéis alguna duda dejadme un comentario y os responderé lo antes posible.