Entradas
Dadas las desventajas de software propietario, especialmente en lo aue respecta a costo, empresas y usuarios en algún momento han llegado a preguntase "¿Deberia migrar mis aplicaciones a software libre?", y aunque existen múltiples razones para hacerlo, la respuesta final dependerá de muchos factores y de la valoración o importancia que tenga cada una de ellas para nosotros.
Por lo general, conviene analizar la situación de la que partimos, es decir, el estado actual de nuestros sistemas. queremos los beneficios del software libre pero llegar a ellos lo vemos muy difícil, por todo lo que ya está implantado; de alguna forma estamos asumiendo mantener una situación ineficiente, siendo conscientes de ello, por no atrevernos o saber cómo cambiarla.
Y es que cambiar los sistemas de escritorio de una organización, con todas las interrelaciones que hay entre las distintas aplicaciones y servicios, no es una tarea trivial que se pueda abordar a modo de "quick fix", como a veces pretende hacerse. Cada septiembre nos llega alguna petición del tipo "Vamos a cambiar de MS Office a OpenOffice antes de final de año. Queremos que nos ayudeis". En estos casos, al preguntar por los motivos del cambio, se repite siempre, con alguna variación, la misma razón: "Hemos recibido una carta amenazante de Microsoft. Estamos hartos de su prepotencia y abusos de precio". Nuestra siguiente pregunta siempre también es la misma: "¿Cuánto hace que estais preparando la migración?". Nunca ha habido preparación previa, este tipo de migración precipitada es siempre una migración forzada por la necesidad de esquivar la auditoría de los abogados de Microsoft. Nuestro consejo en este caso simpre capear la auditoría como se pueda, negociar lo mejor posible el pago de algunas licencias y preparar juntos la migración durante el siguiente año.
La migración a software libre debe ser resultado de una estrategia de sistemas a largo plazo. Si se va preparando la migración como un objetivo estratégico en todas las decisiones que se vayan tomando, con prevision de futuro y algo de sentido común, incluso los entornos más complejos puede migrarse completamente en 2 ó 3 años. Pero nunca en 2 ó 3 meses.
Migrar todo un entorno de usuario a software libre exige una planificación y estrategia que se debe ir desarrollado a lo largo de meses e incluso años. Preparar una migración completa en una única intervención no es realista y provocará, en la mayoría de los casos, un pequeño desastre, con la necesidad de vuelta atrás y la reticencia de los usuarios y la dirección a este tipo de proyecto en el futuro. Ello es especialmente doloroso, porque una mala ejecución impide que la empresa u organización se beneficie del software libre durante mucho tiempo a causa de las "cicatrices " dejadas en los usuarios y dirección. Por ello es muy importante contar con un buen socio tecnológico con consultores de confianza que acompañen a la empresa más allá de los proyectos concretos.
Introducir las nuevas aplicaciones de forma paulatina
Empezar la migración a software libre por el sistema operativo es en la mayoría de casos una mala idea. Debemos aprovechar que casi todas las aplicaciones de Open Source son multiplataforma para empezar el cambio por ellas. Así conseguiremos que el usuario no sufra un cambio radical de todo su entorno de golpe, sino en sólo una o dos aplicaciones cada vez. El objetivo es ir cambiando las aplicaciones propietarias disponibles para Windows que estemos utilizando por sus equivalentes de Open Source multiplataforma. Por ejemplo, podemos cambiar Internet Explorer por Firefox u otro navegador multiplataforma con relativa facilidad, y resolver los problemas que puedan surgir con este cambio sin necesidad de estructurar un gran proyecto. Una vez tengamos estabilizada nuestra infraestructura con Firefox podremos iniciar el cambio a OpenOffice.org o remplazar Outlook por otro cliente de correo, por ejemplo.
Tengamos en cuenta que cada cambio es una pequeña migración, con sus pequeños problemas, requerimientos al entorno y modificaciones en el interface del usuario. Este enfoque permite que la reacción exigida al usuario sea siempre limitada y que los planes de formación de los usuarios y la asimilación del nuevo entorno por éstos sean más sencillos. Cuando todas las aplicaciones de los usuarios sean multiplataforma podremos cambiar el sistema operativo de Windows a Linux de forma extremadamente sencilla, prácticamente sin incidencia en el usuario.
Esta aproximación nos permite, además, concentrarnos en esta última fase en buscar soluciones para las eventuales aplicaciones que quizás debamos mantener obligatoriamente en Windows en modo "legacy", con plataformas de simulación tipo Wine o CrossOver y creando un entorno virtual para la ejecución remota de estas aplicaciones con 2X o XenApp.
No empezar por lo más difícil
Lo más razonable es empezar la implantación del software libre en aquellas aplicaciones que tengan menos exigencias en el apartado de gestión del cambio, es decir, las que modifiquen menos el entorno del usuario. Eso implica que empezaremos por implantar software libre posiblemente en los servidores, por ejemplo en los servidores web, servidores de correo, servidores de aplicaciones e infraestructuras de gestión o servicios de comunicaciones. La mayoría de empresas ya han dado algún paso en este sentido.
Esta aproximación nos permite adquirir experiencia en las peculiaridades del softwre libre y generar confianza en los usuarios, dirección de la empresa y en nuestro propio equipo. En los siguientes pasos iremos migrando otras infraestructuras que tengan ya relación directa con el usuario y que se estén ejecutando en los equipos de escritorio, como el cliente de correo o el paquete ofimático.
En la migración de cada aplicativo también podríamos aplicar el mismo concepto de no empezar por lo más difícil. En general a medida que se va avanzando en la migración vamos adquiriendo experiencia y los usuarios aceptan mejor el cambio, por lo que lo que en un principio parecía difícil poco a poco se va convirtiendo en más fácil.
Visión estratégica: estándares abiertos y libres
Algo muy importante, una vez hemos decidido que queremos al menos algunos de nuestros sistemas en software libre, es no añadir dificultades a la migración con acciones equivocadas. Tenemos que evitar que eso sucede sobre todo con los nuevos desarrollos y nuevas infraestructuras que, dentro del ciclo de vida de nuestros sistemas, vamos a ir evolucionando o implantando. Un ejemplo típico es el siguiente: hemos decidido que en el próximo año queremos migrar a OpenOffice, pero a la vez ponemos en marcha una nueva aplicación de Business Intelligence que requiere Excel para sus reportes. Parece una perogrullada, pero no siempre algo tan simple se cumple, porque en la realidad estas dependencias no siempre son tan evidentes.
Una buena práctica es exigir que cualquier nuevo sistema o aplicación que vayamos a implantar trabaje con estándares abiertos y libres, y que además no exija para su funcionamiento la existencia de software propietario en nuestros equipos. Una forma práctica de conseguir eso es poner como especificación (y validarlo posteriormente) que cualquier nueva aplicación o desarrollo pueda funcionar sobre un equipo con Linux, aunque nuestra implantación en este momento no lo requiera. Con esta simple verificación nos aseguramos que no introducimos nuevos lock-in de los que luego arrepentirnos en nuestros sistemas. Análogamente deberemos pedir a los proveedores y nuestros desarrolladores internos que cualquier nueva aplicación web esté basada en estándares abiertos y pueda funcionar en los navegadores libres. En esta fase es importante no olvidar que un requisito estratégico a demandar para cualquier nueva aplicación o servicio es la interoperatividad con estándares abiertos y libres. Un protocolo abierto, estándar y libre se define como uno libre de patentes, reconocido como estándar por una organización independiente de prestigio y con al menos una implantación con software libre.
Finalmente insistir en que las nuevas aplicaciones se desarrollen de manera que sean multiplatafoma, tanto por el lenguaje en que se escriban como por las bibliotecas que utilicen para la construcción de interfaces. No utilizar nunca para nuevas aplicaciones lenguajes y APIs de arquitecturas específicas ni integrarlas de ningún modo de forma monolítica con otras aplicaciones propietarias.
Peculiaridades de la migración a OpenOffice
Un caso particular de la migración de aplicaciones de escritorio es MS Offce. La migración de las aplicaciones ofimáticas puede resultar muy sencilla o un poco más complicada en función de lo que los usuarios estén utilizando y hayan desarrollado con estas herramientas. En general es importante desincentivar el uso de macros en el lenguaje propietario de Microsoft, buscando otro modo de automatizar los procesos cuando sea necesario.
Otro aspecto deseable es evitar el desarrollo de nuevas aplicaciones con Visual Basic y MS Access, y limitar la evolución de las existentes a lo imprescindible para que no aumente su complejidad. El proceso de migración a OpenOffice es aprovechado por muchas empresas para inventariar las aplicaciones MS Access dispersas por la organización, verificar si cumplen los requisitos de seguridad exigibles por la LOPD y reorganizar totalmente esa parte de los sistemas.
Educar a los usuarios a utilizar el formato PDF para los archivos que sólo requieran acceso o ser compartidos en modo lectura facilitará también el proceso de migración de MS Office a OpenOffice posterior. Formar a los usuarios en buenas practicas de elaboración de documentos, aunque se almacenen todavía en formatos propietarios, hará que su conversión a formatos estándares y abiertos (ODF) posteriormente sea mucho más simple, prácticamente automática.
En cualquier caso, antes de empezar esta parte de la migración es importante realizar un estudio de viabilidad. Sin él la migración de las aplicaciones ofimáticas puede depararnos alguna sorpresa desagradable.
