{% include JB/setup %}

Ya hablamos de las ventajas del software libre para la administración pública y de varios motivos por los que una administración pública debía apostar por el software libre y convertirse en tractora del mismo… pero qué pasa cuando se quiere dar el paso y afrontar una migración?

Una de las primeras razones que se suelen dar para migrar a software libre es el ahorro de licencias. Aunque parezca un eufemismo a mi me gusta más hablar de racionalización del gasto y tiene un por qué y no es aquello de llamarle desaceleración a la crisis. Un proceso de migración a software libre implica un gasto, una inversión importante para llevar a cabo un proyecto que no es sencillo, así que de primeras no es sólo ahorrar en licencias. El por qué me gusta usar racionalización del gasto es porque sí se deja de gastar en licencias de software privativo que van a parar a grandes empresas extranjeras y se empieza a gastar en tejido empresarial local, bien sea en consultoría para la migración o en el soporte a las soluciones libres empleadas, ejerciendo de cabeza tractora del tejido local. A medio plazo sí hay además un ahorro, ya que el soporte sobre una solución libre suele ser mucho más económico que los grandes contratos corporativos de las soluciones privativos.

Afortunadamente tenemos varios procesos de migración a software libre dentro de administraciones públicas y cada vez hay más que se lo están planteando y empiezan a dar pasos en esa dirección. Afortunadamente también hay quienes cuenta y documentan estos procesos, de los cuales se puede aprender mucho. Un documento que me ha parecido muy interesante es el de la migración del escritorio a software libre del ayuntamiento de Zaragoza. Es un documento muy completo al que merece la pena echar un vistazo ya que cuenta aspectos técnicos, metodológicos y analiza problemas con los que cualquiera se puede encontrar en un proceso similar.

Sin querer desgranarlo en detalle ya que como digo, vale mucho la pena su lectura completa, si me gustaría comentar algunas ideas clave:

No identificación de gastos adicionales: Esto ya lo he comentado antes, pero me parece clave su entendimiento para que estos procesos tengan éxito. Hay que asumir que el ahorro viene a medio o incluso largo plazo, y que a corto es necesaria una fuerte inversión. El proceso de migración consumirá muchos recursos, será necesario invertir en formación, en algún caso puede requerir la adquisición e hardware, ya que es conocido que hay casos en los que éste no es compatible con el software libre, o será necesario invertir en desarrollar controladores que lo hagan compatible. Puede ser necesario llevar a cabo adaptaciones del software en algunos casos, lo cual será una ventaja también pero que supone un coste. Mucho software privativo no me permite una sencilla exportación de los datos lo que puede implicar procesos de conversión manuales o costosos, y por último es necesario tener en cuenta los costes de soporte y mantenimiento del software.

Nichos donde el software libre puede no ofrecer soluciones suficientemente maduras: No nos engañemos, hay ciertos nichos muy específicos donde el software libre puede no ofrecer soluciones lo suficientemente maduras o carecer de ciertas funcionalidades imprescindibles. Pero esto no tiene por que ser un problema que pueda llegar a condicionar la migración. Primero, estos casos probablemente puedan suponer un porcentaje muy bajo dentro de los equipos a migrar y se puede optar por soluciones mixtas en las que puedan convivir determinadas soluciones privativas en un entorno migrado a software libre. Técnicamente es posible y no supone mayor problema que el mantener un cierto coste de licencias en software privativo. Es importante identificar bien el número de casos reales que puede haber de este tipo y establecer los mecanismos para la convivencia y que no supongan un obstáculo para compartir información.

Empezar de arriba hacia abajo: Muchos procesos de migración empiezan con pequeños pilotos, migrando un subconjunto de equipos por ejemplo. Se puede tender a empezar migrando equipos “poco importantes” por miedo a que el proceso no vaya bien y que interfiera en los trabajos. Para mi esto es un error. Si bien la realización de pilotos me parece acertada y puede servir para tener más claro los requisitos, las tareas a abordar, identificar posibles problemas, etc… creo que la realización de un piloto tiene que implicar equipos importantes e implicar por ejemplo a un servicio completo, desde la dirección hasta el funcionariado base. El apoyo de la dirección en los procesos de migración es fundamental y deben de ser los primeros en implicarse, ya que eso motivará y facilitará el proceso al resto de implicados. Si a ti te cambian tu software de ofimática privativo por una solución libre y a tu jefe no, cuando te pida un informe, documento o lo que sea, es fácil prever que va a haber un problema.