Código abierto en la eAdministración en España: ¿Qué hay que cambiar para impulsarlo?

Quiero ir un poco en orden de lo más estructural a lo más operativo que, además, marca un poco el paso de lo general a lo concreto.

Compromiso político con el código abierto en la eAdministración

Empecemos por el principio. En España el presupuesto es lo que alimenta a la Administración y este tiene un componente que es, lógicamente, político. Es decir, apostar por el código abierto es una apuesta política porque cuesta dinero (luego hablaremos de este tema). La cuestión es que, para cualquiera que esté cerca de la Administración, la continuidad de políticas es tan escasa como los unicornios o los vellocinos de oro.

Es muy frecuente que lo que un gobierno a impulsado y potenciado cambie con el siguiente si hay un cambio de color (como vimos con el gobierno abierto). Ojo, no digo que sea culpa de los políticos (no es mi cosa juzgar), pero la necesidad de diferenciarse en un mercado político tan competido, lleva a maximizar gestos, tanto en políticas «muy visibles» como en otras que no lo son tanto. Iniciativas como el LinEx y similares se han visto desplazados con un cambio de mayoría.

Estrategia de liderazgo del codigo abierto en la eAdministración

Esto influye, aunque no es la única causa, en una falta de liderazgo en el proyecto. Una estrategia de código abierto desarrollado por la Administración es una apuesta a largo plazo. Esto requiere un liderazgo y una continuidad que tampoco encontramos normalmente en la Administración Pública en España. Normalmente sólo encontramos perfiles consolidados en áreas muy técnicas que no suelen tener relumbrón de primer orden (y exigen competencias que limitan la «elegibilidad» de candidatos más afines al partido).

También es cierto que nos encontramos con una especie de pescadilla que se muerde la cola: no hay liderazgo por la dinámica política, pero tampoco hay una visión política porque la Administración no ha sido capaz de generar un liderazgo que arrastre a los políticos.

A todo lider político le gusta hablar de mejorar la Administración (que siempre es mala) hacerla más moderna y sencilla (viva la tautología), pero no suelen ser demasiado concretos. Con esas mimbres, no tenemos un futuro prometedor

Foco en qué hacer con el código abierto en la eAdministración

Un tercer elemento, también derivado de los anteriores, es la falta de foco. Vale, podemos decir que la Administración electrónica en España ha tenido un foco claro: la mejora de procedimientos internos. Sin embargo este foco hace menos relevante la elección de software. Antes de que cojas la antorcha y pegues fuego al ordenador, deja que me explique.

La mayoría de las acciones que hemos centrado en la Administración en España tienen una visión interna y vertical. Registros, firmas, facturas, intercambios de datos, etc… son elementos que, generalmente permiten sumarte o no sumarte. Poco más. No suelen ser proyectos en los que el aporte o la capacidad de adaptación sea importante. Es decir, hablamos de tomar una decisión una vez y, a partir de ahí, a correr.

¿En qué nos afecta esto? En que cuando hay un foco común y un enfoque más abierto exige más aportación y esfuerzo de quien lo usa (también hablaremos de eso). Eso requiere un enfoque abierto y una idea clara de cuál es el horizonte de trabajo. No en vano, parte del trabajo en Canada o Reino Unido son interfaces para el diseño web… algo que aquí no ha importado nunca demasiado.

La estructura de la Administración Pública.

La Administración en España tiene un modelo organizativo que es el que es y que tiene algunas limitaciones. Una de ellas es que, quizá, el modelo de función pública no sea el mejor para esto. Pensemos que tenemos que tener, normalmente, alguien que aprueba unas oposiciones y que luego acabe donde se desarrolla el software. Luego eso nos supone un coste de actualización, especialización y reciclaje que puede que no esté ahí.

Podríamos optar a modelos de agencias (cuyo proyecto fue defenestrado ya no por un gobierno de distinto color, sino por una ministra del mismo partido que la creó), que flexilbilizara la contratación y gestión de personal. No en vano, tanto el CDS de Canada, como el USDS de USA, como el GDS de Reino Unido son Agencias que buscan profesionales del sector privado según sus necesidades.

Cuesta pensar que a la hora de elaborar el software, contar con empleados públicos como solemos encontrar en Espala (y autonomías), la cosa es complicada. Esto nos lleva al siguiente problema.

El modelo de construcción y proveedores en la Administración

Si no tenemos medios para construir por nuestra cuenta, hay que contratar quien lo haga. Esto nos lleva a todos los problemas de la contratación tecnológica que ya hemos tratado con algunos resultados no del todo óptimos.

Es relativamente frecuente encontrar proveedores privados que hacen código abierto para administraciones públicas con dos problemas. El sistema que prima los precios da lugar a resultados miuy flojos (no voy a decir nombres, porque sería otro debate). Por el otro, suelen ofrecer (si ofrecen) un mantenimiento bastante deficiente, especialmente la lógica del producto, lo que supone un problema del que, una vez más, hablaremos después.

Finalmente,varios modelos de software libre precisan proyectos de consultoría complicados que dejan la alegría del software libre en mal lugar cuando llega el presupuesto de implantación (de nuevo, no digo nombres para herir sensibilidades).

Si revisamos la mayoría de soluciones de software libre para AAPP en España de 2010 no creo que haya muchas activas en la actualidad.

El modelo de reutilización del código abierto en la eAdministración

Normalmente la reutilización se ha centrado en la implantación y luego, ir tirando con el mantenimiento, encontrando, a lo largo del tiempo, casi tantas versiones de un software como instalaciones. La falta de un sistema de mantenimiento y de un control centralizado de versiones hace que cualquier actualización sea una bomba de relojería.

A esto se suma el intento del Centro de Transferencia Tecnológica en el que, en mi opinión, hemos logrado hacer un aparcamiento de proyectos de software casi como el cementerio de Google. La asimilación del software requiere promoción, visualización y convertir a sus implementadores en clientes del creador del servicio. Código abierto no es código del que me olvido… al contrario, como las plantas, las amistades y las relaciones, hay que mimarlo todos los días.

La dispersión entre agencias

Tenemos una organización que lleva para la AGE que ofrece servicios para quien lo pida, y luego un montón de agencias que tienen aplicativos específicos y que, acaban generando sus estructuras. En mi opinión este enfoque es válido pero tiene una expasión y replicabilidad limitadas. Es decir, el PAE hace las cosas del PAE y luego cada administración hace sus cosas. Encuentras diseños desiguales, contenidos repetidos y casos muy diversos.

En términos generales la sensación es:

1. se crea una obligación para las AAPP
2. Cada administración cumple lo que tiene que cumplir y, según sus medios, hace luego ya lo que le parece más adecuado
3. quien no tiene medios, zozobra cumpliendo lo obligado y no tiene más medios para hacer algo adaptado a sus necesidades.

Si queremos apostar por el código abierto necesitamos un enfoque más flexible, pero recursos TIC para cada agencia formados y preparados para implantarlos y ejecutarlos de manera eficaz. Si no, tenemos un tren descarrilado.

La variable política.

Ahora vamos a la parte escabrosa en España. A muchas CCAA (casi todas, diría yo) les importa una pococualquier cosa que venga de la AGE, sea bonita, fea o mala. La AGE tampoco parece estar especialmente abierta a incorporar en su nucleo soluciones de origen autonómico (aunque hay excepciones). Aquí entra de nuevo la variable política. Me cuesta creer que la gente que trabaja en esto a la que conozco y respeto no colabore más por voluntad y necesidades propias que por agendas políticas de diferenciación y generación de industria interna.

Crear software de código abierto requiere dos cosas en cierta cantidad:

1. Usuarios
2. Dinero

Una visión fragmentada y segmentada como la que tenemos, dificulta tener lo primero y hace que gastar el segundo tenga menos sentido. ¿Qué alcance real puede tener una aplicación en la que vamos a tener implantaciones muy limitadas como para invertir mucho dinero? Porque, aquí vamos con el último punto.

El mantenimiento del código abierto en la eAdministración

El código abierto para funcionar bien requiere mantenimiento, y mucho. En muchos casos, esto lo hace la comunidad. En el caso de la Administración no podemos esperar una comunidad por implicaciones de responsabilidad jurídica y técnica, así que tiene que ser, en principio esa agencia, la que impulse y mantenga las aplicaciones.

El mantenimiento es la parte menos glamourosa del software pero, sin duda, la que le da la vida. Requiere recursos especializados y formados, protocolos (usando gits y demás que permitan controlar peticiones y versiones) y muchas personas trabajando y tomando decisiones que, a veces, no gustan. Cuesta dinero (mucho) y conflictos (no pocos).

Esto nos trae a la primera parte: el presupuesto y la política. Igual que no suele haber políticos que se hacen fotos con cuadrillas de reparación y prefieren inauguraciones, gusta sacar la nueva web, pero no importa tanto resolver incidencias (salvo crisis mayores), como para gastar dinero.

Si no quieres mantener el código abierto (y pagar), no te metas en esto.

Conclusiones

Como he dicho muchas veces, puedo tener mis preferencias sobre un sistema propietario o uno libre, pero estoy en contra de ir a medias tintas, sobre todo en el segundo caso. Hacer un sistema basado en código abierto en la eAdministración sin garantizar las condiciones necesarias para que funcione de manera satsfactoria es la mejor manera de invertir tiempo, esfuerzo y dinero en crear quebraderos de cabeza y malestar a quienes lo usan, sea la ciudadanía o las personas que trabajan en la Administración.

En este sentido, creo que si en España se da este salto (lo que no creo que pase, vista la evolución a nivel nacional y autonómico), hay que plantear una serie de cambios estructurales que faciliten el cambio. En mi opinión (y aquí si me mojo), esta es la mejor opción, pero no parece un camino fácil.