El desarrollo de software académico requiere un equilibrio delicado: necesitamos innovación contínua para mejorar las herramientas, pero también estabilidad absoluta para las instituciones que dependen de ellas en producción.
Este artículo explica el modelo de desarrollo que seguirá gbpublisher, sus raíces históricas en el software libre, y por qué es particularmente apropiado para software de producción editorial académica.
El problema: dos audiencias, dos necesidades
En el desarrollo de gbpublisher convergen dos tipos de usuarios con necesidades completamente diferentes:
Usuarios de producción:
- Necesitan que el software funcione siempre
- No quieren sorpresas ni cambios inesperados
- Valoran la estabilidad por encima de features nuevas
- Planifican sus flujos editoriales con meses de anticipación
- Un bug puede significar retrasar la publicación de un número completo
Early adopters y colaboradores:
- Quieren ver las últimas mejoras
- Están dispuestos a reportar bugs
- Entienden que el desarrollo es iterativo
- Pueden tolerar inestabilidad temporal
- Quieren influir en la dirección del proyecto
Intentar servir a ambas audiencias con un único código base es una receta para el desastre. La solución es tan antigua como el software libre mismo: separación de ramas de desarrollo.
Las raíces: el modelo Debian
La solución a este problema no es nueva. Fue formalizada por el proyecto Debian en 1993, cuando Ian Murdock estableció un sistema de tres ramas para gestionar uno de los ecosistemas de software más complejos jamás creados:
stable (estable)
└─ Software probado exhaustivamente
└─ Solo actualizaciones de seguridad
└─ Para sistemas en producción
testing (en pruebas)
└─ Candidatos a próxima versión estable
└─ Features nuevas pero ya probadas
└─ Para usuarios avanzados
unstable (inestable)
└─ Desarrollo activo
└─ Donde entran paquetes nuevos
└─ Puede romperse en cualquier momento
Este modelo ha permitido a Debian mantener simultáneamente:
- Sistemas en producción con décadas de uptime ininterrumpido
- Innovación continua en miles de paquetes
- Una comunidad activa de desarrolladores y testers
El éxito del modelo Debian lo convirtió en el estándar de facto del software libre. Prácticamente todos los proyectos serios lo han adoptado en alguna forma.
Evolución del modelo: del kernel Linux a PostgreSQL
El kernel Linux adoptó tempranamente una variante de este modelo:
- mainline: Donde Linus Torvalds integra cambios para la próxima versión
- stable: Versiones liberadas, mantenidas por Greg Kroah-Hartman
- longterm: Versiones con soporte extendido (LTS) para sistemas críticos
Cuando tu universidad actualiza los servidores, probablemente está usando un kernel LTS de 5-6 años de antigüedad. No porque sea “viejo”, sino porque es absolutamente confiable.
PostgreSQL, la base de datos preferida en entornos académicos y científicos, sigue un modelo similar:
- master: Desarrollo de la próxima versión mayor
- REL_16_STABLE, REL_15_STABLE, etc.: Ramas de mantenimiento
- Cada versión mayor recibe bugfixes durante 5 años
Este modelo permite que una universidad pueda planificar migraciones con años de anticipación, sabiendo exactamente cuándo termina el soporte de cada versión.
Gambas: el padre técnico de gbpublisher
Gambas, el framework en el que está construido gbpublisher, también sigue este modelo fielmente. Benoît Minisini, su creador, mantiene:
- master: Versión estable actual (3.19.x al momento de escribir esto)
- develop: Desarrollo activo de próximas features (3.21.x en progreso)
Este modelo permite que las distribuciones Linux empaqueten la versión estable de Gambas sin temor a que cambie inesperadamente, mientras los desarrolladores pueden seguir el branch develop para acceder a las últimas mejoras.
Como gbpublisher está construido sobre Gambas, adoptar el mismo modelo es natural y coherente. No estamos inventando nada: estamos siendo consistentes con nuestro ecosistema.
El modelo gbpublisher: adaptado al contexto académico
Para gbpublisher, he adaptado este modelo probado al contexto específico de producción editorial académica:
main
└─ Desarrollo activo de próximas versiones
└─ Aquí ocurre la innovación
└─ Puede contener código experimental
└─ Para colaboradores y curiosos
stable/1.x
└─ Versión 1.0.0, 1.0.1, 1.0.2, etc.
└─ SOLO correcciones de bugs críticos
└─ Garantía de estabilidad
└─ Para producción editorial
stable/2.x (cuando se libere)
└─ Versión 2.0.0, 2.0.1, etc.
└─ Nueva rama estable
└─ Coexiste con 1.x durante período de transición
¿Qué significa esto en la práctica?
Si eres editor/a de una revista académica:
- Usas
stable/1.x(o la última stable disponible) - Recibes notificaciones solo de bugfixes críticos
- Tu workflow nunca se rompe por cambios inesperados
- Puedes planificar el número de diciembre sabiendo que el software funcionará igual que en enero
Si eres desarrollador/a o quieres contribuir:
- Sigues el branch
main - Ves las features en desarrollo para v2.0.0
- Puedes reportar bugs temprano
- Puedes influir en decisiones de diseño antes del release
Si eres administrador/a de sistemas:
- Instalas desde
stable/X.x - Sabes exactamente qué esperar
- Las actualizaciones son predecibles
- No hay sorpresas en producción
Por qué esto importa en el contexto académico
La producción editorial académica tiene características únicas que hacen este modelo especialmente importante:
1. Ciclos de publicación predecibles
Las revistas académicas operan con calendarios estrictos:
- Números trimestrales, semestrales o anuales
- Fechas de indexación en bases de datos
- Compromisos con autores sobre fechas de publicación
- Evaluaciones institucionales basadas en producción publicada
Un bug que retrasa la publicación del Vol. 15 No. 2 puede significar:
- Perder la ventana de indexación en SciELO
- Incumplir compromisos con autores
- Afectar métricas de puntualidad de la revista
- Problemas en evaluaciones de calidad
La estabilidad no es un lujo: es un requisito.
2. Recursos técnicos limitados
A diferencia de empresas comerciales, las editoriales universitarias típicamente:
- NO tienen departamentos de IT dedicados
- Dependen de un editor técnico o coordinador
- Carecen de presupuesto para consultores externos
- No pueden “tirar abajo todo y reinstalar”
Cuando algo se rompe, no hay equipo técnico 24/7 para arreglarlo. El modelo de branches estables garantiza que lo que funciona, sigue funcionando.
3. Continuidad institucional
Las revistas académicas trascienden personas individuales:
- Una revista puede tener 40+ años de historia
- Los editores cambian cada 3-5 años
- El conocimiento debe transferirse
- Los procesos deben documentarse
Tener una versión estable bien definida facilita:
- Documentación que no se vuelve obsoleta cada 3 meses
- Capacitación de nuevos editores con materiales vigentes
- Continuidad operativa durante transiciones de personal
4. Trazabilidad y reproducibilidad
En el contexto académico, la reproducibilidad es fundamental:
- ¿Con qué versión se generó este XML-JATS?
- ¿Qué transformaciones XSLT se aplicaron?
- ¿Cómo se puede regenerar este PDF exactamente igual?
El modelo de versiones estables etiquetadas permite:
Este número se produjo con gbpublisher v1.2.3
→ Código exacto disponible en tag v1.2.3
→ Documentación específica de esa versión
→ Reproducible en 5 años si es necesario
Transparencia del desarrollo
Un aspecto crucial de este modelo es que todo el código está visible desde el primer día, incluso durante el desarrollo.
El branch main será público. Cualquiera puede:
- Ver en qué estoy trabajando
- Comentar sobre decisiones de diseño
- Reportar bugs temprano
- Sugerir mejoras antes del release
Esta transparencia es coherente con los valores académicos:
- Revisión por pares: Los desarrolladores pueden revisar el código
- Reproducibilidad: Todo cambio está documentado en el historial Git
- Auditoría: Instituciones pueden verificar qué hace el software
- Colaboración: La comunidad puede contribuir mejoras
Pero esta transparencia NO significa inestabilidad para usuarios finales, porque siempre existe el branch estable para producción.
Modelo de soporte: qué esperar de cada rama
Branch main (desarrollo)
Soporte:
- Limitado y bajo esfuerzo razonable
- Enfocado en mejorar el código, no en soporte de producción
- Issues bienvenidos, pero pueden no resolverse inmediatamente
- Documentación puede estar desactualizada
Para quién:
- Desarrolladores
- Colaboradores
- Curiosos técnicos
- Testers voluntarios
Garantías:
- Ninguna
- El código puede cambiar drásticamente
- Features pueden desaparecer
- APIs pueden modificarse
Branches stable/X.x (producción)
Soporte:
- Profesional y prioritario
- Bugfixes críticos se liberan rápidamente
- Documentación completa y actualizada
- Respuestas a consultas en 24-48h
Para quién:
- Editoriales universitarias
- Revistas en producción
- Instituciones con plazos estrictos
- Usuarios que necesitan estabilidad
Garantías:
- Solo bugfixes, NUNCA breaking changes
- Compatibilidad hacia atrás dentro de la misma versión mayor
- Comportamiento predecible
- Documentación precisa
Ciclo de vida de una versión
┌─────────────────────────────────────────────────────┐
│ DESARROLLO (6-12 meses) │
├─────────────────────────────────────────────────────┤
│ Branch: main │
│ Actividad: Features, refactoring, experimentación │
│ Usuarios: Colaboradores y testers │
└─────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ RELEASE (v2.0.0) │
├─────────────────────────────────────────────────────┤
│ Tag: v2.0.0 │
│ Branch: stable/2.x se crea desde main │
│ Licencia: BSL 1.1 (→ GPL v3 en 5 años) │
└─────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ MANTENIMIENTO (2 años) │
├─────────────────────────────────────────────────────┤
│ Branch: stable/2.x │
│ Releases: v2.0.1, v2.0.2, v2.1.0, etc. │
│ Solo: Bugfixes y mejoras menores │
│ Usuarios: Producción editorial │
└─────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ LEGACY / TRANSICIÓN (1-2 años) │
├─────────────────────────────────────────────────────┤
│ Branch: stable/2.x (bugfixes críticos únicamente) │
│ v3.0.0 ya está disponible │
│ Usuarios migran gradualmente a v3.x │
└─────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ END OF LIFE │
├─────────────────────────────────────────────────────┤
│ Branch: stable/2.x permanece disponible │
│ Código: Disponible para siempre (GPL v3) │
│ Soporte: Termina oficialmente │
│ Usuarios: Deben migrar a versión actual │
└─────────────────────────────────────────────────────┘
Convivencia de versiones: migración gradual
Un aspecto importante del modelo es que múltiples versiones estables pueden coexistir:
Enero 2027 - Se libera v2.0.0:
stable/1.x
└─ v1.2.5 (última versión 1.x)
└─ Soporte extendido: bugfixes críticos por 1 año
└─ Algunas instituciones prefieren quedarse en v1
stable/2.x
└─ v2.0.0 (nueva versión recomendada)
└─ Soporte completo activo
└─ Instituciones early adopters migran
Esto permite migraciones planificadas:
- Una editorial puede terminar el año con v1.x
- Probar v2.x durante enero-febrero (período “tranquilo”)
- Migrar completamente para el siguiente número
- Sin presión ni urgencias
En software comercial, frecuentemente se fuerza la actualización. En software académico, respetamos los tiempos institucionales.
Distribución y acceso: modelo de auditoría responsable
gbpublisher sigue un modelo de distribución que equilibra accesibilidad con responsabilidad académica.
Cómo obtener gbpublisher
El código fuente está completamente disponible en el repositorio GitHub:
git clone https://github.com/albertomoyano/gbpublisher
git checkout stable/1.x # para versión de producción
Los paquetes .deb compilados están disponibles mediante solicitud:
- Completa el breve formulario en [URL_DEL_FORMULARIO]
- Recibirás el enlace de descarga por correo (usualmente en 24-48h)
- Instala normalmente:
sudo dpkg -i gbpublisher_X.X.X.deb
¿Por qué un formulario?
Este proceso no es una barrera comercial (el software es sin costo), sino una práctica de investigación y desarrollo responsable:
Auditoría de adopción:
- Conocer qué instituciones usan gbpublisher
- Identificar áreas geográficas y disciplinas
- Demostrar impacto para financiamiento académico
- Generar métricas de uso real vs. descargas especulativas
Priorización de desarrollo:
- Entender necesidades de usuarios reales
- Diseñar features para casos de uso documentados
- Asignar recursos de soporte limitados eficientemente
- Construir comunidad de práctica identificable
Comunicación directa:
- Notificar sobre actualizaciones críticas
- Enviar avisos de bugs que afecten producción
- Invitar a participar en decisiones de diseño
- Facilitar colaboración entre instituciones similares
Datos solicitados
El formulario solicita únicamente:
- Nombre y correo de contacto
- Institución / editorial
- Tipo de publicaciones (revista, libro, etc.)
- Versión solicitada (1.x stable, 2.x testing, etc.)
- Opcional: Caso de uso específico
Garantías de privacidad:
- NO se comparten datos con terceros
- NO se usa para marketing comercial
- Solo comunicaciones técnicas relacionadas con gbpublisher
- Puedes solicitar eliminación de datos en cualquier momento
Alternativa: compilar desde fuente
Si prefieres no completar el formulario, puedes compilar gbpublisher desde el código fuente:
# Clonar repositorio
git clone https://github.com/albertomoyano/gbpublisher
cd gbpublisher
git checkout stable/1.x
# Compilar con Gambas
gbc3 -a
gba3
Esta opción requiere conocimientos técnicos pero garantiza total autonomía.
Coherencia con BSL 1.1
Este modelo de distribución es completamente compatible con Business Source License 1.1:
- El código fuente es completamente visible y auditable
- El software es sin costo (no hay venta)
- La conversión a GPL v3 ocurre automáticamente tras 5 años
- Solo se controla cómo se distribuyen los binarios compilados durante el período de restricción
Esto es similar a prácticas de proyectos respetados como GitLab, MariaDB MaxScale y Nextcloud Enterprise, que solicitan registro para descargas enterprise mientras mantienen el código fuente completamente abierto.
Política de no-discriminación
Las solicitudes se procesan sin discriminación:
- ✅ Todas las instituciones académicas legítimas
- ✅ Editoriales universitarias públicas y privadas
- ✅ Proyectos de publicación científica sin fines de lucro
- ✅ Investigadores individuales para evaluación
No se rechazarán solicitudes legítimas de usuarios que cumplan con el caso de uso académico/editorial del software.
Comunicación clara: cómo saber qué usar
El README del repositorio siempre indicará claramente:
## Versiones Disponibles
### v1.x (Legacy - Mantenimiento limitado)
- **Última versión**: v1.2.5
- **Branch**: stable/1.x
- **Estado**: ⚠️ Mantenimiento solo para bugs críticos
- **Recomendado para**: Instituciones que no pueden migrar todavía
- **Conversión GPL v3**: Enero 2031
### v2.x (Actual - Producción)
- **Última versión**: v2.0.3
- **Branch**: stable/2.x
- **Estado**: ✅ Soporte completo activo
- **Recomendado para**: Todos los usuarios nuevos y actuales
- **Conversión GPL v3**: Enero 2032
### v3.x (En desarrollo)
- **Branch**: main
- **Estado**: 🚧 Desarrollo activo
- **Recomendado para**: Colaboradores y testers únicamente
- **Release estimado**: Mediados 2028
Conclusión: disciplina técnica al servicio de la misión académica
El modelo de desarrollo con ramas separadas no es complejidad innecesaria. Es disciplina técnica que permite cumplir la misión del software académico:
Estabilidad donde se necesita:
- Las editoriales pueden planificar con confianza
- Los números salen a tiempo
- La indexación no se retrasa
- La calidad es consistente
Innovación donde corresponde:
- El software mejora continuamente
- Nuevas features se desarrollan sin prisa
- La comunidad puede participar
- El proyecto permanece activo y relevante
Transparencia en todo momento:
- El código es auditable
- Las decisiones son visibles
- La dirección del proyecto es clara
- La reproducibilidad está garantizada
Este modelo ha funcionado para Debian desde 1993, para el kernel Linux desde sus inicios, para PostgreSQL durante décadas, y para Gambas desde 1999.
No estoy inventando nada. Estoy aplicando 30+ años de sabiduría colectiva del software libre a un dominio específico: la producción editorial académica latinoamericana.
Y eso, precisamente, es lo que debe hacer el software académico serio:
construir sobre conocimiento probado, no reinventar ruedas innecesariamente.
Referencias y lecturas adicionales
- Debian Social Contract: https://www.debian.org/social_contract
- Gambas Project: https://gambas.sourceforge.net/
- PostgreSQL Versioning Policy: https://www.postgresql.org/support/versioning/
- The Cathedral and the Bazaar (Eric S. Raymond): Sobre modelos de desarrollo en software libre
- “Release Early, Release Often”: Filosofía que fundamenta estos modelos
