Migración al Software Libre
AIMME ITI
Foto Temática
Triángulo Submenú
Requisitos
Estado actual

La primera tarea a llevar a cabo es la de determinar cuál es el estado actual de la empresa, intentando recopilar la mayor cantidad de información posible. Esta información nos permitirá conocer en profundidad todo el entorno que estemos intentando migrar, lo que nos permitirá elaborar los informes necesarios para que las personas encargadas de tomar las decisiones puedan tomar las decisiones óptimas en cada caso. Para esta recopilación de datos podemos servirnos de plantillas de preguntas e incluso de software especializado.

Descripción general de la empresa

Cuanto más profundamente se comprenda la actividad de la empresa, más posibilidades hay de encontrar la solución óptima para una migración. Sobre todo si la migración se va a llevar a cabo por personal externo a la compañía. Por eso se debe realizar una descripción previa de la empresa en la que se mencione a qué actividad se dedica la empresa, cuántos años de experiencia tiene en el sector, cuántos empleados tiene, cuales son sus objetivos y toda la información que se considere de interés. En los siguientes puntos se comentan los diferentes aspectos en los que se debe profundizar para poder llevar a cabo una buena planificación que garantice el éxito de la migración.

Aspectos técnicos

El inventario del software

Realizar un inventario de software de la organización. Esto es, un listado con todos los programas que se utilicen en los equipos a migrar. El inventario dependerá del tipo de sistemas que se vayan a migrar, si se van a migrar los servidores se hará un inventario del software que se utiliza en dichos servidores, si se migran los equipos de escritorio hacer un inventario de todo el software que hay en esos equipos. Esto nos servirá para identificar todas las aplicaciones, servicios y configuraciones especiales que se necesitan tener en cuenta en el plan de migración.

Las cuestiones clave que debe responder el inventario son las siguientes:

  • ¿Qué aplicaciones de terceras partes están instaladas y se utilizan?
    Esto generará una lista de software incluyendo las versiones utilizadas y los potenciales parches aplicados.
  • ¿Qué software desarrollado por la empresa se utiliza?
    Esto resultará en una lista de software desarrollado y mantenido internamente en la compañía, que puede necesitar ser portado a GNU/Linux o a un entorno independiente de la plataforma.
  • ¿Qué aplicaciones requieren acceso a datos externos?
    Esto resultará en una lista de software que accede a servidores de ficheros, servidores de aplicaciones, servidores web, bases de datos, mainframes o cualquier otra implementación de proceso de datos.
  • ¿Hay definidos grupos de usuarios? ¿Cómo se caracterizan?
    Esto debería proporcionar una visión global de si hay grupos o usuarios típicos, y de ser así cómo se agrupan. La agrupación se puede hacer por departamentos, aplicaciones que se utilizan, tipo de trabajo o responsabilidad en el negocio.
  • ¿Qué software relacionado con la seguridad se utiliza? ¿Qué procesos y reglas de seguridad se aplican?
    Esto dará una vista de qué productos se utilizan para asegurar los PC, como por ejemplo antivirus, seguridad de escritorio, escaneo de puertos, así como reglas de cómo se instalan dichas aplicaciones, cómo se mantienen, actualizan y cómo se instruye al usuario para que las utilice. También se deben incluir las políticas de aplicación de parches de seguridad de cualquier componente del sistema operativo o cualquier aplicación instalada.

Este inventario nos servirá después para identificar aplicaciones que pueden ser migradas, las que no, las que pueden serlo parcialmente y las que no se utilizan o no son necesarias, y proporciona una información de partida para poder realizar una migración consistente y homogénea.

¿Qué es una aplicación no migrable? Vamos a considerar una aplicación no migrable cuando una o más de las siguientes afirmaciones a cerca de un software sean ciertas:

  - No existe una versión software libre o una alternativa a la aplicación.
  - No es factible portar la aplicación a software libre.
  - Las restricciones en la licencia de la aplicación hagan su migración
     imposible o muy cara.

El inventario de software puede ser realizado a mano, examinando el contenido de los equipos, pero cuando se dispone de una gran cantidad de equipos o ningún control sobre el software que los usuarios han podido ir instalando, el proceso puede ser demasiado costoso. Para hacer este proceso menos costoso, se recomienda el uso de sistemas de inventariado automático. Se pueden utilizar aplicaciones específicas para realizar esta tarea, como el OCS Inventor. En http://www.ocsinventory-ng.org/ podrá encontrar más información. Se pueden encontrar más proyectos similares en http://www.sourceforge.net haciendo una búsqueda con las palabras clave "software inventory".

Pulse para ampliar

Ejemplo de OCS Inventory, accediendo a los datos de inventario vía Web.

En caso de no poder llevar a cabo un inventariado automático puede ser de utilidad establecer una categorización de software para así poder llevar un orden en el inventariado y poder identificar mejor los grupos de aplicaciones de interés. Una posible categorización puede la que se muestra a continuación.

Sistemas Diseño
Sistemas operativos
Antivirus
Backup
Compatibilidad Windows
Proxy/Firewall
Servidor Web/FTP
Servidores correo electrónico
Comunicaciones
Clientes correo electrónico
Clientes FTP/SCP
Control remoto
Envío / Recepción Faxes
Mensajería instantánea
Navegador Web
3D
CAD / CAM / CAE
Editores de imágenes simples, vectoriales o avanzados
Bases de Datos
Servidores de bases de datos
Gestión
CRM y ERP
e-Learning
Ofimática Finanzas
Agendas y calendarios
Compresores
Diagramas
Diccionarios
Encriptación
Multimedia
Paquetes
PDF
Traductores
Gestión de la producción (GPAO)
Gestión de proyectos
Gestión del conocimiento
Trabajo en grupo
OLAP
Punto de venta
Gestión documental

El inventario de hardware

Realizar un inventario completo de los sistemas que se hayan seleccionado para la migración. El inventario de hardware permitirá identificar cualquier incidencia con el soporte de hardware y nos ayudará a definir reglas para comprar o reemplazar sistemas en un futuro.

Las preguntas a realizar en este área serian las siguientes:

  • ¿Qué hardware está en uso actualmente? Indicar el Vendedor, tipo y modelo.
  • ¿El tipo de hardware está estandarizado? Si todas las máquinas son iguales, entonces el soporte de drivers y sistema operativo debería ser significativamente más sencillo.
  • ¿Qué dispositivos periféricos están actualmente instalados y son requeridos por los usuarios? Esto incluye cualquier tipo de impresoras, escáneres o dispositivos especiales.
  • ¿El soporte de GNU/Linux está incluido en los requisitos a los vendedores de hardware cuando se adquiere hardware nuevo?
  • ¿Cuáles son los componentes clave del hardware requeridos actualmente por los usuarios? Por ejemplo, las máquinas pueden llevar tarjetas de sonido incorporadas, pero los drivers no están instalados dado que los usuarios no van a utilizar el sonido. De esta manera el soporte de sonido en GNU/Linux no estaría incluido.
  • ¿A qué tipo de dispositivos extraíbles se debe dar soporte? Por ejemplo la sincronización de calendarios u otros datos con PDAs o smartphones puede ser un requisito. También, lápices USB, dispositivos Bluetooth y discos duros externos firewire se han hecho muy populares, aunque algunas organizaciones no los permiten debido a motivos de seguridad. Puede ser necesario dar soporte a dichos dispositivos o explícitamente no incluir el soporte para alguno de estos dispositivos.

Se recomienda la utilización de sistemas de inventario automático. Como GLPI o OCSInventory. Se pueden encontrar diversos sistemas de estas características en http://www.sourceforge.net estableciendo "hardware inventory" como criterio de búsqueda.

Al realizar este inventario también se deben tener en cuenta las máquinas retiradas, normalmente la mayoría de herramientas basadas en software libre suelen requerir máquinas con pocos recursos, por ejemplo las herramientas de gestión de red (firewall, router, etc...) o servidores de impresión, incluso servidores de bases de datos o servidores web pueden ser ejecutados completamente en modo texto, de esta manera una máquina retirada por no poder ejecutar fluidamente el "pesado" software propietario puede convertirse en un servidor más que eficiente.

Se debe proporcionar el máximo nivel de detalle en el listado de hardware ya que esto nos permitirá saber de antemano si el hardware del que se dispone está soportado en Software libre de manera nativa o no. Por ejemplo algunas tarjetas de red inalámbrica (Wireless, también conocido como Wi-Fi) no disponen de un driver nativo para sistemas operativos basados en software libre, pero se pueden hacer funcionar gracias a emuladores que permiten ejecutar el driver propietario. Si no se dispone de un sistema automático de inventariado de hardware se propone la siguiente plantilla para rellenar con los datos de cada equipo.

Plantilla:

Nombre del equipo: Comentarios:
   
Sistema Operativo: Procesador:
Nombre
Versión
Service Pack
Tipo
Velocidad
Num. procesadores
Memoria RAM
(Lista con la siguiente info):
Almacenamiento (Lista):
Descripción (DIMM, SIM...)
Capacidad
Velocidad (MHz)
Número de Ranuras
Fabricante
Modelo
Descripción (IDE, SCSI...)
Tipo (CD-ROM, HD, DVD-ROM...)
Tamaño (MB)
Particiones (Lista): Dispositivos de entrada (Lista):
Letra
Tipo (Primaria, Secundaria...)
Sistema de archivos
(Ext3, NTFS, VFAT...)
Tamaño (MB)
 
BIOS: Sonido:
Número serie
Fabricante
Modelo
Versión
Fecha
Fabricante
Nombre
Descripción
Tarjeta vídeo: Monitor:
Nombre
Chipset
Memoria (MB)
Resolución
Nombre
Fabricante
Tipo (CRT, TFT...)
Resolución
Red (Lista): Impresora:
Tipo (USB, paralelo, FireWire...)
Nombre
Libre (Si, No)
Descripción
Nombre
Fabricante
Modelo

Se deben incluir también en el inventario todos aquellos dispositivos pertenecientes a terceros, como por ejemplo un Router perteneciente al ISP.

Diagrama de estructura

Es conveniente tener una idea clara de donde están ubicados todos los equipos que se van a migrar y realizar un diagrama de estructura que describa estas localizaciones. Algunas cuestiones que se pueden plantear para entender mejor este concepto son:

  • ¿Todos los ordenadores se encuentran en la misma sala?
  • ¿Existe una sala en la que se encuentren todos los servidores de la empresa (en caso de que hayan)?
  • ¿Hay equipos distribuidos en diferentes salas, despachos, pisos de un edificio o incluso diferentes edificios?
  • ¿Cómo están distribuidas las impresoras y otros periféricos de uso común?

Esta información puede resultar relevante si la empresa posee gran cantidad de equipos y están repartidos en diferentes localizaciones, a la hora de planificar las tareas de migración.
Pulse para ampliar
Ejemplo de diagrama de estructura

En un diagrama de estructura se muestra la distribución de los equipos en la empresa, mediante iconos fácilmente identificables. En cierto sentido es parecido a un plano arquitectónico, aunque en este tipo de planos no es necesario que las medidas sean exactas, solo con representar esquemáticamente la distribución física de los equipos en la empresa es suficiente.

Para realizar estos diagramas se puede utilizar una herramienta del estilo de Dia o TCM.

Diagrama de red

Un diagrama de red representa los nodos y las conexiones entre nodos en una red de ordenadores o, más generalmente, en cualquier red de telecomunicaciones. Iconos fácilmente identificables se utilizan para representar aplicaciones de red usuales, como por ejemplo un enrutador, y el estilo de líneas entre los nodos indican el tipo de conexión. Las nubes se utilizan para representar redes externas a la red que se está dibujando con el objetivo de representar las conexiones entre dispositivos internos y externos, sin indicar los detalles de la red exterior. Por ejemplo, en la hipotética red de área local (LAN) que hay más abajo, hay 3 ordenadores personales y un servidor conectado a un switch, al servidor también se conecta una impresora y una pasarela router, la cual está conectada a través de un enlace WAN a Internet.

Diagrama Redes
Ejemplo de diagrama de red

Dependiendo de si el diagrama está previsto para un uso formal o informal, ciertos detalles pueden estar ausentes y ser determinados por el contexto. Por ejemplo, el diagrama de ejemplo no indica el tipo de conexión física entre los PCs y el switch, pero dado que se trata de una LAN moderna, se puede asumir que se utilizan el estándar ethernet.
Pulse para ampliar
Diagrama de red de una organización conectada a Internet

A diferentes escalas, los diagramas pueden representar varios niveles de granularidad de red. A nivel de LAN, los nodos individuales pueden representar dispositivos físicos individuales, como hubs o servidores de ficheros, mientras que a nivel de WAN, los nodos individuales pueden representar ciudades enteras.

A partir de un cierto tamaño las redes se convierten en algo difícil de visualizar sin ayudas gráficas. Cuanto más grande es la red más difícil es entenderla como un todo. Los diagramas de red ayudan entender mejor las redes de conexión partiéndolas en trozos más manejables. Una red grande puede ser resumida por un punto de vista muy amplio, por ejemplo mostrando solo las grandes oficinas con los backbones principales entre ellas. Después cada oficina puede ser expandida en otro diagrama que revele mas detalles sobre la red. Uno de los aspectos negativos de los diagramas de red es que requieren una inversión de tiempo en su creación y una vez creados requieren también esfuerzo para mantenerlos actualizados. Pero son una herramienta de mucho valor en situaciones como las de una migración a software libre.

Los diagramas de red pueden expresar más en pocos minutos que hablar sobre la red durante días enteros. Existe software que facilita la tarea de crear diagramas de red como por ejemplo Dia. Se puede encontrar ejemplos de diagramas de red realizados por diferentes personas en http://www.ratemynetworkdiagram.com

Listado de formato de datos

Para la mayor parte de aplicaciones cliente-servidor, el único requisito es la disponibilidad de un reemplazo funcional de la parte cliente que se ejecute nativamente en GNU/Linux. Un ejemplo puede ser una aplicación que utiliza una interfaz Web para acceder a datos almacenados en el servidor. Siempre que la interfaz Web pueda ser ejecutada en un Navegador Web para GNU/Linux, entonces la migración de la parte del cliente se convierte en algo trivial.

Para algunas aplicaciones (mayoritariamente aplicaciones locales y nativas), los datos pueden estar almacenados en formatos propietarios que requerirán un proceso de conversión. Las aplicaciones en esta categoría pueden incluir sistemas de correo electrónico (como por ejemplo Lotus Notes) o suites de productividad (Como Lotus Smartsuite o Microsoft Office). Sin entrar en aspectos técnicos durante la toma de requisitos se debe explorar el uso actual de dichas aplicaciones.

Como ejemplo, algunas de las cuestiones a tratar en este punto son:

  • ¿Se utiliza Microsoft Office? De ser así, ¿Qué componentes y con qué frecuencia?
  • ¿Se utilizan macros en Microsoft Office? Si es así, ¿Qué tipo de macros, para qué componentes y con qué frecuencia?
  • ¿Se utiliza Microsoft Outlook? ¿Qué componentes y con qué frecuencia?
  • ¿Se utiliza Microsoft Project? ¿Qué componentes y con qué frecuencia?
  • ¿Se utiliza algún lenguaje de programación (como Visual Basic) para automatizar tareas en o entre aplicaciones?
  • ¿Se utiliza Lotus Smartsuite? ¿Qué componentes y con qué frecuencia?
  • ¿Se utiliza Lotus Notes? ¿Qué componentes y con qué frecuencia?
  • ¿Se comparten datos con organizaciones externas? ¿En qué formatos y con qué frecuencia?

Algunas respuestas a las preguntas anteriores requerirán una revisión en profundidad de la infraestructura subyacente. Por ejemplo, el uso de Microsoft Outlook en el cliente frecuentemente nos lleva a que se utilice Microsoft Exchange en el servidor, mientras que Lotus Notes en el cliente usualmente indica Lotus Domino en el servidor. Para escenarios como estos, el software instalado en los servidores se deben tener en cuenta cuando se diseña una nueva pila de clientes y la migración de las cuentas de los usuarios ha de ser planificada. En caso de que no exista una alternativa libre (o cliente para GNU/Linux) para la comunicación con el servidor, puede ser necesario tener en cuenta la migración del servidor a una solución compatible con GNU/Linux antes de que la migración de los clientes a GNU/Linux pueda comenzar.

Aplicaciones a utilizar

Después de una migración, los usuarios en la mayoría de los casos tendrán que adaptarse a aplicaciones diferentes pero funcionalmente equivalentes a las actuales. Para poder "puentear" este salto, el cual puede llevar a una pérdida de productividad, es de utilidad desarrollar una estrategia mediante la cual los usuarios se familiaricen con las nuevas aplicaciones.

Algunas aplicaciones que se ejecutan de modo nativo en GNU/Linux también están disponibles nativamente para Windows. Estas aplicaciones proporcionan la oportunidad de minimizar los efectos de la transición y los requisitos de reentrenamiento de los usuarios provocados por una migración de Sistema Operativo. De esta manera es posible migrar aplicaciones que serán soportadas en GNU/Linux antes incluso de la migración del propio sistema operativo.

Es importante ir siempre de lo fácil a lo difícil. Intentar en la medida de lo posible realizar una migración lo más escalonada posible, es conveniente acostumbrarse al uso de las nuevas aplicaciones antes de hacer efectiva la migración, para evitar pérdidas de productividad.

El beneficio de tales cambios antes de la migración es que de esta manera se le permite a los usuarios acostumbrarse a las nuevas aplicaciones antes de que se lleve a cabo la migración del Sistema Operativo. Una vez que se instale el nuevo Sistema Operativo, los usuarios no experimentarán ningún cambio en absoluto en lo referente a las aplicaciones que utilizan.

La siguiente tabla proporciona algunos ejemplos de aplicaciones que pueden ser utilizadas como "puente" entre Microsoft Windows y GNU/Linux. Los equivalentes basados en GNU/Linux que se muestran en la segunda columna son ejemplos de aplicaciones que tienen versiones nativas tanto para Windows como para GNU/Linux.

Aplicación en Windows Aplicación Puente
Microsoft Internet Explorer Mozilla Firefox
Microsoft Outlook, Outlook Express Mozilla Thunderbird, Evolution
Microsoft Word OpenOffice.org Writer
Microsoft Excel OpenOffice.org Spreadsheet
Microsoft PowerPoint OpenOffice.org Impress
Adobe Photoshop The GIMP
Cliente de Mensajería (MSN, Yahoo...) Pidgin (Antes conocido como GAIM)

Las funcionalidades proporcionadas por las aplicaciones tales como navegadores de sistemas de ficheros, archivadores, y visores fuerzan que el diseño de estas herramientas esté más íntimamente ligado al Sistema Operativo de la máquina. No se pueden considerar como "aplicaciones puente" en el sentido en el que se describen las aplicaciones anteriores. Uno de los motivos por los que se dice que GNU/Linux está alcanzando la equivalencia a Windows es la disponibilidad de múltiples aplicaciones de utilidad. En muchos casos, estas aplicaciones tienen conjuntos de funcionalidades más potentes que sus aplicaciones equivalentes en Windows hoy en día.

Desafortunadamente no es posible encontrar aplicaciones "puente" (el caso ideal) o aplicaciones funcionalmente equivalentes para satisfacer todos los escenarios. Por ejemplo, aplicaciones ERP o CRM son especialmente susceptibles de implementar un cliente ligero para los cuales no hay equivalente entre Windows y GNU/Linux. Las empresas fabricantes de software no están respondiendo a esto implementando un cliente ligero para cada plataforma, si no centrándose en los Navegadores Web como contenedor para extender el funcionamiento de sus aplicaciones a las plataformas alternativas de sus clientes (como GNU/Linux).

Si una solución basada en Navegador Web no es factible, la opción de "puentear" las aplicaciones al nuevo escritorio mediante la migración en primer lugar a un cliente web multiplataforma no puede ser utilizada. En este caso puede que se tenga que migrar la aplicación a una versión más reciente y que sí soporte clientes multiplataforma o puede que se tenga que considerar la opción de cambiar a otro proveedor de software que sí proporcione clientes multiplataforma.

Funcionalidades necesarias

En este punto ya se dispone de un listado de aplicaciones que se utilizan y seguramente exista una alternativa para GNU/Linux en la mayoría de los casos, bien proporcionada por el mismo fabricante o bien desarrollada por la comunidad de software libre, pero para facilitar la tarea de decidir que software se adapta mejor a las necesidades concretas de la empresa es recomendable elaborar un listado de funcionalidades requeridas para el nuevo software. Este listado de funcionalidades nos permitirá más adelante cotejar las diferentes alternativas y decidir cual es la más conveniente.

Para la elaboración de la lista de funcionalidades necesarias se puede utilizar una plantilla como la siguiente:

  • Título del software:
  • Categoría (p.e. Diseño):
  • Subcategoría (p.e. CAD/CAM/CAE):
  • Descripción de funcionalidades:

Aplicaciones que querría utilizar

Se conoce muy bien qué software se utiliza en la empresa, pero una migración puede ser más que un mero cambio de sistema operativo o de aplicaciones por otras equivalentes. Por eso se debe plantear también si existe alguna aplicación que se desearía utilizar pero que actualmente no se hace.

  • ¿Existen aplicaciones que resuelvan mejor la problemática de la empresa?
  • ¿Por qué no se utilizan? ¿Precio elevado de las licencias? ¿Desconocimiento en el uso?

Una migración no solo pretende cambiar unas aplicaciones propietarias por otras libres, también se busca mejorar, tanto en eficiencia como en calidad y prestaciones.

Aspectos de recursos humanos

Los proyectos de migración solo pueden tener sentido y solo pueden tener éxito a nivel de recursos humanos si los beneficios pueden ser claramente identificados y comunicados como algo esencial y necesario. El personal participante debe estar convencido de los beneficios del proyecto de migración para que apoyen e introduzcan el proyecto en cada departamento de la empresa. Al mismo tiempo, los limites del software libre deben ser comunicados claramente y las razones para introducir software libre en la empresa deben ser explicadas.

El objetivo es asegurar un alto grado de aceptación y de esta manera fomentar la motivación y la satisfacción entre el personal de la empresa. Se debe prevenir que personal insatisfecho (gente con falta de información, motivación o formación) comprometa el éxito de toda la migración y difunda los fallos, de haberlos. A largo plazo, esto puede afectar a la eficiencia y el rendimiento de toda la empresa. Mas allá del "ejercicio obligatorio" de asegurar información sobre el estado del proyecto, los responsables también deben realizar un "ejercicio voluntario" de monitorizar el nivel de satisfacción del personal durante el proceso de migración para poder tomar las medidas oportunas, en caso de ser necesario.

Aunque el desarrollo de los conceptos y de las medidas de implementación son inicialmente trabajo de la gente encargada de gestionar la migración, esta solo se podrá desarrollar, implementar y, por supuesto, mejorar de manera continuada junto con todo el personal. El soporte, consejos o experiencias de organizaciones externas pueden ser de gran ayuda en la fase inicial.

Factores humanos

Dado que la migración de los escritorios afecta directamente a los usuarios finales, considerar los aspectos de recursos humanos en la estrategia de gestión del cambio es muy importante. Es de esperar que un cambio radical en la interfaz de escritorio, a la que están acostumbrados los usuarios, causará distintos tipos de reacciones: desde aceptación entusiasta hasta rebelión extrema. Así que es muy importante mantener a los usuarios finales informados acerca de los nuevos desarrollos de una manera clara y concisa. Un plan de comunicaciones es clave. Generalmente no es una buena idea hacer algún cambio en los entornos de trabajo de los usuarios finales sin su conocimiento, así que un buen plan de comunicaciones contribuirá a reducir los aspectos negativos del cambio para los usuarios y hará que lo acepten mejor.

Un buen plan de comunicaciones combinado con la formación adecuada en las nuevas aplicaciones debería minimizar el numero de usuarios que se oponen y repudian el cambio, haciendo al mismo tiempo que los usuarios afronten el cambio con aceptación en lugar de insatisfacción.

Con respecto al personal de soporte de TI, estos mismos aspectos son incluso más importantes. La decisión estratégica de cambiar de sistema operativo y la manera en la que se gestionan los clientes pueden causarles la impresión de que se desaprueba el trabajo que han hecho. Al personal técnico puede darle la sensación de que sus conocimientos actuales están siendo devaluados. Probablemente no será fácil convencer a un administrador de sistemas Windows de que migrar a clientes GNU/Linux es una buena estrategia, a menos que que se les convenza de que la organización esta preparada para realizar una importante inversión en ampliar y actualizar sus conocimientos actuales.

  • Desarrollar un plan de comunicaciones
  • Seleccionar un grupo piloto que se ajuste de la mejor manera posible a la tarea de la migración

Para ayudar a que los usuarios acojan el cambio con mayor aceptación puede contemplarse la posibilidad de otorgar incentivos tales como una renovación del hardware. En algunas administraciones que decidieron migrar a software libre se incentivó al personal a participar en el grupo piloto cambiando sus monitores CRT (Tubo de Rayos Catódicos) por un monitor TFT (Monitor plano), fomentando así una actitud positiva desde el principio al cambio a Software Libre.

La importancia de la formación

En lo que a la formación se refiere, los administradores deben estar integrados en una etapa temprana del proyecto y la formación de los futuros usuarios se debe realizar lo antes posible. Un plan especifico de formación para cada grupo de usuarios debe ser desarrollado teniendo en cuenta tanto sus habilidades actuales, experiencia y cualificación así como los componentes específicos del trabajo que van a desarrollar.

Se debe tener especial atención con la formación en el lugar de trabajo a los encargados de ofrecer soporte a los usuarios durante la migración a software libre.

Además las experiencias de migraciones piloto u otros proyectos de migración deben ser tenidas en cuenta para hacer uso de las lecciones aprendidas.

La formación se vuelve aún mas importante si actualmente no se poseen conocimientos sobre software libre y una vez finalizada la migración no se va a tener soporte.

Durante el curso de la migración, la formación a los usuarios será necesaria en muchos casos. Dado que los cursos o clases son normalmente de coste elevado debido a tener que pagar a un profesor, y las horas de trabajo que pierden los empleados, se pueden plantear maneras de reducir un poco estos costes.

1. Las aplicaciones puente pueden separar la formación de la migración

Refiriéndose a las aplicaciones puente mencionadas anteriormente, la estrategia de reemplazar las aplicaciones actuales con equivalentes de software libre que estén disponibles tanto en Windows como en GNU/Linux puede reducir los costes en formación.

2. Aprender un nuevo "look and feel"

Otra estrategia para ahorrar costes es intentar mantener la apariencia de las aplicaciones actuales y del escritorio. Es posible personalizar ciertos aspectos de los escritorios GNOME y KDE (GNOME y KDE son entornos de ventanas de los escritorios GNU/Linux) para emular la apariencia del escritorio de Windows y de las aplicaciones basadas en Windows. Hay multitud de temas de escritorio disponibles para ser descargados y modificados libremente.

Se pueden encontrar ejemplos para GNOME en http://www.gnome-look.org y para KDE en http://www.kde-look.org

3. Acciones cotidianas

Emular las acciones es también una buena práctica. Un buen ejemplo es configurar un "doble clic" en lugar de un solo "clic" como evento para abrir iconos del escritorio.

4. Sistema de ficheros: todo ha cambiado de sitio.

Los usuarios de Windows están acostumbrados al sistema de ficheros jerárquico basado en los puntos de montaje de sistemas de ficheros como C:o D:. El sistema de ficheros jerárquico de GNU/Linux difiere de esta convención, viéndose un único sistema de ficheros, sobre el que hay puntos de montaje de unidades físicas u otros sistemas de ficheros, como puede ser /mnt/floppy, /mnt/cdrom o /home, por ejemplo. Los usuarios que se enfrenten a una migración pueden encontrar mucha confusión a la hora de entender la nueva jerarquía del sistema de ficheros de GNU/Linux. Para suavizar esta transición, un método recomendado es migrar el contenido completo de los archivos existentes en la carpeta "Mis Documentos" de los usuarios a carpetas de nombre similar en el directorio por defecto del usuario en GNU/Linux. Dentro de /home/nombre-de-usuario/Mis Documentos el contenido y estructura de archivos y directorios aparecerán exactamente igual a como lo hacían en la carpeta original de Windows.

5. Tomar contacto con GNU/Linux antes de la migración

Actualmente la mayor parte de distribuciones de GNU/Linux proporcionan "Live CD" o CD's que cargan una distribución de GNU/Linux al encender el ordenador. Uno de los pioneros en crear estas distribuciones "Live CD" fue Knoppix.

KNOPPIX es un CD auto-ejecutable con una colección de software GNU/Linux, detección de hardware automática, y soporte para la mayor parte de tarjetas gráficas, tarjetas de sonido, SCSI, dispositivos USB y otros periféricos. KNOPPIX puede ser utilizado como una demostración de GNU/Linux, CD educacional, sistema de rescate, o adaptado y usado como una plataforma para demostraciones de productos software comerciales. No es necesario instalar nada en el disco duro. Gracias a la descompresión "al vuelo" el CD puede incorporar hasta 2 GiB de software ejecutable instalado en él. Véase http://www.knoppix.com

Un "Live CD" se puede utilizar para proporcionar al usuario la oportunidad de ejecutar un sistema GNU/Linux en su escritorio. Se puede usar para testear y evaluar la interfaz de usuario, aplicaciones, y otras facetas del cliente GNU/Linux, antes de hacer efectiva la migración. Y todo esto se puede llevar a cabo sin dañar la instalación del sistema operativo actual de la máquina. Otro beneficio de utilizar un "Live CD" como parte del plan de migración es la detección de problemas con el hardware o dispositivos. Si se es capaz de personalizar los módulos de los "driver" cargados por un "Live CD" entonces se debe ser capaz también de validar la correcta detección de hardware y soporte de dispositivos en las máquinas sujetas a la migración antes de la migración real.

La formación a los usuarios es un aspecto clave en el éxito de una migración. El mayor esfuerzo, tanto económico como temporal, se debe realizar en este área.

Aspectos Legales

En este punto se van a observar los diferentes puntos a tener en cuenta sobre aspectos legales en una migración a Software Libre.

Contratos actuales (mantenimiento y otros)

Antes de la migración se debe pensar en los contratos (de mantenimiento u otros) que pueda tener la empresa. Si la empresa utiliza un software hecho a medida por algún proveedor de software se puede intentar negociar con el proveedor de software el que libere la aplicación bajo una licencia libre como la GPL, ya que al fin y al cabo el software ha sido desarrollado para la empresa en concreto. Pero los proveedores de software no suelen colaborar en este aspecto y no suelen estar por la labor de liberar sus aplicaciones propietarias.

Otro aspecto a tener en cuenta es la existencia de contratos de mantenimiento de software propietario, si ese software es elegido para ser migrado dichos contratos deben ser extinguidos, lo cual puede acarrear alguna penalización que debe ser estudiada a fondo por la empresa.

Si no se dispone de personal cualificado en la empresa para modificar y adaptar las aplicaciones, en caso de ser necesario, se puede optar por la realización de un contrato con algún proveedor de software libre que se encargue de la modificación y adaptación de las aplicaciones a las necesidades de la empresa. Normalmente las aplicaciones distribuidas bajo una licencia libre suelen ir sin "garantías", así que si se desea soporte técnico o mantenimiento se debe contratar. Ahí es donde está el negocio en el software libre.

Licencias de software

Al analizar las licencias de uso, tanto las de software propietario como las de software libre, merece especial consideración que se estudie sus elementos subjetivos o personales: qué sujetos son las partes de la licencia de software. Por un lado, se encuentra el proveedor-licenciante, quien concede un derecho de uso sobre el software al usuario-licenciatario (en una licencia de software libre, concede además el derecho a modificar y redistribuir el software, con o sin modificaciones). Por otro lado, tenemos a ese usuario-licenciatario, quien a su vez adquiere tal derecho de uso, abonando o no un precio por ello.

El proveedor-licenciante ha de encontrarse facultado para conceder licencias de software, bien por ser su autor, el titular de sus derechos de explotación o, como mínimo, de un derecho a su distribución. Por su parte, con relación al usuario-licenciatario, es importante saber si se trata de un empresario o de un consumidor, pues de ello dependerá el régimen legal aplicable a la licencia. El proveedor-licenciante es quien concede la licencia al usuario para utilizar el software, proporcionándole una copia del software licenciado.

Pueden conceder licencias de uso el autor o autores originales del software, la persona física o jurídica que sea titular de los derechos de explotación, o aquella que como mínimo tenga el derecho a distribuir el software objeto de la licencia en cuestión. Esta diversidad de sujetos con capacidad para conceder licencias de software es lo que explica que denominemos a esta parte proveedor del software o simplemente licenciante. Se trata de expresiones más genéricas que permiten abarcar a todos los que pueden otorgar licencias sobre el software, a diferencia de otras comúnmente empleadas como autor, titular o propietario del software.

El usuario-licenciatario es la otra parte del contrato de licencia de software. Es la persona (física o jurídica) que adquiere el derecho a usar el software por medio de la licencia, según los términos y condiciones que se establecen en la misma (casi siempre impuestos por el proveedor del software). El usuario-licenciatario tiene como principales obligaciones pagar el precio de la licencia (cuando es de pago) y respetar las limitaciones de uso que le impone la licencia de software, un software cuya propiedad no le pertenece.

En el caso de que el usuario sea licenciatario de un software propietario, en principio serán pocos sus derechos como usuario (básicamente ejecutar el programa, aprovechar sus aplicaciones y poder hacer una copia de seguridad del mismo), mientras que las limitaciones son muchas. Por el contrario, si es licenciatario de un software libre, las libertades del usuario-licenciatario son mucho más amplias, y por ende, las limitaciones son menores: puede usar el software libremente, modificarlo y redistribuirlo con o sin modificaciones. Si el usuario está facultado para modificar y modifica el software, puede pasar a ser el autor de una obra derivada, según el artículo 11 de la Ley de la Propiedad Intelectual (es decir, de la traducción o adaptación del software). Por su parte, si el usuario está facultado para redistribuir y redistribuye el software, se convertirá también en proveedor de software.

Para ser usuario-licenciatario no se requiere ningún requisito especial en principio, aparte de las exigencias sobre capacidad legal genéricas: que el usuario persona física sea mayor de edad o, si se trata de una persona jurídica (empresa, administración, asociación sin ánimo de lucro, etc.), que ésta se halle válidamente constituida. Es importante tener en cuenta si se emplean o no condiciones generales en las licencias de software (en casi todos los casos se emplean) y si el usuario-licenciatario es un consumidor o un empresario, porque varía el régimen legal al que está sujeto el contrato de licencia.

A veces, en el propio texto de la licencia de uso se contemplan derechos y limitaciones distintas según si el usuario es un consumidor que va a destinar el software a un uso particular o un empresario/profesional que va a destinar el software a su actividad. Se trata de las llamadas licencias duales. Si el usuario es un consumidor, se entiende que se halla en una posición especialmente débil, por lo que debe tener una protección legal frente a posibles abusos del proveedor del software, al igual que sucede en muchos otros contratos que celebran los consumidores. Se debe tener en cuenta que, aunque las normas protectoras del consumidor no se apliquen cuando el usuario sea un empresario o profesional, ello no significa que el proveedor del software puede imponer sin más a este usuario cláusulas especialmente injustas o abusivas. Ocurre, no obstante, que el usuario empresario no tiene la protección legal que supone que ciertas cláusulas abusivas se consideran automáticamente nulas por disponerlo así la ley.

Si el usuario (empresario o profesional) cree que una cláusula de la licencia es abusiva y se niega a respetarla, deberá demandar el contrato de licencia ante los tribunales. La cláusula podrá ser anulada por estimar que es contraria a la regla general de buena fe que ha de regir en el cumplimiento de los contratos. No obstante, ello dependerá del examen de las circunstancias de cada caso en concreto y será el juez quien decida si se trata o no de una cláusula contraria a la buena fe entre las partes.

Aun siendo las partes de la licencia las mismas (proveedor-licenciante y usuario-licenciatario) tanto para software propietario, como para software libre, las diferencias tan importantes sobre los derechos que otorgan unas y otras al usuario hace que sea conveniente tener en cuenta las siguientes consideraciones:

  • Las licencias de software libre son el medio o instrumento legal, no para que el proveedor del software pueda rentabilizar al máximo sus derechos exclusivos de explotación, sino para garantizar a los usuarios las libertades de uso, modificación y redistribución. En el supuesto de que modifique el software, el usuario será el autor de un programa derivado. Por tanto, el usuario-licenciatario también puede convertirse a su vez en proveedor-licenciante de otros usuarios; bien licenciando el mismo software que se le ha licenciado a él, bien por licenciar un software derivado del original. Estos otros usuarios pueden, a su vez, modificar y distribuir el programa de nuevo, y así sucesivamente.
  • Debemos tener en cuenta que las legislaciones sobre propiedad intelectual, incluida la Ley de la Propiedad Intelectual en España, conceden al proveedor de software unos derechos exclusivos en virtud de los cuales ninguna otra persona puede hacer nada con el software si no cuenta con la expresa autorización (licencia) del proveedor. Por ello, el usuario de un software libre puede beneficiarse de las libertades de uso, modificación y redistribución sólo si el proveedor del software le ha concedido realmente tales libertades por medio de una licencia de uso.
  • Además, ni en España ni en otros países es necesario inscribir el software en el Registro de la Propiedad Intelectual para que su autor sea reconocido como tal. En principio, para ello basta con que el autor pueda probar ser el creador de un software original (o derivado, con la autorización del autor del software original). Esto propicia que existan riesgos de que alguien intente apropiarse de un software libre, que reclame la exclusividad en su explotación y se atreva a sostener que los usuarios utilizan ese software sin tener derecho.
  • Si alguien intenta apropiarse ilegítimamente del software o pretende restringir las libertades que tienen los usuarios sobre el mismo, el verdadero autor del software es quien podrá reaccionar y ejercer las medidas legales oportunas para impedir esta apropiación indebida. A diferencia del software propietario, el autor no reaccionará tanto para proteger sus derechos exclusivos, sino más bien para que los usuarios puedan continuar disfrutando de las libertades (de uso, modificación y distribución) sobre el software.
  • Por otra parte, quien pretenda divulgar su software como libre debe garantizar que ese software es verdaderamente libre y que no infringe los derechos de otro software (sea libre o propietario).
  • La concesión de una licencia de software libre implica que su titular comparte con los usuarios los principales derechos de explotación sobre el mismo. Pero en España (y en el resto de la Europa "Continental"), el hecho de que ceda a una multitud de usuarios los derechos de modificar o distribuir el software no significa que el software libre pase al dominio público. El software libre no es un software sin propietario, sino que el autor conserva su condición de autor del software y, en particular, los derechos morales sobre el software.

Licencias de Software Libre

Una licencia es aquella autorización formal con carácter contractual que un autor de un software da a un interesado en ejercer "actos de explotación legales". Pueden existir tantas licencias como acuerdos concretos se den entre el autor y el licenciatario. Desde el punto de vista del software libre, existen distintas variantes del concepto o grupos de licencias:

  • Las libertades definidas anteriormente están protegidas por licencias de software libre, de las cuales una de las más utilizadas es la Licencia Pública General GNU (GPL). El autor conserva los derechos de autor (copyright), y permite la redistribución y modificación bajo términos diseñados para asegurarse de que todas las versiones modificadas del software permanecen bajo los términos más restrictivos de la propia GNU GPL. Esto hace que no sea imposible crear un producto con partes no licenciadas GPL: el conjunto tiene que ser GPL.
  • Licencias estilo BSD, llamadas así porque se utilizan en gran cantidad de software distribuido junto a los sistemas operativos BSD. El autor, bajo tales licencias, mantiene la protección de copyright únicamente para la renuncia de garantía y para requerir la adecuada atribución de la autoría en trabajos derivados, pero permite la libre redistribución y modificación, incluso si dichos trabajos tienen propietario.
    Son muy permisivas, tanto que son fácilmente absorbidas al ser mezcladas con la licencia GNU GPL con quienes son compatibles.Puede argumentarse que esta licencia asegura "verdadero" software libre, en el sentido que el usuario tiene libertad ilimitada con respecto al software, y que puede decidir incluso redistribuirlo como no libre. Otras opiniones están orientadas a destacar que este tipo de licencia no contribuye al desarrollo de más software libre.
  • Licencias estilo MPL y derivadas, Esta licencia es de Software Libre y tiene un gran valor porque fue el instrumento que empleó Netscape Communications Corp. para liberar su Netscape Communicator 4.0 y empezar ese proyecto tan importante para el mundo del Software Libre: Mozilla. Se utilizan en gran cantidad de productos de software libre de uso cotidiano en todo tipo de sistemas operativos. La MPL es Software Libre y promueve eficazmente la colaboración evitando el efecto "viral" de la GPL (si usas código licenciado GPL, tu desarrollo final tiene que estar licenciado GPL). Desde un punto de vista del desarrollador la GPL presenta un inconveniente en este punto, y lamentablemente mucha gente se cierra en banda ante el uso de dicho código.
    No obstante la MPL no es tan excesivamente permisiva como las licencias tipo BSD. Estas licencias son denominadas de copyleft débil. La NPL (luego la MPL) fue la primera licencia nueva después de muchos años, que se encargaba de algunos puntos que no fueron tenidos en cuenta por las licencias BSD y GNU. En el espectro de las licencias de software libre se la puede considerar adyacente a la licencia estilo BSD, pero perfeccionada. Hay que hacer constar que el titular de los derechos de autor (copyright) de un software bajo licencia copyleft puede también realizar una versión modificada bajo su copyright original, y venderla bajo cualquier licencia que desee, además de distribuir la versión original como software libre. Esta técnica ha sido usada como un modelo de negocio por una serie de empresas que realizan software libre (por ejemplo MySQL); esta práctica no restringe ninguno de los derechos otorgados a los usuarios de la versión copyleft. También podría retirar todas las licencias de software libre anteriormente otorgadas, pero esto obligaría a una indemnización a los titulares de las licencias en uso.
    En España, toda obra derivada está tan protegida como una original, siempre que la obra derivada parta de una autorización contractual con el autor. En el caso genérico de que el autor retire las licencias "copyleft", no afectaría de ningún modo a los productos derivados anteriores a esa retirada, ya que no tiene efecto retroactivo. En términos legales, el autor no ha derecho a retirar el permiso de una licencia en vigencia. Si así sucediera, el conflicto entre las partes se resolvería en un pleito convencional.

Existen otras muchas licencias, como por ejemplo la licencia de Apache o la licencia MIT/X11.

Puede encontrar más licencias de software libre en la web del OpenSource Inititiative, un organismo sin ánimo de lucro que se encarga de revisar y aprobar licencias compatibles con la filosofía del software libre.

Comparación con el software Open Source

Aunque en la práctica el software Open Source (de código abierto) y el software libre comparten las mismas licencias, la FSF opina que el movimiento Open Source es filosóficamente diferente del movimiento del software libre. Apareció en 1998 con un grupo de personas, entre los que cabe destacar a Eric S. Raymond y Bruce Perens, que formaron la Open Source Initiative (OSI). Ellos buscaban:

  • Darle mayor relevancia a los beneficios prácticos del compartir el código fuente.
  • Interesar a las principales casas de software y otras empresas de la industria de la alta tecnología en el concepto.

Estos defensores ven que el término "open source" evita la ambigüedad del término inglés free en free software. El término "open source" fue acuñado por Christine Peterson del think tank Foresight Institute, y se registró para actuar como marca registrada para los productos de software libre.

Mucha gente reconoce el beneficio cualitativo del proceso de desarrollo de software cuando los desarrolladores pueden usar, modificar y redistribuir el código fuente de un programa. El movimiento del software libre hace especial énfasis en los aspectos morales o éticos del software, viendo la excelencia técnica como un producto secundario deseable de su estándar ético. El movimiento Open Source ve la excelencia técnica como el objetivo prioritario, siendo la compartición del código fuente un medio para dicho fin. Por dicho motivo, la FSF se distancia tanto del movimiento Open Source como del término "Open Source".

Puesto que la OSI sólo aprueba las licencias que se ajustan a la OSD (Open Source Definition), la mayoría de la gente lo interpreta como un esquema de distribución, e intercambia libremente "open source" con "software libre". Aun cuando existen importantes diferencias filosóficas entre ambos términos, especialmente en términos de las motivaciones para el desarrollo y el uso de tal software, raramente suelen tener impacto en el proceso de colaboración.

Aunque el término "open source" elimina la ambigüedad de libertad frente a precio (en el caso del Inglés), introduce una nueva: entre los programas que se ajustan a la Open Source Definition, que dan a los usuarios la libertad de mejorarlos, y los programas que simplemente tienen el código fuente disponible, posiblemente con fuertes restricciones sobre el uso de dicho código fuente. Mucha gente cree que cualquier software que tenga el código fuente disponible es open source, puesto que lo pueden manipular (un ejemplo de este tipo de software sería el popular paquete de software gratuito Graphviz, inicialmente no libre pero que incluía el código fuente, aunque luego AT&T le cambió la licencia). Sin embargo, mucho de este software no da a sus usuarios la libertad de distribuir sus modificaciones, restringe el uso comercial, o en general restringe los derechos de los usuarios.

Recursos temporales

Como se puede observar, en la mayoría de los casos una migración no es una tarea sencilla o rápida, requiere mucha planificación y tener en cuenta muchos factores a la hora de tomar decisiones. Otro factor mas a tener en cuenta es el factor "tiempo".

En general las prisas no son buenas, y más en una migración a nuevas aplicaciones basadas en software libre. Todo requiere su tiempo. Se debe ir paso a paso para garantizar el éxito.

Algunas cosas a tener en consideración son:

  • ¿De cuánto tiempo se dispone para llevar a cabo la migración?
  • Conociendo el nivel de los usuarios ¿Cuánto tiempo se va a dedicar a la formación?
  • ¿Existen procesos (industriales o de cualquier otro tipo) involucrados en la migración que no se puedan detener?
  • ¿Existen procesos o situaciones que nos acoten el tiempo disponible para llevar a cabo la migración? Por ejemplo el envío semanal de una copia de seguridad de datos a una oficina central o similares.

Recursos económicos

Es importante determinar el esfuerzo económico que puede suponer el realizar una migración y contrastarlo con el coste que supondría mantener un sistema compuesto enteramente por software propietario.

No se debe basar la decisión de realizar una migración únicamente en el factor económico.

Aunque por lo general el software libre es más rentable a medio/largo plazo que el software privativo se deben evaluar más criterios para decidir si se lleva a cabo una migración.

Por ello otro de los factores importantes a tener en cuenta en una migración es el factor económico. En concreto el aspecto que mejor refleja el coste de una migración es el que se conoce como TCO: Total Cost of Ownership. El TCO define el coste total de propiedad de una tecnología concreta sobre su periodo de vida útil.

Los componentes que forman el TCO son todos aquellos costes que se producen como consecuencia de la introducción de una nueva tecnología. A grandes rasgos se puede hablar de dos tipos de costes, los directos e indirectos. Los costes directos, normalmente, son aquellos costes conocidos y que implican una contraprestación económica (por ejemplo la compra de un nuevo PC para la empresa). Por otra parte, los costes indirectos son los que no tienen una contraprestación económica conocida y no son tan fácilmente identificables como los costes directos (por ejemplo la producción "perdida" a causa de las horas invertidas por el usuario en la instalación y configuración del nuevo PC adquirido por la empresa).

De esta manera vamos a intentar hacer una clasificación general de los costes asociados a una migración:

  • Costes Directos
  • Licencias y soporte de software
  • Costes hardware
  • Costes de soporte
  • Costes de formación
  • Costes de personal
  • Costes Indirectos
  • Costes de soporte
  • Downtime

Costes directos: Licencias y soporte de software

El software propietario que se utiliza actualmente tiene asociado un coste por licencia (por puesto de trabajo, por acceso, etc...) que, en función del volumen de la empresa, puede suponer un porcentaje elevado de los costes totales de un sistema de información. Las distribuciones de GNU/Linux y la mayoría de aplicaciones incluidas en dichas distribuciones son de Código Abierto y se licencian bajo la GPL. Esto significa que es distribuido libremente. Así pues no suele haber costes de licencia, como tal, asociados al software distribuido bajo esta licencia.

Aun así, las distribuciones empaquetadas por empresas distribuidoras no tienen porqué ser gratuitas. Normalmente hay un modelo de precios "por puesto" establecido por las empresas distribuidoras de software libre. Pero esta tasa se paga en concepto de soporte técnico y no en concepto de licencia de uso. Usualmente esta tasa otorga el derecho a soporte técnico durante un año, aunque es posible contratar niveles de soporte extra con las empresas distribuidoras de software libre. Dada la naturaleza de código abierto del sistema operativo GNU/Linux y su software relacionado, también es posible utilizarlo completamente libre de costes de licencia o de soporte. En este caso el soporte depende completamente de la comunidad software libre y del personal bien cualificado del que se disponga en la plantilla de la empresa.

Costes de Hardware

La mayor parte de distribuciones de GNU/Linux y el software libre en general son capaces de ser ejecutados satisfactoriamente sobre hardware viejo. Dependiendo de las necesidades y exigencias de las aplicaciones a utilizar es incluso posible reutilizar hardware que haya sido retirado porque no era lo suficientemente potente como para satisfacer las necesidades de rendimiento requeridas por las ultimas versiones de aplicaciones no libres.

De todas maneras, las últimas versiones de las distribuciones de software libre tienen requisitos mínimos de memoria que se asemejan a los requisitos de memoria de las aplicaciones privativas. Aún así, siendo solo requisitos de memoria, se puede seguir utilizando hardware retirado para ejecutar estas distribuciones. Y la tendencia parece que continuará siendo esta debido al uso intensivo que hacen las aplicaciones privativas de formatos de datos más complejos de lo necesario (conocidos también como Rich Data Formats).

Dependiendo del tipo de migración que se vaya a llevar a cabo y del estado del hardware del que se dispone actualmente, se debe plantear la adquisición de nuevo hardware, el mantenimiento del hardware actual o la recuperación de hardware retirado.

Costes de soporte

En una empresa mediana/grande, mantener cualquier equipo de escritorio operativo, libre de fallos y de agujeros de seguridad es, normalmente, uno de los costes totales más altos. Esta situación no es diferente en una estrategia basada en GNU/Linux y software libre. Pero, el hecho de utilizar sistemas operativos de tipo UNIX introduce muchas estrategias de ahorro de costes a tener en cuenta. Por ejemplo, al poder acceder remotamente a los equipos y gestionarlos utilizando protocolos como telnet, ssh o similares, es posible instalar scripts en las estaciones de trabajo que pueden ser ejecutados remotamente de una manera sencilla.

El uso de scripts remotos posibilita la monitorización de todas las estaciones de trabajo para prevenir fallos y ejecutar tareas en todos los equipos de manera centralizada. Por ejemplo, es posible aplicar la corrección de un error en todos los equipos a la vez sin que la producción del usuario final se vea afectada o interrumpida por el cambio. Los costes de soporte incluyen la instalación y configuración, mantenimiento y solución de problemas derivados de la migración.

Si la empresa no dispone de un departamento de TI se deben contratar los servicios profesionales de consultoras u otras empresas de servicios de software libre que puedan implantar la base tecnológica necesaria.

La ventaja que ofrece el software libre en el aspecto del soporte es la existencia de multitud de comunidades de usuarios que ofrecen soporte sobre la aplicación software libre o sistema operativo en cuestión mediante foros, documentación o charlas completamente libres de coste. Los fabricantes de software propietario son conscientes de la importancia de este canal de soporte que ha establecido el software libre. Por eso Microsoft creó sus propias comunidades de usuarios para poder ofrecer soporte de manera eficiente. También es cierto que, aunque el coste de soporte sea cual sea el tipo de software (libre o propietario) es gran parte del TCO, las soluciones basadas en software libre configuradas apropiadamente requieren un coste mínimo de mantenimiento.

Costes de formación

Este es otro apartado fundamental en el que se debe invertir, y el éxito de la migración depende en gran medida del esfuerzo que se realice en cuanto a la formación de los usuarios. Se debe tener en cuenta que la filosofía del software libre, así como las metodologías de uso da las aplicaciones, son bastante diferentes a las que se está acostumbrado en Software Propietario, y esto puede generar confusión y rechazo en los usuarios si no se invierten los recursos necesarios para dar a conocer las nuevas aplicaciones. En este apartado se deben contemplar los costes asociados, si procede, de posibles cursos externos de formación para los usuarios, o por ejemplo el sueldo del profesorado contratado para impartir la formación internamente.

Costes de personal

En este apartado se deben reflejar todos los gastos de personal relacionados directamente a la migración, es decir, los salarios del personal de TI que lleve a cabo la migración. La actual penetración de GNU/Linux y el software libre en general está haciendo que el dominio de estos sistemas sea ya cada vez más extenso por parte de muchos administradores de sistemas. Actualmente, las empresas que necesiten un administrador de sistemas GNU/Linux no tendrán problemas en encontrar a personal cualificado. De igual manera se puede encontrar personal cualificado para administrar, programar o crear aplicaciones de software libre, tanto en el área de servidores como en entornos de escritorio.

Costes indirectos

Estos gastos son algo mas difíciles de predecir ya que cuando se habla de costes indirectos se suele hacer en el sentido de pérdidas de productividad en la empresa debidas a la migración.

Un buen estudio y plan de migración conducirá inexorablemente a una migración exitosa e implícitamente a una reducción sustancial en los costes indirectos.

Aunque como ya se ha comentado estos costes son difíciles de establecer a priori se van a comentar dos de los más importantes.

Costes de soporte

Los usuarios de las tecnologías en empresas normalmente se apoyan en los técnicos informáticos y en compañeros de trabajo para la resolución de problemas. Este hecho implica el conocimiento de la tecnología por parte de los usuarios de la empresa. Este concepto pretende abarcar el coste de las pérdidas de productividad derivadas bien del desconocimiento del uso de la tecnología, bien sea por una errónea utilización del sistema o por errores del propio sistema.

Costes de inoperatividad del sistema

En este apartado se suman los costes derivados de la pérdida productividad en la empresa debidas a inoperatividad del sistema. Existen muchas causas por las cuales el sistema puede quedar temporalmente inoperativo, entre ellas la propia migración. Es decir, dependiendo de la planificación que se haga se puede dar el caso de que la empresa no pueda producir normalmente durante el proceso de migración.

En el mundo del software y los sistemas operativos privativos se vive una situación que provoca muchísimas pérdidas a las empresas, los virus. Estos virus pueden provocar que el sistema quede inoperativo temporalmente, con las consiguientes pérdidas para la empresa. En el mundo del software libre y los sistemas operativos libres, como GNU/Linux, los virus tal como se entienden en los sistemas privativos no existen debido a las restricciones establecidas y las medidas de seguridad tomadas por naturaleza. Pero esto no significa que el software libre esté exento de errores o programas maliciosos que puedan aprovechar una vulnerabilidad del sistema para dejarlo inoperativo o causar daños.

 
SourcePYME cofinanciado: Generalitat Valenciana IMPIVA Fondo Social Europeo