Linus Torvalds lo ha dicho en múltiples ocasiones: desarrollar aplicaciones de escritorio en Linux puede ser un calvario. No por las herramientas, que son excelentes, sino por la fragmentación del ecosistema.
Este es uno de los problemas que nadie quiere admitir
La enorme libertad y diversidad de entornos, bibliotecas, gestores de ventanas y distribuciones se convierte en una traba real para el desarrollo unificado en el escritorio. Lo que funciona perfectamente en Ubuntu puede fallar en Fedora. Lo que se ve bien en GNOME puede romperse en KDE. Las dependencias que están en Debian Sid pueden no existir en una LTS.
Esta no es una crítica al software libre ni a la diversidad del ecosistema Linux. Es simplemente reconocer un hecho técnico: la fragmentación tiene costos, y esos costos los paga principalmente el desarrollador.
Mi aplicación, gbpublisher, está desarrollada en Gambas y tiene una política técnica muy estricta:
- Solo tiene soporte oficial para Linux Mint Cinnamon
- Utiliza Gambas 3.21+ como entorno de desarrollo
- Se distribuye exclusivamente como paquete .deb probado en este entorno
Esta decisión no es arbitraria. Surge de la necesidad de garantizar estabilidad, seguridad y coherencia técnica para un software que se usa en producción editorial académica.
Mi solución: restricciones intencionadas
La falta de un camino común o de una distribución líder que marque un estándar de facto en el escritorio Linux genera un entorno en el que cada proyecto debe definir sus propias reglas para evitar naufragar en la fragmentación.
En mi caso, esa definición estricta ha sido clave para lograr un software confiable.
El problema no es solo filosófico: es económico y práctico. Dar soporte oficial a múltiples distribuciones multiplicaría el tiempo de desarrollo por un factor de 3-5x, sin añadir valor real al usuario final de mi nicho específico.
Prefiero un software que funcione perfectamente en un entorno que uno que funcione de manera mediocre en diez.
Como desarrollador individual, mi tiempo es limitado. Puedo invertirlo en:
- Opción A: Probar en 10 distribuciones, gestionar bugs específicos de cada una, mantener documentación fragmentada, y ofrecer soporte diluido
- Opción B: Dominar completamente un entorno, ofrecer soporte real, documentación precisa, y garantizar estabilidad
He elegido la opción B.
La reacción esperada (y por qué no me preocupa)
Esta decisión genera cierta resistencia inicial. Muchos usuarios se muestran reticentes ante las limitaciones del entorno base. He recibido comentarios como:
- ¿Por qué no haces un Flatpak/Snap/AppImage?
- Yo uso Arch, ¿por qué no puedo usarlo?
- Deberías dar soporte a Fedora también
- Esto va contra el espíritu del software libre
Sin embargo, con el tiempo, se acepta la idea de que la estabilidad requiere disciplina, y quien no está dispuesto a adaptarse simplemente es libre para no usar la aplicación y buscar otras alternativas, o —cuando la licencia BSL convierta a GPL v3 en 2031— hacer su propia versión adaptada.
En ese sentido, esta rigidez no es una debilidad, sino una forma de garantizar que la aplicación cumpla su función dentro de su nicho: editoriales universitarias, centros de investigación y revistas académicas latinoamericanas, sean públicas o privadas sin fines de lucro.
No se trata de competir con Adobe InDesign o con otras soluciones comerciales, sino de ofrecer una herramienta funcional, confiable y segura para un sector muy específico que tradicionalmente ha sido ignorado por el software comercial.
¿Y si uso otra distribución?
Aquí debo ser completamente transparente.
La realidad técnica es que Linux Mint es un derivado de Ubuntu LTS, que a su vez es derivado de Debian. La compatibilidad técnica con Ubuntu 22.04/24.04 es alta, probablemente superior al 90%.
Gambas es un lenguaje compilado que genera ejecutables nativos. Si tu distribución tiene las bibliotecas correctas (GTK+3, MySQL/MariaDB client, libxml2, etc.), técnicamente podría funcionar.
Sin embargo, no ofrezco soporte oficial fuera de Linux Mint Cinnamon porque no puedo probar ni garantizar el comportamiento en otros entornos.
Si decides usar gbpublisher en otra distribución:
- ✅ Estás en tu derecho (la licencia BSL 1.1 lo permite)
- ✅ Estás bajo tu responsabilidad técnica completa
- ✅ Puedes compilar desde fuente siguiendo las instrucciones
- ✅ Puedes compartir tu experiencia (ayuda a otros usuarios)
- ❌ No esperes soporte oficial si algo falla
- ❌ No crees issues en GitHub sobre bugs específicos de tu entorno
- ❌ No esperes que dedique tiempo a depurar tu instalación
Esto no es hostilidad: es transparencia sobre mis capacidades reales como desarrollador individual que mantiene este proyecto junto a su trabajo principal como editor.
¿Por qué no Flatpak/Snap/AppImage?
Esta es probablemente la pregunta más frecuente, así que merece una respuesta detallada.
Estas tecnologías de empaquetado universal prometen resolver el problema de la fragmentación encapsulando las dependencias. En teoría, suena perfecto. En la práctica, para gbpublisher, introducen más problemas de los que resuelven:
Problemas técnicos específicos:
-
Dependencias del sistema: gbpublisher no es una app aislada. Necesita interactuar con Pandoc, Saxon-HE, xsltproc, TeX Live, y otras herramientas del sistema. Los sandboxes de Flatpak/Snap complican esta integración.
-
Tamaño del paquete: Empaquetar todas las dependencias de Gambas + todas las herramientas de procesamiento XML/XSLT + TeX Live resultaría en un paquete de 1.5+ GB para una aplicación que como .deb pesa ~3 MB (porque usa las bibliotecas del sistema).
-
Permisos del sistema: gbpublisher necesita acceso completo al filesystem para trabajar con proyectos editoriales, bases de datos MySQL locales, y ejecutar transformaciones XSLT. Los permisos granulares de Flatpak serían una pesadilla de configurar para el usuario final.
-
Mantenimiento: Mantener un Flatpak actualizado requiere conocer otra tecnología completa, con sus propias convenciones y problemas. Es más trabajo, no menos.
La realidad práctica:
Un .deb bien hecho en un sistema estable es más confiable, más pequeño, más rápido y más fácil de mantener que cualquier paquete universal para este tipo de aplicación.
Las tecnologías universales tienen sentido para apps genéricas y portables. Para software especializado con profundas integraciones del sistema, son una solución que busca un problema que no existe en mi caso de uso.
Sobre el idioma y la realidad del desarrollo sostenible
Siguiendo esta misma lógica, gbpublisher no ofrece soporte para múltiples idiomas: el software está únicamente disponible en español.
Esta decisión también responde al principio de sostenibilidad del desarrollo y concentración de recursos.
Pero hay algo más que vale la pena explicar: el español es idioma oficial de 21 países y lengua nativa de aproximadamente 500 millones de personas. El mercado potencial es enorme sin necesidad de internacionalización inmediata.
La audiencia objetivo —editoriales universitarias, revistas académicas, instituciones de investigación— en América Latina y España representa un nicho suficientemente grande como para justificar un desarrollo especializado.
La traducción no es solo intercambiar textos
Internacionalizar una aplicación no es simplemente traducir cadenas de texto. Implica:
- Localización de formatos: fechas, números, monedas, direcciones
- Pruebas exhaustivas: cada idioma duplica la superficie de testing
- Documentación paralela: manual de usuario, tutoriales, videos
- Soporte multiidioma: responder consultas en cada lengua
- Mantenimiento continuo: cada nueva feature multiplica el trabajo
Para un proyecto mantenido por una persona con un trabajo de tiempo completo en edición académica, esto no es realista sin financiamiento específico o un equipo de colaboradores permanentes.
Términos técnicos en inglés: una decisión pragmática
Del mismo modo, los términos técnicos que aparecen en los metadatos o en las claves de BibLaTeX se mantienen en inglés, sin traducirse.
Esto refleja una realidad práctica: el inglés sigue siendo el idioma técnico común en el ámbito académico y tecnológico. Campos como author, title son estándares internacionales.
Traducirlos a autor, título, etc., no solo rompería la compatibilidad con estándares existentes, sino que confundiría a usuarios que trabajan con otras herramientas académicas (Zotero, Mendeley, BibTeX).
Mi idioma nativo es el español, y aprendí inglés para poder interactuar con esos términos técnicos y con la documentación de desarrollo. Del mismo modo, considero válido que quien hable inglés aprenda español para interactuar con la aplicación.
No se trata de una postura confrontativa, sino de buscar un equilibrio justo entre accesibilidad y sostenibilidad del desarrollo.
Traducción futura: no descartada, pero condicionada
¿Consideraré otros idiomas en el futuro? Posiblemente, cuando se cumplan estas condiciones:
- El proyecto sea sostenible económicamente (licencias comerciales, donaciones, o financiamiento institucional)
- Exista una comunidad de colaboradores comprometida con el mantenimiento de traducciones
- Las funcionalidades core estén completamente estabilizadas
La traducción profesional y el mantenimiento multiidioma requieren recursos que hoy simplemente no tengo. Priorizar la calidad en un idioma sobre la mediocridad en varios es, nuevamente, una decisión de disciplina técnica.
Precedentes: otros proyectos académicos con decisiones fuertes
No soy el único que toma decisiones restrictivas en software académico. Muchos proyectos exitosos tienen opiniones fuertes sobre cómo deben usarse. La diferencia es que yo las hago explícitas desde el principio.
Ejemplos de software académico con restricciones:
-
Pandoc: Escrito en Haskell, un lenguaje esotérico para la mayoría. Compilar desde fuente es complejo y requiere un toolchain específico. La mayoría de usuarios usa binarios precompilados para plataformas específicas.
-
Zotero: Aunque multiplataforma, impone completamente su stack tecnológico (JavaScript/Electron) y su modelo de datos. No puedes “adaptar” Zotero fácilmente a otros workflows.
-
LaTeX/TeX Live: Ecosistema enormemente fragmentado pero con distribuciones fuertemente recomendadas. La documentación oficial prácticamente asume que usas TeX Live completo, no distribuciones mínimas.
-
R y RStudio: RStudio solo funciona con versiones específicas de R. No puedes usar cualquier versión arbitraria. Además, muchos paquetes académicos especifican dependencias estrictas.
-
JASP (software estadístico): Solo ofrece binarios para Windows, macOS y versiones específicas de Ubuntu/Debian. Ni siquiera intentan dar soporte a otras distribuciones Linux.
Todos estos proyectos son exitosos, ampliamente utilizados, y respetados en sus comunidades. Ninguno intenta ser “todo para todos”.
La lección es clara: en software especializado, las restricciones bien fundamentadas no impiden el éxito, lo facilitan.
¿No limitas tu audiencia?
Sí, y lo hago de manera intencional.
Prefiero 100 usuarios satisfechos en mi nicho que 10000 usuarios frustrados con un software que casi nunca funciona en sus sistemas variados.
Esta estabilidad no sería posible con un enfoque disperso intentando soportar docenas de configuraciones diferentes.
¿Y si Linux Mint desaparece?
Esta pregunta surge ocasionalmente y merece una respuesta seria.
Linux Mint tiene más de 15 años de historia (lanzamiento inicial en 2006) y es consistentemente una de las 3 distribuciones más populares según DistroWatch. Tiene una comunidad sólida, financiamiento estable vía donaciones y sponsors, y un modelo de desarrollo conservador y predecible.
La probabilidad de que desaparezca en el mediano plazo es bajísima.
Pero supongamos el escenario hipotético de que Linux Mint dejara de existir:
-
Migración a Ubuntu LTS: Dado que Mint es derivado de Ubuntu, la transición sería relativamente simple. La mayoría del código funcionaría sin cambios.
-
Mantenimiento del último LTS funcional: Linux Mint 22.x tiene soporte hasta abril de 2029. Eso da años de estabilidad garantizada.
-
Fork comunitario: Si Mint desapareciera, muy probablemente surgiría un fork mantenido por la comunidad (como pasó con CentOS → Rocky/Alma).
-
GPL v3 en 2031: Para entonces, la licencia estará próxima a ser GPL v3 y cualquiera podrá adaptar gbpublisher a otra plataforma.
En resumen: no estoy preocupado, y tú tampoco deberías estarlo.
Preguntas frecuentes
¿Esto va contra el espíritu del software libre?
No. El software libre es sobre libertad, no sobre obligaciones del desarrollador.
Yo tengo libertad para:
- Elegir mi plataforma objetivo
- Establecer las condiciones de soporte
- Decidir en qué invierto mi tiempo
Tú tienes libertad para:
- Usar el software en el entorno soportado
- Compilar desde fuente para tu entorno (bajo tu responsabilidad)
- Esperar a 2031 cuando sea GPL v3 y hacer tu propia versión
Nadie está obligando a nadie. Eso es libertad.
¿Por qué no aceptas pull requests para otras distribuciones?
Porque aceptar código significa aceptar responsabilidad de mantenimiento.
Si acepto un pull request que añade soporte para Arch Linux, automáticamente me comprometo a:
- Mantener ese código funcionando en futuras versiones
- Probar cada release en Arch
- Responder a bugs específicos de Arch
- Mantener documentación para Arch
No puedo hacer eso sin sacrificar tiempo de desarrollo de features core o calidad del soporte principal.
Es mejor ser honesto desde el inicio que generar expectativas falsas.
¿Puedo pagar por soporte en mi distribución?
Potencialmente, sí. Bajo la licencia BSL 1.1 puedo ofrecer licencias comerciales con términos diferentes.
Si representas a una institución que necesita gbpublisher en una distribución específica, contacta conmigo. Podemos discutir:
- Soporte comercial para tu entorno
- Desarrollo de features específicas
- Capacitación personalizada
- Consultoría para workflows editoriales
El modelo BSL permite esta flexibilidad sin comprometer la versión base libre.
¿Qué sucede en 2031 cuando sea GPL v3?
El 24 de mayo de 2031, gbpublisher se convertirá automáticamente a GPL v3.
En ese momento:
- Cualquiera podrá hacer ports a otras distribuciones
- Cualquiera podrá crear forks especializados
- Cualquiera podrá comercializarlo libremente
- Todas las restricciones BSL desaparecerán
Hasta entonces, opero bajo las condiciones BSL que me permiten sostener el desarrollo.
¿Por qué BSL y no GPL desde el inicio?
Porque necesito proteger mi inversión durante los primeros años críticos.
Desarrollar gbpublisher me ha tomado años de trabajo. Si lo lanzara como GPL v3 inmediatamente, cualquier empresa comercial podría tomar el código, hacer cambios menores y venderlo sin ningún tipo de contribución.
BSL me da 5 años de protección mientras establezco el proyecto, construyo comunidad, y potencialmente genero ingresos para dedicarle más tiempo.
Después de esos 5 años, cuando el proyecto esté establecido, GPL v3 es perfectamente apropiada.
Conclusión: calidad sobre compatibilidad universal
El software libre no es ausencia de límites, sino libertad para elegir conscientemente qué límites tienen sentido para tu proyecto.
En gbpublisher, esos límites son:
- Una distribución: Linux Mint Cinnamon (derivada de Ubuntu LTS)
- Un idioma: Español (con términos técnicos en inglés según estándares)
- Una tecnología: Gambas 3.21+ con stack documentado y probado
A cambio ofrezco:
- ✅ Software que funciona (no “debería funcionar”)
- ✅ Documentación precisa (no genérica ni vaga)
- ✅ Soporte real (respuestas informadas, no guessing)
- ✅ Estabilidad probada (testing exhaustivo en entorno controlado)
- ✅ Código auditable (fuente disponible bajo BSL 1.1)
- ✅ Futuro libre (GPL v3 garantizada en 2031)
Esta es mi forma de aportar al ecosistema académico latinoamericano: calidad sobre cantidad, profundidad sobre amplitud, estabilidad sobre universalidad.
No intento competir con soluciones comerciales como Adobe InDesign. No intento ser todo para todos. Intento ser la mejor herramienta posible para un nicho específico que tradicionalmente ha sido ignorado: pequeñas y medianas editoriales universitarias de habla hispana con recursos técnicos limitados.
Si esta filosofía resuena contigo, bienvenido/a a gbpublisher.
Si no, respeto tu decisión y te deseo éxito con las alternativas que encuentres.
Y si prefieres esperar a 2031 cuando sea GPL v3 para hacer tu propia versión adaptada a tus necesidades específicas, eso también es completamente válido.
Esa es la verdadera libertad del software libre: poder elegir.
Alberto Moyano, editor y desarrollador en estudio2a
Para obtener gbpublisher
El software está bajo licencia BSL 1.1 (conversión automática a GPL v3 en mayo de 2031).
Importante: a partir de abril estará disponible una versión RC (Release Candidate) que se terminará de pulir hasta el 24 de mayo de 2026, fecha de lanzamiento de la rama estable, a partir de ese momento se podrá acceder al formulario de solicitud.
Para solicitar acceso al paquete .deb, véase Formulario de solicitud
