Hace unas semanas recibí la primera contribución externa al código de gbpublisher. La trajo Jonatán Perren, profesor adjunto y coordinador editorial en la Facultad de Ciencias Económicas de la Universidad Nacional del Litoral, usuario de la aplicación. Detectó un problema concreto en cómo se procesaban las citas dentro de los manuscritos, lo resolvió, y lo aportó al proyecto a través del repositorio.
Qué resolvió
En la práctica editorial académica, una misma referencia bibliográfica puede aparecer de varias maneras dentro del texto: como cita parentética estándar —(Salas, 2018)—, como cita con el autor incorporado al cuerpo —Salas (2018) sostiene…—, con localizador de página —(Salas, 2018, p. 5)—, con un prefijo aclaratorio —(ver Salas, 2018)—, o agrupando varios autores en un único paréntesis. Cada una de esas formas tiene un significado editorial distinto y debe respetarse en la salida final.
Hasta este aporte, gbpublisher reconocía correctamente solo una parte de esas variantes. El resto quedaba sin procesar y, como consecuencia, las referencias asociadas podían omitirse del listado final del artículo. Después del cambio, todas las variantes se reconocen y el formato bibliográfico de salida —en PDF, HTML o EPUB— refleja con precisión lo que el autor escribió en el manuscrito original.
Para los equipos editoriales, esto significa que el flujo de citas se vuelve más confiable: lo que se redacta en Markdown es lo que aparece en la versión final, sin pérdidas silenciosas.
Qué significa para el proyecto
gbpublisher se desarrolla desde hace varios años como una herramienta para revistas y editoriales académicas que necesitan estandarización, reproducibilidad y soberanía tecnológica. Hasta ahora, todo el código había sido escrito por una sola persona. Esta es la primera vez que alguien externo lo lee, entiende una pieza específica, la modifica y la aporta de vuelta al proyecto.
El detalle no es menor. Cuando un software depende exclusivamente de su autor, queda expuesto a una fragilidad estructural: si el autor cambia de tema, se enferma, o simplemente se cansa, el proyecto se detiene. La distribución del código bajo licencia abierta —que es como gbpublisher se publica— justamente busca evitar esa concentración del riesgo. Pero la licencia es solo una posibilidad: lo que la transforma en una realidad es que alguien efectivamente decida participar. Eso es lo que ocurrió acá.
Una invitación abierta
Si trabajan en una revista, una editorial universitaria o un proyecto editorial académico, y están usando o evaluando gbpublisher, hay muchas formas de aportar más allá del código:
- reportes detallados de errores que encuentran en uso real,
- sugerencias de mejora basadas en flujos de trabajo concretos,
- documentación de casos de uso particulares,
- pruebas en distintos entornos institucionales,
- traducciones o correcciones de la documentación existente.
Todo eso construye un proyecto más sólido y más útil para la comunidad editorial académica latinoamericana, que es para quien gbpublisher está pensado.
Pueden escribir a contacto@estudio2a.ar o participar directamente en el repositorio del proyecto en https://github.com/albertomoyano/gbpublisher.
Quiero agradecer especialmente a Jonatán Perren por el aporte, por el cuidado puesto en el diagnóstico del problema, y por la honestidad de documentar también una limitación que su solución no alcanzó a cubrir. Esa transparencia técnica es lo que hace que estos aportes valgan mucho más que el cambio puntual de código.
