Seguro que os ha pasado alguna vez: intentáis abrir un documento oficial de la administración, o quizás un archivo que os ha pasado un cliente, y de repente el ordenador empieza a quejarse. Que si la versión no es compatible, que si necesitas pagar una suscripción de tres cifras al año para ver una tabla de Excel, o que si el formato es tan cerrado que parece que lo ha diseñado un búnker suizo. Es una situación frustrante, y la verdad es que, a estas alturas de la película, resulta hasta un poco ridícula.
En el mundillo de la tecnología, y sobre todo cuando hablamos de la gestión pública o de grandes infraestructuras, hay un concepto que suena a música celestial para unos y a pesadilla logística para otros: el Plan de Implementación de Software Libre y Estándares Abiertos (lo que los amigos de las siglas llaman PISLEA). No es solo una declaración de intenciones de esas que se quedan cogiendo polvo en un servidor; es, o debería ser, la hoja de ruta para que dejen de tomarnos el pelo con las licencias propietarias.
Vaya, que la idea es sencilla: dejar de depender de empresas extranjeras que nos dictan cómo y cuándo podemos acceder a nuestra propia información. Y ojo, que esto no va solo de ahorrar cuatro duros en licencias de Office, que también, sino de algo mucho más profundo que en España solemos olvidar: la soberanía tecnológica. Si estamos en Cartagena, por ejemplo, y queremos que nuestro sistema de gestión de aguas o el padrón municipal no dependan de un señor que vive en Seattle y que puede decidir mañana que el soporte se acaba, tenemos que mover ficha.
A veces se confunde el software libre con el «gratis». Y claro, a todos nos gusta que no nos cobren, pero la clave aquí no es el precio, sino la libertad. Es como si te compras un coche y el fabricante te prohíbe abrir el capó para ver cómo funciona el motor o, peor aún, te obliga a ir a su taller oficial incluso para inflar las ruedas. El software libre es ese coche que viene con el manual de despiece completo y te permite cambiarle las piezas o mejorarlo si tienes la maña suficiente.
Para que un plan de implementación funcione, hay que entender las cuatro libertades fundamentales. No me voy a poner en plan profesor de universidad, pero para que nos entendamos: puedes usarlo para lo que quieras, puedes estudiar cómo funciona (ver el código fuente), puedes hacer copias y puedes mejorarlo para que otros se beneficien. En una administración pública española, esto es vital. Si el Ministerio de Obras Públicas desarrolla una herramienta para gestionar licitaciones con dinero de nuestros impuestos, ¿no tendría sentido que el Ayuntamiento de Cartagena pudiera usarla y mejorarla sin pagar de nuevo?
La verdad es que, históricamente, en España hemos tenido intentos muy valientes. ¿Os acordáis de Linex en Extremadura o de Guadalinex en Andalucía? Fueron pioneros. Sin embargo, muchas veces estos proyectos se daban de bruces con la realidad: la falta de estándares abiertos. Porque de nada sirve tener un sistema operativo libre si luego los documentos que te envía el ministerio de turno solo se abren bien con un software privativo específico. Ahí es donde entran los estándares abiertos, los verdaderos héroes olvidados de esta historia.
Los estándares abiertos: el lenguaje común que nadie debería poseer
Imagina que intentas hablar con alguien, pero para que te entienda tienes que pagarle un canon a una empresa que es dueña del idioma español. Suena a distopía, ¿verdad? Pues eso es lo que pasa cuando usamos formatos de archivo cerrados. Un estándar abierto es como el sistema métrico decimal: es de todos, cualquiera puede fabricar una regla de un metro y siempre medirá lo mismo.
En un plan de implementación serio, el uso de formatos como el ODF (Open Document Format) para textos o el PDF/A para archivado a largo plazo es innegociable. Y es que, al final del día, lo que importa no es qué programa usas hoy, sino si dentro de cincuenta años alguien podrá leer el acta de un pleno municipal o los planos de una obra en el puerto de Cartagena sin tener que buscar un ordenador de museo en Wallapop.
¿Por qué nos cuesta tanto dar el paso?
La teoría es preciosa, pero la práctica es harina de otro costal. Implementar software libre en una organización grande es como intentar cambiarle las ruedas a un camión mientras va a 120 por la autovía hacia Murcia. Hay varios frenos que siempre aparecen:
- La inercia del «siempre se ha hecho así»: El miedo al cambio es humano. Si un administrativo lleva veinte años usando la misma herramienta, decirle que ahora el botón de «guardar» está en otro sitio puede provocar un pequeño motín.
- El efecto red: «Es que todo el mundo usa el otro programa». Es el argumento circular por excelencia.
- El soporte técnico: Existe el mito de que el software libre no tiene soporte. Mentira. Lo que no tiene es un número 902 donde te atiende un bot. Tiene comunidades globales y empresas locales (muchas de ellas españolas y muy buenas) que viven de dar ese soporte.
Fases de un plan de implementación que no sea un desastre
Si mañana me dijeran que tengo que organizar la migración a software libre de una entidad pública o una empresa en Cartagena, no lo haría de golpe. Eso es suicidio digital. Un PISLEA bien estructurado suele seguir estas etapas, y creedme, saltarse una es comprar papeletas para el fracaso.
1. El diagnóstico (o «qué narices tenemos instalado»)
Antes de borrar nada, hay que auditar. Necesitas saber qué licencias estás pagando, qué programas se usan de verdad y, lo más importante, qué dependencias críticas existen. A veces te encuentras con una macro de Excel hecha en 1998 que es la que mantiene en pie todo el departamento financiero. Si no identificas eso, el día que instales LibreOffice se para el mundo.
Para los que os gusta el código, una forma sencilla de empezar a auditar en entornos Linux (que es donde suele empezar la migración de servidores) es usar scripts que identifiquen paquetes y sus licencias. Aquí os dejo un ejemplo rápido en Python que podríais usar para listar qué tenéis en un sistema basado en Debian/Ubuntu:
import apt
def listar_paquetes_y_licencias():
cache = apt.Cache()
print(f"{'Paquete':<30} | {'Versión':<20}")
print("-" * 55)
for pkg in cache:
if pkg.is_installed:
# Aquí podríamos filtrar por secciones o licencias si tuviéramos los metadatos
print(f"{pkg.name:<30} | {pkg.installed.version:<20}")
# Esto es solo un aperitivo, en un entorno real usaríamos herramientas como 'license-check'
Vaya, que no es física de partículas, pero requiere orden. La clave aquí es detectar el «vendor lock-in» o secuestro del proveedor. Si tus datos están en una base de datos que solo se puede leer con un software que cuesta 50.000 euros al año, tienes un problema de rehenes, no un problema técnico.
2. La migración progresiva: servidores primero, escritorio después
Casi siempre se empieza por «debajo». Los servidores son los candidatos perfectos. La mayoría de internet ya corre sobre software libre (Linux, Apache, Nginx, PostgreSQL). Es invisible para el usuario final, pero el ahorro y la estabilidad que ganas son brutales.
Luego viene lo difícil: el escritorio del usuario. Aquí es donde entra la psicología. No puedes llegar un lunes y quitarle el Windows a todo el mundo. Lo ideal es empezar introduciendo herramientas multiplataforma. Primero instalas Firefox, luego VLC, luego LibreOffice… y cuando el usuario ya se siente cómodo con las aplicaciones, cambiar el sistema operativo de base es mucho menos traumático.
3. Formación y acompañamiento (el factor humano)
Este es el punto donde fallan el 90% de los planes. Se gastan miles de euros en servidores y cero en explicarle a la gente cómo usarlos. Hay que dar cursos, sí, pero cursos útiles. No me cuentes la historia de Richard Stallman y la impresora; enséñame cómo hacer una tabla dinámica en Calc o cómo compartir archivos en Nextcloud de forma segura.
La importancia de la soberanía de datos en el contexto español
Ojo con esto, porque es un tema serio. En España, como miembros de la Unión Europea, estamos sujetos al RGPD (Reglamento General de Protección de Datos). Cuando usamos nubes propietarias de empresas de fuera de la UE, a veces estamos caminando por el filo de la navaja legal.
Un plan de implementación de software libre permite que los datos de los ciudadanos de Cartagena se queden en servidores controlados por la propia administración, o al menos en proveedores locales que cumplan a rajatabla la normativa europea. No es solo una cuestión de «libertad», es una cuestión de seguridad nacional y privacidad ciudadana. Si usamos soluciones como Nextcloud en lugar de Google Drive, nosotros tenemos la llave de la caja fuerte. Literalmente.
Casos de uso: ¿Qué herramientas deberían estar en cualquier PISLEA?
Para que este artículo no sea solo filosofía, vamos a bajar al barro. Si estás montando un plan de estos, estas son las piezas del Lego que no te pueden faltar:
- Sistema Operativo: Debian o Ubuntu (por su estabilidad y gran comunidad en España). Para entornos muy críticos, Red Hat (o sus derivados libres como AlmaLinux).
- Ofimática: LibreOffice es el rey, pero ojo a OnlyOffice si buscas una interfaz más moderna y mejor compatibilidad con formatos de Microsoft.
- Base de Datos: PostgreSQL. Es, sencillamente, la mejor base de datos de código abierto del mundo. Robusta, escalable y con un soporte para datos geográficos (PostGIS) que para una ciudad como Cartagena, con todo su patrimonio arqueológico, es una joya.
- Colaboración: Nextcloud. Es mucho más que un sitio donde guardar archivos; es una suite completa con calendario, chat y videoconferencia.
- Gestión de contenidos: WordPress o Drupal. La mayoría de las webs municipales ya los usan, y por algo será.
La verdad es que la madurez de estas herramientas es asombrosa. Ya no estamos en los años 90, cuando configurar una tarjeta de sonido en Linux era un rito de iniciación que duraba tres días. Hoy en día, en muchos aspectos, el software libre es técnicamente superior al privativo.
El papel de la Inteligencia Artificial en el software libre
No quería tocar el tema porque parece que hoy en día si no hablas de IA no te publican nada, pero es que aquí el software libre tiene mucho que decir. Estamos viendo cómo grandes corporaciones cierran sus modelos de IA, convirtiéndolos en cajas negras donde no sabemos qué pasa con nuestros datos ni cómo se han entrenado.
Frente a eso, están surgiendo modelos abiertos. En España, se está impulsando mucho el uso de modelos que hablen bien nuestras lenguas (castellano, catalán, gallego, euskera). Un plan de implementación moderno debe incluir cómo vamos a usar la IA de forma ética y abierta. Si el Ayuntamiento de Cartagena quiere poner un chatbot para ayudar a los turistas a encontrar el Teatro Romano, mejor que sea un modelo que podamos ejecutar en nuestros servidores y que no envíe cada pregunta a un servidor en California.
¿Cómo medir si el plan está funcionando?
No vale con decir «ya hemos instalado Linux en diez ordenadores, misión cumplida». Hay que medir. Pero no solo el ahorro económico (que a veces tarda en llegar por la inversión inicial en formación), sino otros indicadores:
- Independencia del proveedor: ¿Podemos cambiar de empresa de mantenimiento sin tener que cambiar de software? Si la respuesta es sí, vamos por buen camino.
- Interoperabilidad: ¿Nuestros ciudadanos pueden enviarnos documentos en formatos abiertos y nosotros podemos responderles igual?
- Seguridad: ¿Cuántas vulnerabilidades hemos detectado y parcheado gracias a tener acceso al código o a una comunidad activa?
- Contribución: ¿Estamos devolviendo algo a la comunidad? Un buen plan de software libre también implica que, si mejoramos una herramienta, liberamos esa mejora.
Para que nos entendamos, esto es como cuidar un jardín. No basta con plantar las semillas; hay que regar, quitar las malas hierbas y, de vez en cuando, compartir los esquejes con los vecinos.
Reflexión final sobre el terreno
Al final del día, la implementación de software libre y estándares abiertos no es una cuestión técnica, es una decisión política y estratégica. En España tenemos el talento; hay desarrolladores y administradores de sistemas en cada rincón, desde Cartagena hasta Gijón, que son auténticos cracks en esto. Lo que falta, a veces, es la valentía de romper con los contratos de mantenimiento de toda la vida que nos tienen atados de pies y manos.
La conclusión que saco de todo esto es que el PISLEA no debe ser un documento estático. Debe ser algo vivo, que se adapte a las necesidades reales de la gente. Porque la tecnología debería estar a nuestro servicio, y no nosotros al servicio de la tecnología (o de las facturas de las grandes tecnológicas).
Vaya, que si queremos una administración moderna, transparente y, sobre todo, nuestra, el camino pasa por el código abierto. Y si por el camino nos ahorramos unos euros que puedan ir a restaurar otra joya de nuestro patrimonio o a mejorar los servicios públicos, pues bienvenido sea. Que ya va siendo hora de que seamos nosotros los que tengamos las llaves de nuestro propio motor digital.
Deja una respuesta