Mi viaje en código abierto con VoiceyBill: tres PRs y seis lecciones

Durante meses, experimenté esa sensación familiar de abrir un repositorio en GitHub, desear contribuir y cerrar la pestaña con una mezcla de inseguridad y respeto. Hasta que decidí dejar de observar y convertirme en parte activa del ecosistema open source. Mi objetivo era VoiceyBill, un gestor financiero que permite registrar ingresos y gastos mediante voz, escaneo de recibos con inteligencia artificial y cuadros de mando analíticos. Lo que comenzó como una exploración terminó en tres pull requests (PR) fusionadas en dos repositorios diferentes, cada una con sus propios desafíos y lecciones. Este viaje no solo mejoró mis habilidades técnicas, sino que me permitió comprender en profundidad cómo se construyen aplicaciones a medida en entornos reales de producción, con usuarios reales esperando que el código funcione correctamente.

La primera lección llegó al abordar el backend. El proyecto necesitaba un endpoint que exportara el historial de transacciones a un archivo Excel. Implementé la funcionalidad siguiendo la arquitectura controller-service-route que ya existía, usando ExcelJS para generar el archivo. Todo funcionaba en local, pero al abrir el PR, el sistema de integración continua (CI) falló. Faltaba el archivo package-lock.json, un error común entre principiantes. Aprendí que en el desarrollo de software a medida, la reproducibilidad del entorno es crítica. Las automatizaciones de CI/CD, similares a las que aplicamos en Q2BSTUDIO para garantizar calidad en cada entrega, no perdonan estos descuidos. La solución fue trivial, pero la enseñanza profunda: leer los logs de fallo con atención y entender por qué el pipeline exige consistencia.

La segunda lección fue sobre la gestión de dependencias y la coherencia tecnológica. En el frontend, al implementar el botón de exportación CSV, instintivamente añadí axios como dependencia. Sin embargo, el proyecto ya utilizaba RTK Query para todas las peticiones API, una decisión arquitectónica deliberada. El revisor señaló que debía respetar esa elección. Aquí comprendí que construir aplicaciones a medida no es solo escribir código funcional, sino alinearse con las decisiones previas del equipo. En Q2BSTUDIO, cuando desarrollamos ia para empresas o cualquier solución, priorizamos mantener una coherencia tecnológica para evitar la deuda técnica que genera mezclar herramientas sin razón suficiente.

La tercera lección llegó en la revisión de código. Mi primera versión del frontend duplicaba la lógica de descarga de archivos en dos páginas distintas. El revisor aplicó el principio DRY (Don't Repeat Yourself) y me sugirió extraerla a una utilidad compartida. Lo hice, pero olvidé actualizar uno de los llamados originales. Fue necesario un segundo round de revisión para corregirlo. Este error me enseñó la importancia de auditar todos los puntos de uso al refactorizar. En el ámbito de la ciberseguridad, por ejemplo, un fallo en la actualización de una función compartida puede exponer vulnerabilidades. En Q2BSTUDIO integramos prácticas de revisión exhaustiva y pruebas automatizadas para mitigar estos riesgos.

El tercer PR fue puramente de interfaz de usuario: añadir un botón de cierre en el panel lateral móvil. Parecía sencillo, pero implicaba considerar la accesibilidad: atributos aria-label, manejo del foco, soporte para teclado y gestos táctiles. Lo probé en seis navegadores y dispositivos reales. Esta atención al detalle es la misma que aplicamos en Q2BSTUDIO al ofrecer servicios cloud aws y azure, donde la experiencia del usuario final debe ser impecable independientemente del dispositivo o plataforma. El PR se fusionó en la primera revisión sin cambios solicitados, lo que demostró que una tarea bien acotada, documentada y probada tiene más posibilidades de éxito que varios cambios dispersos.

Estas tres contribuciones —backend, frontend y UI— no fueron ejercicios aislados. Juntas forman una funcionalidad completa: el usuario móvil abre el menú, navega a transacciones, pulsa exportar y descarga su archivo Excel. Ese flujo extremo a extremo es el mismo que diseñamos en Q2BSTUDIO cuando desarrollamos servicios inteligencia de negocio como Power BI, donde cada componente debe encajar para entregar información accionable. También aprendí que el código abierto no es solo código; es comunidad, paciencia y respeto por los tiempos de los mantenedores. Mi PR de frontend aún espera aprobación final, pero mientras tanto ya busco el próximo issue.

La sexta lección, quizás la más valiosa, fue entender que mi primer PR fue el más difícil. Después de él, el repositorio se vuelve familiar, los mantenedores reconocen tu trabajo y el proceso se acelera. Hoy, al reflexionar, veo paralelismos claros con la forma en que Q2BSTUDIO aborda proyectos de agentes IA o automatización: empezar con un alcance pequeño, validar con el cliente, iterar con revisiones, y escalar gradualmente. El open source me regaló exactamente eso: un entorno real donde equivocarme, recibir feedback genuino y mejorar como profesional. Si aún no has dado el paso, te recomiendo elegir un proyecto que te apasione, leer su guía de contribución, y lanzarte. El resultado no es solo un PR fusionado, sino una comprensión más profunda de cómo se construye tecnología que realmente importa.