Blog sobre la Migracion al Software Libre: agosto 2014

Este Blog esta enfocado en mostrar los beneficios del software libre como una gran herramienta para promover la soberanía tecnológica en la población en general.

En este contexto, se da los mínimos lineamientos a tener en cuenta en el proceso de migración hacia el software libre en cualquier ambiente de trabajo.

Para efectos de mejor entendimiento del porque se pone énfasis en este tema, se presenta el siguiente vídeo que muestra el nivel de compromiso que tiene el actual Estado Boliviano con el Software Libre, ádemas que se toca el tema en general.

Temas a tratar

Para intentar afrontar una migración al software libre se deben muy claros estos puntos:

1. Motivación

En una industria cada vez mas competitiva las empresas deben adaptarse y ajustarse a las variaciones para poder mantener su posición de competitividad. Durante años, en el mundo del software, se ha vivido bajo un modelo de negocio muy lucrativo para las empresas de desarrollo de software y muy poco ventajoso para el resto de usuarios de software, el modelo de software propietario.

2. Software Libre

El software libre, tal y como fue concebido en sus inicios, trata de la forma ética en la que se utiliza, difunde y modifica el software. Trata de establecer una serie de valores y, para ello, propone una serie de libertades que no se deben violar para mantener la libertad del software.

El software libre es, también, una manera de acumular experiencia y formas de resolver problemas de software, de manera que podamos reutilizarlo para poder desarrollar nuestras propias aplicaciones. De todas maneras, no se trata únicamente de que el software pueda ser utilizado y modificado por cualquiera, sino que, además, cualquiera pueda ser beneficiario de ese software en cuanto las modificaciones sean liberadas nuevamente en la comunidad donde se desarrolló.

En la Wikipedia podemos acceder a un mapa conceptual bastante completo donde comprobar, de un vistazo, cómo se interrelacionan las cuatro libertades básicas del software libre con el desarrollo, la mejora y la calidad de este software. La manera en que los usuarios y los desarrolladores intervienen en la toma de decisiones y cómo esta interacción se hace evidente en un software al que, posiblemente, haya empresas que nos le den soporte. Para consultar este mapa conceptual, podemos visitar:

http://upload.wikimedia.org/wikipedia/commons/d/d2/Mapa_conceptual_software_libre.png

2.1. Las cuatro libertades del software libre

Como hemos mencionado anteriormente, el software libre, como forma ética de entender el software, trata de reconocer siempre 4 libertades esenciales.

Libertad 0: Usar el programa, con cualquier propósito

Evidentemente, la primera libertad expresada dentro del movimiento del software libre tiene que ver con la capacidad de no restringir el uso del programa. Es importante remarcar lo de con cualquier propósito, ya que limitar el uso en cualquier de sus aspectos limita la libertad de ese software en cualquiera de las aplicaciones que vayamos a darle.

Libertad 1: Estudiar el funcionamiento del programa y adaptarlo a las necesidades

Para poder acumular la mejor calidad en el software desarrollado, es imprescindible contar con personas que comprender el código que da soporte a las características del software. Por tanto se debe permitir el acceso al código fuente. De esta manera, no sólo se puede estudiar el funcionamiento de cara a poder ayudar a la comunidad a desarrollar el software, sino que se puede adaptar el código a las necesidades de cada entidad que requiera modificarlo.

Un ejemplo típico es el núcleo Linux. Este núcleo ha sido adaptado a las distintas arquitecturas que soporta debido a que utiliza una licencia GPL (GNU Public License, que veremos en el Bloque II con más detalle). Gracias a la naturaleza libre del código en que está basado este núcleo de sistema operativo, muchas empresas han desarrollado versiones específicas para, por ejemplo, poder embeberlo dentro de microcontroladores en electrodomésticos. De hecho, es habitual encontrar este núcleo adaptado a diversos productos encaminados a dotar de servicios de acceso a redes, como los routers que muchas empresas de telecomunicaciones regalan al darnos de alta en su servicio ADSL.

Libertad 2: Distribuir el software, de manera que beneficie a la comunidad

No sería posible que los desarrollos derivados del software libre quedaran atrapados de manera que la comunidad que empezó un proyecto no pudiera acceder a los nuevos desarrollos hechos sobre él. De esta manera, es necesario proteger al software libre de manera que se permita la distribución del software. Conseguiremos así que el software pueda llegar a diferentes usuarios de la comunidad para que puedan utilizarlo.

Libertad 3: Mejorar el programa y publicar las mejoras

Finalmente, de nada nos serviría un software que nos permitiera redistribuirlo, comprobar cómo está hecho y modificarlo si no se nos permite mejorar la aplicación y, además, publicar las mejoras.

Es importante tener en cuenta que, bajo esta libertad, hay muchas empresas que se han beneficiado de esta libertad. Generalmente, alrededor de un producto de software libre encontramos una comunidad entusiasta dispuesta a corregir, mejorar y adaptar el código a las necesidades de cada uno, y muchas empresas utilizan esta posibilidad para permitir que los usuarios mejoren su software.

Un ejemplo de estas mejoras podemos verlas en las PDA Sharp Zaurus. Este microordenador de bolsillo, utiliza software libre para funcionar y el núcleo del sistema así como una parte importante de las aplicaciones que le acompañan vienen acompañados de su correspondiente código fuente. Al poco tiempo de aparecer las primeras unidades, la comunidad alrededor comenzó a colaborar con el proyecto de manera que se crearon firmwares alternativos que mejoraban el acceso a determinadas capacidades, o que añadían nuevas aplicaciones que inicialmente no tenía. De esta manera, el producto fue mejorado y muchos hackers de hace unos años miran a esa PDA como una de las primeras en promover el desarrollo de software junto a una plataforma de bolsillo de software abierto.

Cuando hablamos de software libre, tenemos que tener en cuenta estas cuatro libertades que hemos enumerado. Desafortunadamente, esto resulta ambiguo para las personas que hacen uso del software y no tenemos que confundir el software libre con software gratuito ni con software de dominio público.

Hay muchas oportunidades de negocio asociadas al software libre. La primera es vender el software. Que sea libre no implica que sea gratuito. Quizá la ambigüedad principal se deba principalmente al nombre como tal: software libre. Aunque esta ambigüedad no es tal cuando lo expresamos en castellano, tenemos que tener en cuenta que el uso del término inglés free software no distingue entre libertad y gratuidad, ya que la palabra free es ambigua en ese lenguaje.

Además, la mayor parte del software libre sí que se puede acceder de forma gratuita, aunque no todo el software gratuito sea libre, ni todo el software libre sea gratuito. Por tanto, hemos de evitar relacionar en la medida de lo posible la gratuidad del software con la libertad de este.

Por otra parte, el software libre no puede ser considerado de dominio público. Son conceptos diferentes. Generalmente se emplea el término dominio público cuando se considera que algo, dada la relevancia o el tiempo que pasó desde que se creo, pasa a formar parte de la cultura como bien a nivel global y, por tanto, todos podemos acceder a él.

2.2. Open Source

OpenSource es un término que surgió a finales de la década de los 90, y que evita la ambigüedad (o al menos lo intenta) del término free software. Como veremos a continuación, no siempre se consigue eliminar totalmente la ambigüedad, por lo que más adelante estudiaremos el término FOSS o FLOSS.

Cuando se creó el término OpenSource, se intentó darle un enfoque más empresarial, evitando el término free para que las empresas se sintieran cómodas utilizando el nuevo término. De hecho, el movimiento OpenSource intenta poner en la práctica (abandonando en parte las implicaciones éticas) aquello que hasta el momento se conocía como free software.

Aunque inicialmente el término también se utilizó para evitar la confusión provocada por la palabra inglesa free, se han tenido otros problemas con el concepto de código abierto. De hecho, hay software que se auto denomina de código abierto que realmente no lo es, ya que hacen una interpretación literal del concepto open source, pero no tienen en cuenta el decálogo que el movimiento open source sigue a rajatabla.

Este decálogo, que pasamos a ver a continuación, es una traducción práctica de las ideas y las implicaciones éticas detrás del software libre y, de hecho, son tratadas como normas a seguir para que un proyecto pueda ser considerado de código abierto.

Libre distribución

Evidentemente, para que un proyecto pueda ser considerado open source se debe permitir la libre distribución de ese software.

Código fuente accesible

Si el código está accesible, cualquiera puede estudiarlo y modificarlo libremente, de manera que pueda añadir mejoras.

Trabajos derivados

Además, permitiendo trabajos derivados conseguimos que el software pueda ser adaptado a las necesidades de cada persona.

Integridad del código fuente del autor

Protegiendo la integridad del código fuente, se consigue reconocer a los autores materiales de cada versión de código fuente, de manera que no se puedan apropiar de la propiedad intelectual de la realización de una parte determinada del software.

No discriminación de personas o grupos

Para conseguir que el software sea de libre distribución y acceso, se deben eliminar toda posible discriminación por cualquier motivo a cualquier grupo de persona. Es una libertad básica para permitir la libre distribución del software.

No discriminación de áreas de iniciativa

Además, no se debe restringir el software o partes de él a unos intereses particulares, de manera que otros grupos de personas no puedan acceder a él para poder modificarlo, distribuirlo o mejorarlo.

Distribución de la licencia

Evidentemente, la licencia debe permitir la distribución del software. Además todo el software debe estar acompañado de una licencia considerada open source por el OpenSource Institute, la organización encargada de validar y estudiar las distintas licencias para ver aquellas que mantienen las 4 libertades del software libre.

Licencia no específica

No hay una licencia específica que se deba utilizar para poder liberar el software open source, sino que se puede utilizar cualquier licencia validada por el OpenSource Institute o un conjunto de ellas, siempre que sean compatibles.

No restricción del software a otro software

El software, al ser libre, no debe limitar el uso o funcionamiento de cualquier otro software, limitando la libertad de este último. Es muy común encontrar dentro del software privativo cláusulas que impiden ejecutar o utilizar cierto tipo de software con el software privativo. En cambio, en el movimiento del software libre se pretende lo contrario: el usuario debe ser capaz de elegir utiliza el software que más le interese en cada momento, independientemente de si es o no software libre.

Licencia tecnológicamente neutral

La licencia no debe imponer el uso de una tecnología determinada, limitando las modificaciones que se puedan realizar sobre el software bajo la denominación open source. Se trata de permitir que cualquier tecnología tenga cabida, de manera que no se incline la balanza por una tecnología en particular.

2.3. FLOSS/FOSS

El término FOSS o FLOSS se ideó para evitar la ambigüedad producida por los términos estudiados anteriormente. De hecho, este término prácticamente es una concatenación de open source y free software. El significado de las siglas en inglés es Free (Libre) Open Source Software, nótese el uso de la palabra castellana libre dentro de la denominación en inglés, para especificar libertad, en vez de gratuidad, y así eliminar la ambigüedad del término en inglés.

Aunque generalmente el término open source se ve como una aportación a la empresa, el término free software el nombre que le da la comunidad al software libre y FLOSS como el término aportado desde el ámbito académico y universitario, tenemos que tener en cuenta que vamos a encontrar todos estos términos utilizados de forma análoga. Por tanto, es otra manera de referirse al software libre.

2.4. GNU

GNU son las siglas de GNU is Not UNIX (GNU no es UNIX), un acrónimo recursivo que sigue la tradición comenzada por los hackers desde el principio de internet para nombrar nuevos proyectos, entre ellos los de software libre.

GNU comenzó en 1983, debido a la necesidad de crear un sistema libre tipo UNIX que contuviera las mismas herramientas y funcionalidad que el sistema operativo propietario.

El movimiento GNU fue iniciado por Richard Stallman, aunque al poco tiempo ya había una considerable cantidad de hackers trabajando en el sistema, de manera que evolucionó rápidamente hasta conseguir prácticamente su objetivo en 1989, cuando la única pieza clave para desarrollar un sistema operativo libre completo que faltaba era el núcleo: la pieza encargada de hacer funcionar el hardware del sistema en una plataforma software de forma homogénea y conocida. Como veremos más adelante, cuando Linus Torvalds desarrolló desde finlandia su núcleo del sistema llamado Linux, la simbiosis entre ambos proyectos dio el pistoletazo de salida a lo que conocemos actualmente como GNU/Linux, el sistema operativo de código abierto más completo y extendido del mundo.

Durante los primeros años de vida del proyecto GNU se optó por desarrollar todas la utilidades base para sustituir aquellas que aparecían en los sistemas operativos del estilo de UNIX, con lo que la funcionalidad y las librerías base del sistema fueron escritas desde cero y liberadas a la comunidad para que otros pudieran utilizarlas. Estas utilidades fueron creciendo en complejidad hasta el punto en que muchas de ellas no sólo eran un sustituto de las equivalentes privativas, sino que disponían de muchas más características que estas, por lo que muchos usuarios de sistemas operativos UNIX sustituían algunas de ellas por alternativas libres.

El movimiento GNU no creó únicamente alternativas a las utilidades propietarias de UNIX, sino que además aportó nuevas utilidades que no existían en estos sistemas, como el editor de textos GNU Emacs, la colección de compiladores GCC (el sistema de compilación con más características existentes actualmente), así como algunas librerías de C y C++.

Como hemos comentado anteriormente, el objetivo de GNU es conseguir un sistema operativo libre. Este hecho ha creado una serie de licencias conocidas como las licencias GNU, para proteger la libertad del software que se desarrolla dentro del marco de este proyecto. Estas licencias han sido adoptadas posteriormente por la comunidad de software libre en numerosos proyectos, hasta el punto ser de las más extendidas. De hecho, la mayoría del software libre está cubierto por la licencia GPL (o su derivada LGPL) que veremos con más detalle en el siguiente bloque.

Finalmente, destacar otros proyectos que surgieron de la necesidad de sustituir otros elementos del sistema, como el entorno gráfico GNOME, que es junto a KDE, el entorno de escritorio más utilizado hoy en día.

Como nota curiosa, hay que comentar que GNU sigue en su afán por conseguir desarrollar un sistema UNIX completo, por lo que aunque disponemos hoy en día de Linux como núcleo libre, GNU sigue desarrollando su propio núcleo llamado Hurd. Este núcleo ha sufrido a lo largo de los años muchísimas modificaciones y, aunque es funcional el configuraciones básicas, aún no está completamente desarrollado y es muy limitado en muchos aspectos.

2.5. FSF

La Free Software Fundation es la fundación derivada de GNU que se encarga de velar por el software libre, así como de ayudar a la comunidad de software libre a desarrollar y difundir aplicaciones libres.

La FSF fue creada en 1985 por Richard Stallman y otros entusiastas del software libre que se unieron al proyecto GNU idearon esta fundación para buscar un método de financiamiento del desarrollo de software libre.

Esta fundación provee de una serie de servicios a la comunidad de software libre. Las vamos a ver a continuación.

Alojamiento de proyectos

Una de las tareas principales es dotar a los proyectos de software libre de un lugar donde poder centralizar el desarrollo, la difusión y los servicios asociados al software. GNU desarrolló un software de forja de proyectos llamado Savannah que es el utilizado por la FSF para dotar de servicios de gestión, difusión, descargas, desarrollo y atención a los usuarios para proyectos de software. En el bloque III veremos qué forjas son las más utilizadas junto a esta, así como otros métodos de encontrar software libre.

Formación legal

Como la mayoría de proyectos de software libre utiliza una de las licencias de GNU, la FSF se vio obligada a desarrollar cursos y formación para abogados de manera que estos pudieran obtener la información necesaria para poder defender las licencias GNU en los tribunales.

Directorios de software

Aunque GNU aglutina una parte importante del software libre disponible, no es ni mucho menos la única fuente de software de código abierto, por lo que mantiene un completo directorio de software libre para que podamos hacer búsquedas independientemente de dónde esté localizado el software, sea GNU o no.

FSF Award for the Advancement of Free Software

La FSF premia cada año a aquel software libre que avanza en el uso de las nuevas tecnologías. Este premio se concede al software libre que mejor representa el esfuerzo para desarrollar software que mejor se adapte a las nuevas tendencias tecnológicas.

Documentación

Una parte importante de los recursos de la FSF va destinada al desarrollo y la distribución de documentación para aplicaciones de software libre.

Por una parte, se encarga de crear manuales en papel y venderlos para aquellas personas o entidades que necesiten del manual impreso en formato libro. Además estas acciones son una de las fuentes de ingreso de esta organización.

Por otra parte, se dedican recursos en la elaboración de documentación para aquellos proyectos, principalmente GNU, que aún no disponen de ella o que es de muy poca calidad. De hecho, incluso se contratan recursos humanos para realizar esta tarea cuando los proyectos de software libre no puede conseguirlo de otra manera.

Software GNU

El software GNU es mantenido prácticamente a través de voluntarios, pero hay un núcleo de desarrolladores de alto renombre encargados de gestionar los cambios que se realizan. Estos desarrolladores forman parte de la FSF generalmente y, por tanto, son los encargados de velar y desarrollar nuevo software GNU. Casi todo el software de GNU tiene un soporte directo a través de esta fundación. Hay que recordar que la FSF surgió, precisamente, al agruparse parte de los desarrolladores principales de GNU.

Licencias GNU y cumplimiento de las licencias GNU

Finalmente, la FSF tiene un cometido que podríamos considerar especial: defender y velar por el cumplimiento de las licencias GNU. De hecho, la FSF tiene recursos suficientes para personarse en los casos en los que una licencia GNU es violada de manera que los proyectos de software libre, bajo unas determinadas condiciones, puedan acogerse a este servicio. En este caso la FSF actúa como un vehículo legal para proteger al software libre de incumplimiento de licencias. Casi todas las demandas interpuestas contra empresas de software debido a licencias GNU se han resuelto a través de la FSF y, muchas veces, a través del diálogo.

2.6. LINUX

A pesar de lo que mucha gente piensa, Linux no es un sistema operativo en sí mismo. Linux es un núcleo monolítico de software libre pero, únicamente con Linux no podríamos realizar todas las tareas que podemos hacer actualmente con un sistema operativo. Es decir, lo que generalmente es conocido como Linux, es en realidad un conjunto de aplicaciones y librerías que se ejecutan sobre el núcleo Linux. De todas maneras, y debido al uso que se le da al nombre, habitualmente cuando se habla de Linux se hace tanto del núcleo como de todo el sistema y deberemos discriminar su significado en función del contexto.

Si nos ceñimos al significado estricto de Linux, se trata de un núcleo monolítico desarrollado a partir de 1991 por Linus Torvalds. Este finlandés, basándose en un núcleo desarrollado en el ámbito académico llamado Minix, desarrolló una versión primaria que liberó a la comunidad del software libre utilizando la licencia GPL. Gracias a esta licencia, y debido a cómo la comunidad de software libre acogió el núcleo, más y más desarrolladores se fueron incorporando al desarrollo de él, de manera que en cuestión de 3 años se consiguió un núcleo suficientemente estable como para competir con los núcleos privativos tipo UNIX de la época. En este sentido, el núcleo Linux junto al software desarrollado por GNU fue el impulso definitivo para la creación del sistema operativo GNU/Linux que conocemos actualmente y, de hecho, ni GNU ni Linux serían tan utilizados como lo son hoy en día si no fuera gracias a esa simbiosis perfecta de la que hacen gala.

Distribución

Cuando en el mundo del software libre se habla de distribuciones, nos referimos al empaquetado de un conjunto de aplicaciones software que, en un todo y con una debida coordinación entre ellos forma un sistema operativo libre completo.

Grosso modo una distribución no es más que un conjunto de aplicaciones junto al núcleo más un conjunto de librerías que necesitan esas aplicaciones para funcionar correctamente. Evidentemente, cada distribución modifica las aplicaciones en función de la imagen corporativa o el tipo de público al que vaya dirigida la distribución. Estos cambios afectan desde la imagen o la estética hasta modificaciones específicas del núcleo del sistema.

Por tanto, a la hora de elegir una distribución, no es lo mismo utilizar una destinada al uso en el escritorio que otra preparada para servidores. Aunque todo o casi todo el software suele funcionar independientemente del tipo de distribución elegida, es posible que algunas funcionen mejor en una u otra. Por ejemplo, las distribuciones de escritorio sueles estar preparadas para ejecutar múltiples aplicaciones en tiempo real (no confundir con sistemas de tiempo real) para mejorar la experiencia del usuario, en cambio las versiones servidor permiten están modificadas para sacar el máximo partido a los parches de seguridad o exprimir al máximo el hardware para cometidos específicos, como por ejemplo el uso de un gran número de conexiones en red o el acceso a solo cierto tipo de recursos.

2.7. HISTORIA

Para finalizar este bloque, vamos a realizar un pequeño repaso a la historia del software libre. Tenemos que tener en cuenta que el software, aunque nos parezca que el modelo de negocio privativo es el habitual, en los inicios no fue así, sino que durante la década de los 60 y 70 gran parte del software era entregado con el código abierto por los desarrolladores de los computadores.

Fue posteriormente, sobre todo desde la aparición de UNIX y CPM, cuando empezó a separarse la distribución del software y el hardware, de manera que empezaba a ser factible la venta de software por un lado, y la de hardware por otro.

A continuación vamos a ver una pequeña lista de eventos ocurridos que han sido relevantes en la historio del software libre:

1969 – Creación de ARPANET

1970 – Creación de UNIX en los Laboratorios Bell

1979 – Creación de BSD en la Universidad de California

1983 – Richard Stallman inicia el movimiento GNU

1984 – Se crea el entorno gráfico X Window System

1985 – Se funda la Free Software Fundation

1989 – GNU está casi completo, pero falta el núcleo

1991 – Se inicia el desarrollo del núcleo Linux por Linus Torvalds

1992 – Primera distribución GNU/Linux: SLS

1993 – Creación de las distribuciones Debian y Slackware

1994 – Creación de Redhat y Suse

1996 – Inicio del proyecto KDE

1997 – Inicio del movimiento Open Source.

Creación de la OSI. Inicio del proyecto GNOME

1998 – Netscape es liberado como software libre

2002 – Creación de Gentoo y Linex

2003 – Creación de Knoppix y Fedora Core

2004 – Creación de Ubuntu

Por supuesto, ha habido muchos cambios desde 2004, pero los más relevantes, sobre todo el inicio o surgimiento de GNU o las grandes distribuciones GNU/Linux están contempladas. De hecho, desde 2004 y gracias al concepto de metadistribución, han sido muchas las nuevas distribuciones que han aparecido.

Hay que recordar que el software libre trata sobre libertad, y la libertad de elección entre varios proyectos es, quizá, una de las que el usuario más se beneficia.

3. Licencias

3.1. Licencias Libres

Hay gran cantidad de licencias libres, por lo tanto sólo vamos a estudiar una parte en este curso. Como referencia, podemos tomar el listado de licencias del OpenSource Institute, que se encarga de comprobar distintas licencias para ver si cumplen con los principios del software libre y el movimiento open source.

La lista podemos verla en: http://www.opensource.net/licenses/category

y contiene algunas de las licencias. Hay que destacar que recientemente, algunas de las licencias que Microsoft ha utilizando para liberar algunas partes de software son fundamentalmente licencias libres y, por tanto, están incluidas dentro del índice de licencias.

¿Cómo se decide si una licencia es libre?

Una licencia de software es libre si cumple con las cuatro libertades del software libre o con el decálogo que expusimos anteriormente sobre el open source. Como muchas veces, evaluar si se cumple o no con estas ideas o conceptos es muy complicado, podemos:

Ver si la licencia es libre por definición: Algunas licencias de software son libres por definición, ya que han surgido desde las entrañas del propio movimiento del software libre. Un ejemplo claro son las licencias GNU.
Comprobar si está incluida dentro de las licencias listadas en el OSI: El OSI se encarga de elaborar y comprobar minuciosamente esta lista, como hemos comentado anteriormente, para comprobar que cumple con las ideas del software libre y el movimiento open source.

¿Por qué son necesarias las licencias de software?

La licencia del software es la encargada de establecer los límites legales en el uso del software. En la mayoría de los países occidentales, los derechos de autor son restrictivos y son reservados implícitamente por el autor de ese software mientras no se diga lo contrario.

Este hecho, limitar los derechos de los usuarios por defecto excepto en aquellos casos en que se exprese lo contrario es lo que dio lugar a las licencias de software. Las licencias de software privativo utilizan la licencia para expresar exactamente qué se puede hacer con el software, en cambio las licencias de software libre se encargan de liberar ciertos derechos sobre el software de manera que el usuario tenga capacidad para poder hacer uso de unos derechos que, de otra forma, no podría ejercer.

Generalmente las licencias de software libre se encargan, por tanto, de precisar los derechos que tienen aquellas personas que utilizan el software: uso, distribución, copia, lucro, etc.

3.2. Copyleft

Antes de pasar a estudiar algunas de las distintas licencias de software libre que nos podemos encontrar, hay que situar estas licencias en el entorno en que surgieron.

Cuando el movimiento del software libre comenzaba, estaba de moda liberar los trabajos mediante copyleft. Con el copyleft trata de cambiar la mentalidad hasta ese momento en que se retienen todos los derechos, de manera que se liberar derechos para aquellos que utilizan el software. De esta manera, se intenta dar más libertad a aquellos que deseen realizar trabajos derivados del software o realizar tareas de difusión e incluso vender el software.

De esta forma, la manera de ver el copyright cambia desde:

A esta nueva visión de ver el copyright:

“Copyleft. All rights reversed.”

Izquierdos de copia. Todos los derechos invertidos.

Este párrafo, que se puede encontrar en mucho software liberado como copyleft y que comenzó como un juego de palabras fue tomando consistencia, hasta que se inició un movimiento derivado de él que cambiaría la forma de ver el software.

De hecho, esta nueva perspectiva permitiría a Richard Stallman comenzar el movimiento GNU y, posteriormente las licencias GNU, con las que se pretende proteger al copyleft del exceso de libertad que puede ser contraproducente para la comunidad de desarrolladores de software libre. De hecho, el copyleft como tal no cumple con las cuatro libertades enumeradas por GNU para contemplar a un software como libre. Más adelante veremos cómo se desarrollaron nuevas licencias que hacían compatible esta manera de ver el software y que se ajusta más al software libre tal y como lo conocemos hoy en día.

La licencia copyleft típica

“Nombre del software. Copyright Nombre del autor. Año XXXX.

Este software es copyleft, puede usarlo con cualquier propósito.”

Esta licencia, que conceptualmente parece sencilla, tiene una serie de inconvenientes importantes que no protegen al autor ni al software. Por una parte, el autor puede perder la autoría, en el sentido en que la licencia no obliga a mantener o dar crédito al autor. Además, dado que el software se ejecuta sobre una plataforma de hardware, puede haber una serie de garantías implícitas con las que el autor posiblemente no haya contado.

Es importante saber también que se permiten trabajos propietarios completamente privativos, con lo que se pueden perder aportaciones importantes al software ya que esos trabajos derivados no tienen la obligación de contribuir al proyecto original. Esta licencia es tan permisiva, que incluso se permite relicenciar el software sin ni siquiera pedir permiso.

3.3. Licencia MIT

La licencia MIT, también conocida como MIT/X11 debido a que el MIT (Instituto Tecnológico de Massachusetts) utiliza muchas otras licencias, permite casi una libertad total. En este aspecto es muy similar a la licencia copyleft con algunas modificaciones.

La licencia MIT añade una serie de cláusulas que protegen en parte al autor, aunque como veremos posteriormente, esta cláusula se puede saltar fácilmente. Una característica importante es que esta licencia introduce un blindaje ante garantías implícitas y expresas, con lo que en principio el autor está legalmente protegido contra ellas. Además establece algunas cláusulas más, como que el software no tiene por qué adaptarse con ningún propósito en particular o el autor no tiene que hacerse cargo de ningún daño derivado del uso del software.

Aunque añade un conjunto de cláusulas interesantes, tiene bastantes pegas, desde el punto de vista del autor, ya que:

Permite productos derivados completamente privativos.
Se permite relicenciar el código.
Se puede usar el renombre de los autores para promocionar, por ejemplo, el software derivado.
La documentación tiene que tener la misma licencia, o al menos aparecer en ella.
No obliga a distribuir el código fuente.

Finalmente, hay que decir que esta licencia se considera una metalicencia. Las metalicencias son aquellas que sirven de plantilla para generar licencias similares siguiendo los mismo criterios pero que no son compartidas por distintos proyectos de software libre, ya que difieren ligeramente. Es decir, cada vez que utilizamos la licencia, lo que estamos haciendo realmente es crear una licencia basada en esta para licenciar nuestro software. Más adelante veremos cómo existen varias licencias de este tipo y que son muy comunes.

3.4. Licencia BSD

La licencia BSD nació en la Universidad de California. Esta licencia en sus orígenes contenía una cláusula que obligaba a que en todos los productos donde se utilizara se incluyera a la Universidad de California como autora de la aplicación. Las licencias BSD que incluyen esta cláusula son conocidas como la vieja licencia BSD.

La licencia BSD nueva, o la licencia BSD de dos cláusulas es la que se suele utilizar normalmente. Esta no contiene la cláusula que acabamos de nombrar, con lo que no es necesario atribuir a la Universidad de California software que no ha realizado. Cuando hablemos de licencia BSD, siempre nos referiremos a esta última mientras no se especifique lo contrario.

Aunque la licencia BSD es en esencia similar la licencia MIT, contiene algunas partes interesantes. Por ejemplo, no se puede utilizar a los autores sin el permiso explícito de ellos para promocionar software derivado, como ocurría en la MIT, así como tampoco se permite relicenciar y se reserva explícitamente todos los derechos.

Esta licencia, por supuesto, también protege de las garantías implícitas derivadas del uso del software.

Como todas las licencias, podemos encontrar también algunos inconvenientes de debemos conocer:

No obliga a distribuir el código original.
No es una licencia actualizable.

Antes de continuar, vamos a ver qué son las licencias actualizables. Cuando se escribe el texto de una licencia, es posible que posteriormente nos encontremos con la posibilidad de encontrar pegas posteriores que invaliden partes de la licencia y que, por tanto, hagan de esta inservible. Para proteger a las licencias de estos problemas, lo que se pensó es en la creación de las licencias actualizables. Estas licencias permiten que cuando se utiliza un software sujeto a ellas, se permita utilizar la versión de la licencia con la que se liberó el software o una posterior. Más adelante veremos como con las licencias GNU se consiguió de esta manera que se pudiera actualizar las licencias sin ningún problema a medida que se va desarrollando el software.

Finalmente, y antes de terminar, hay que comentar que la licencia BSD es también una metalicencia.

3.5. Licencia GNU: La licencia GPL

Vamos a ver ahora el conjunto de licencias más utilizadas actualmente: la Licencia Pública General de GNU, o GPL en sus siglas inglesas.

Realmente no se trata de una única licencia, ya que ha pasado por varias versiones, estando actualmente en la versión 3, que se dio a conocer a mediados de 2007. Posteriormente veremos las diferencias fundamentales entre las distintas versiones de la licencia, pero antes vamos a estudiar las características genéricas de este conjunto de licencias.

Las licencias GPL derivan del movimiento copyleft. Como hemos visto, este movimiento liberaba los derechos sobre el software, de manera que cualquiera podía hacer lo que quisiera con él. Aunque en principio esto parezca dar más libertad al usuario (y realmente es así inicialmente), lo que se consigue es que el software desarrollado por la comunidad de software libre sea atado por alguna compañía de manera que se aproveche de la ventaja tecnológica de este software (hasta aquí bien, claro) pero que luego no libere o ayude a la comunidad contribuyendo posteriormente con las partes modificadas.

Ante esta situación GNU decidió crear las licencias GNU. En las primeras intentonas se siguió una estrategia de metalicencia. Este tipo de licencias ya las hemos comentado anteriormente. De esta manera surgió la Licencia Pública General de Emacs y la Licencia Pública General de GCC.

Estas dos primeras licencias desarrolladas por GNU eran idénticas, exceptuando el nombre del software al que protegían. Además, para que los trabajos derivados de ese software se establecía que los trabajos derivados debían mantener exactamente la misma licencia.

Al principio, el uso de estas licencias parecía una buena idea, pero un día toparon con un gran problema: incompatibilidad de licencias. ¿Qué ocurría si alguien quería desarrollar un software que utilizara partes de Emacs y partes de GCC para crear nuevo software? Simplemente no podían, no se podía mantener exactamente la misma licencia.

3.5.1. El nacimiento de la Licencia Publica General (GPL) de GNU

Para solventar el problema entre licencias libres, y para evitar una explosión de distintas licencias de software libre que fueran incompatibles, GNU decidió crear una licencia única para proteger todo el software que desarrollaban.

En 1989 se unificaron las licencias GNU en la versión 1 de la Licencia Pública General (GPL). Esta licencia proporcionaba los pilares básicos para la creación de software libre de manera que fuera protegidos legalmente de forma efectiva.

Una de las características fundamentales de esta licencia era el soporte de nuevas versiones. Cuando se obtiene un software con licencia GPL se puede utilizar la versión de la licencia que acompaña al software o cualquier versión posterior en función de nuestros intereses. Esta es una manera increíblemente efectiva de poder actualizar la licencia en un proyecto de software libre sin necesidad de tener que relicenciar el proyecto completo cuando no interesa. Además, puede ser que posteriormente una nueva versión de la licencia recoja algún caso o treta legal que se escape en versiones anteriores que permita saltarse alguna parte de la licencia de forma efectiva: si la licencia no fuera efectiva, no habría una manera sencilla de poder acogerse a nuevas versiones de la licencia en caso de ser necesario.

Afortunadamente, el uso de esta cláusula sirvió para que muchos proyectos adoptaran la segunda versión de la licencia en 1991, al detectarse algunas deficiencias en la primera versión de la GPL.

3.5.2. Versión 2 de la Licencia Pública General

La segunda versión de la GPL añade una serie de características interesantes para evitar algunos inconvenientes surgidos en la primera versión. De esta manera, esta segunda versión añadía el concepto de no necesidad de aceptación de la licencia así como el soporte para la redistribución del código de forma alternativa.

Cuando hablamos de “no necesidad de aceptación de la licencia” quizá nos llame la atención. Realmente no debería ser tan chocante, sobre todo cuando se trata de no restringir el uso de software libre. De hecho, esta cláusula hace referencia al hecho de que, en caso de que sólo se vaya a usar el software, no es necesario siquiera aceptar la licencia. En cambio, si se pretende modificar, incluir, redistribuir, etc. el software, entonces sí que se debe aceptar la licencia.

Por otra parte, cuando se redactó la primera versión de la GPL, apenas comenzaba a utilizarse Internet, de manera que cuando alguien creaba nuevo software, generalmente distribuía el código conjuntamente al programa, por ejemplo mediante el envío físico de disquetes que contuvieran tanto el programa como el código fuente. Esto cambió radicalmente cuando empezó a utilizarse Internet de manera masiva: ya no hacía falta incluir sistemáticamente el código con el software. Por tanto, la licencia se actualizó a este hecho para permitir incluir simplemente una manera de cómo obtener el código, generalmente mediante una dirección en Internet desde donde descargarlo.

Otra curiosidad de la segunda versión de la licencia GNU es la inclusión de una cláusula paradógica: prohibido prohibir. Si la licencia da unos derechos a aquellos que reciben el software, no se puede unilateralmente recortar parte de estos derechos. La manera de hacer esto correctamente, es el doble licenciamiento. De esta manera, en función del uso que se le vaya a dar el software se puede optar entre una licencia GPL u otra, pero la licencia GPL original queda intacta. Este es el método que utilizan muchos proyectos de software libre.

Por otra parte, también se actualizó la licencia para cumplir con la legislación de cada país, cuando la licencia incumpla alguna de las leyes en ese país donde se va a usar el software.

Hemos dejado para el final la parte más importante: no se permite incorporar parte del software de forma privativa. Esto es muy importante, ya que si no fuera así la licencia no serviría para nada. La única manera de aportar código, es de en forma de software libre, si no simplemente no se puede incluir en el proyecto. Esta restricción es eliminada parcialmente si se hace uso de la LGPL, una licencia análoga a la GPL pero con algunas pequeñas modificaciones que veremos más adelante.

3.5.3. Versión 3 de la Licencia Pública General

La tercera versión de la GPL fue necesaria debido a la creación de nuevas tecnologías emergentes, como el uso del DRM (Gestión de derechos digitales), los dispositivos embebidos o nuevas medidas tecnológicas que se utilizaban para saltar algunas obligaciones legales contempladas en la versión anterior. De hecho, la paradoja de prohibido prohibir entra de nuevo en juego, de manera que no se puedan alterar los términos de la licencia de ninguna manera.

Por una parte, se prohibe el uso de medidas de DRM que impidan ejercer por parte del usuario los derechos que le permite la licencia. Esta medida se aplicó debido a que, aunque algunas empresas desarrollaban software libre para crear nuevo software y cumplían legalmente con la licencia liberando el software, como ese software se ejecutaba en plataformas hardware específicas, solo el software firmado digitalmente por esa empresa era ejecutado por la plataforma hardware. De esta manera, aunque el usuario disponía del código fuente y podía ejercer sus derechos, el software modificado no podía utilizarse ya que la plataforma hardware lo rechazaba al no poseer esta firma, con lo que el uso de la licencia GPL quedaba simplemente como un hecho testimonial.

Por otra parte, el uso de dispositivos embebidos con aplicaciones adaptadas a las necesidades de estos hace imposible la inclusión del código fuente junto a ellos. Por tanto, la nueva versión permite que en los casos en los que no se pueda distribuir el código junto a los dispositivos embebidos, se proporcione una forma de poder acceder a ese código bien a través de un medio físico duradero que acompañe al producto (por ejemplo un CD-Rom) o bien una manera alternativa: descarga electrónica o medio tradicional.

Otras características interesantes de la GPL es la inclusión de los denominados permisos adicionales. Estos permisos solo pueden añadirse si se tiene todo el copyright del software que se está desarrollando y permiten especificar cláusulas adicionales que den más derechos a aquellos que accedan al software. Además, para evitar algunos problemas legales que pudieran surgir, se elimina el derecho de poder cancelar la licencia.

Finalmente, y como nota curiosa, se añade la característica de que la licencia permite la extensión de las patentes relacionadas con el software a toda la comunidad de software libre. Este caso es más sencillo explicarlo con un ejemplo:

Supongamos que una empresa añade funcionalidad a un proyecto de software libre cubierto con la versión 3 de la GPL, y supongamos también que esa parte del código hace uso de una patente que puede usar esa empresa (bien porque es una patente suya o porque tiene un contrato de uso de la patente). En el caso de que la empresa hiciera pública una versión (bien binaria o de código fuente) en que se utilizara esa parte del software, dotaría a todos los desarrolladores de software libre del derecho de uso de esa patente.

Esta cláusula, en el que el derecho de uso de patentes se extiende de forma vírica, es la manera que tiene la GPL de evitar denuncias por patentes desde empresas hacia proyectos de software libre. Evidentemente, también es una de las cláusulas que más ha dado que hablar, ya que las empresas no están dispuestas a ello. Realmente es como un desafío: o usas software libre y dejas usar las patentes que has utilizado o no puedes aprovechar las ventajas de software libre.

3.5.4. La licencia de Documentación Pública

En los casos en que tengamos que licenciar otro material que no sea software, la licencia GPL nos servirá de bien poco. Para ello GNU creó la licencia FDL (Free Documentation License). Esta licencia, aunque recoge muchas de las ideas expresadas en la GPL, está especialmente adaptada para licenciar la documentación del software.

Utilizando esta licencia podemos, por ejemplo, fijar párrafos invariables que no pueden ser modificados. De esta manera el autor se asegura que los trabajos derivados (generalmente traducciones) de esa documentación contengan esos párrafos íntegros. Generalmente se utiliza para notas importantes y para preservar el copyright del autor original.

En http://www.gnu.org/licenses/fdl.txt podemos obtener el texto completo de la licencia.

3.6. Creative commons

La licencia CC, o metalicencia mejor dicho, permite licenciar obras audiovisuales de forma muy flexible, siguiendo el concepto general de copyleft adaptándolo a nuestras necesidades. De hecho es una de las más utilizadas hoy en día para liberar ensayos, imágenes y canciones por muchos autores.

Esta licencia tiene detrás a la institución Creative Commons, que al igual que la FSF con las licencias GNU, se encarga de adaptar y difundir el uso de la licencia CC. Esta institución está formada por un grupo de expertos en leyes aplicables a la red y propiedad intelectual, por lo que la licencia CC no sólo se ha creado para ser utilizada en un país, ya que ha sido adaptada a multitud de lugares del mundo, en función de las leyes vigentes en cada país.

La licencia CC es una licencia que introduce por primera vez el concepto de atributos. En función de cómo combinemos estos atributos, podemos modificar la licencia base a nuestro antojo para adaptarla al uso que queramos dar. Es importante recalcar que la licencia CC no es una licencia de software.

Los atributos

Como comentábamos anteriormente, la licencia CC utiliza una serie de atributos que podemos mezclar para adaptar la licencia. Los atributos de los que disponemos son:

Attribution: Se debe dar crédito al autor original del trabajo del que partimos, así como de los autores anteriores si los hubiera.
Noncommercial: No se pueden realizar operaciones comerciales con el material licenciado, sea el trabajo original o uno derivado.
No Derivative Works: No se permited trabajos derivados, de manera que no podemos hacer modificaciones al material licenciado que utilice este atributo.
Share Alike: En caso de que se realicen trabajos derivados, es necesario que se mantenga intacta la licencia de los trabajos derivados.

Utilizando estos atributos podemos crear un conjunto de distintas licencias, todas ellas bajo el sello CC. Por ejemplo se pueden combinar los atributos:

Attribution + Share Alike: En este caso particular estamos bajo la conocida licencia CC-by-sa, que establece que se tiene que dar crédito en trabajos derivados así como en usos del material original y, en caso de que se realicen trabajos derivados, estos deben tener exactamente la licencia CC-by-sa.
Noncommercial + No derivative: En este caso no se permite ninguna modificación del trabajo, sea o no para uso comercial. Como no se hace mención al atributo attribution podríamos obviar mencionar al autor original si usamos la imagn de forma personal.

3.7. Cuadro Resumen

Como el conjunto de licencias es amplio, a continuación se puede ver un cuadro resumen donde ver rápidamente y a modo de referencia las distintas características de algunas de las licencias:

4. Aplicaciones de Software Libre

4.1. Forjas de software

Las forjas de software son lugares en línea preparados específicamente para desarrolladores, de manera que puedan crear nuevos proyectos de software libre y disponer de toda la infraestructura necesaria para llevar a término dichos proyectos.

Generalmente, las forjas de software disponen de un repositorios de código con control de versiones (indispensable para desarrollar software en condiciones), sistemas de control de fallos del software, foros y listas de correo para usuarios y desarrolladores, espacio web para la página del proyecto y algunos servicios más complejos, como las granjas de compilación (necesarias para los proyectos grandes, que necesitan mucho tiempo de compilación).

Por otra parte, las forjas de software generalmente disponen de un servicio de descargas con múltiples mirrors por todo el mundo, de manera que la difusión de los proyectos que contienen se puedan realizar de manera ininterrumpida.

Otro de los servicios interesantes de las forjas de software es que permiten la comunicación entre desarrolladores y usuarios, de manera que puedan resolverse mejor los problemas relacionados con ese software.

Actualmente, las forjas de software también están incluyendo servicios para la venta de soporte asociada a proyectos de software libre, de manera que los desarrolladores puedan cobrar por los servicios de soporte asociados, si se presta la ocasión, de manera muy sencilla tanto para el desarrollador como para el usuario que hace una petición de soporte.

Algunas de las forjas más conocidas son:

4.2. Directorios de software en línea

Los directorios de software no son más que listados ordenados por categorías con referencias al sitio original desde donde podemos descargar el software. Actualmente, también ofrecen sistemas de comentarios por parte de los usuarios y sistemas de votación para las distintas versiones, de manera que podemos comprobar si el software tiene o no aceptación, o preguntar a otros usuarios dudas en cuanto a funcionalidad de dicho software.

BerliOS (http://www.berlios.de/)
Freshmeat (http://freshmeat.net/)
Open Source Windows (http://www.opensourcewindows.org)
OSSWin Project (http://osswin.sourceforge.net)
Alternativas Libres (http://alts.homelinux.net)
CDLibre (http://www.cdlibre.org)

4.3. Repositorios de software

Generalmente, con las distribuciones de GNU/Linux suelen venir preinstalados unos repositorios de software. Estos repositorios no son más que colecciones de software ya empaquetadas y preparadas para la distribución GNU/Linux que utilicemos.

Los repositorios de software son los lugares desde lo que instalamos generalmente software en sistemas operativos abiertos, ya que los programas empaquetados que contienen han sido testeados pos los desarrolladores de la distribución. De esta manera, nos ahorramos tiempo en mantenimiento, ya que podemos instalar el software cómodamente (generalmente, con unos pocos clicks, ya que las distribuciones actuales tienen gestores de repositorios de software con una interfaz gráfica muy sencilla e intuitiva).

Además, los repositorios de software, junto con el software de gestión de repositorios instalado en cada versión, nos libra de tener que compilar, buscar, descargar e instalar las dependencias de ese software, de manera que siempre que podamos, es preferible utilizar el software preempaquetado de estos repositorios.

Existen tres grandes tipos de repositorios: repositorios Debian, respositorios RPM (Redhat) y metarepositorios.

Tanto los repositorios Debian como los RPM son repositorios de software preempaquetado, precompilado y preconfigurado, de manera que instalar un nuevo programa solo implica indicar qué tiene que instalarse, y el gestor de paquetes adecuado (APT para los repositorios Debian o YUM para los repositorios RPM) se encarga del resto. Solo en el software específico para administradores tendremos que realizar configuraciones a mano de ese software.

Por otra parte, los metarepositorios tienen un métodos de funcionamiento heredado de BSD. Estos metarepositorios, solo contienen especificaciones de cómo descargar y compilar el software pero no el software preempaquetado. Dentro de este tipo de repositorios podemos contemplar el sistema que utiliza Gentoo (usando su gestor de metapaquetes Emerge). La ventaja de este tipo de repositorios es que podemos modificar la manera en que se compilan los programas, optimizándolos para nuestra arquitectura específica o sólo incluyendo cierta características de los programas para, por ejemplo, ahorrar espacio. Desgraciadamente, no es oro todo lo que reluce, ya que en el caso de tener problemas en la compilación, las soluciones pueden ser más costosas de encontrar. Además, hay que tener en cuenta que la compilación de un software "grande", como pueda ser el sistema de ventanas gráfico X.org o el entorno de escritorio GNOME puede llevar mucho tiempo, con lo que tenemos que tenerlo en cuenta, ya que los requisitos para compilar dicho software suele ser mayor que el requisito para usarlo.

De todas maneras, el hecho que nos interesa es poder realizar búsquedas en el repositorio. Por ejemplo, en los repositorios Debian podemos utilizar la utilidad apt-cache para realizar búsquedas, de manera que podamos encontrar software ya empaquetado con la versión soportada por nuestra distribución.

4.4. Selección de software libre

Existen tres grandes tipos de repositorios: repositorios Debian, respositorios RPM (Redhat) y metarepositorios.

4.4.1. Servicios y administración

A continuación mostramos una lista de software dedicado a ofrecer servicios para que consuman los clientes, generalmente de forma remota. también se presentas herramientas típicas que se encuentran en servidores, así como algunas herramientas administrativas.

4.4.2. Aplicaciones de escritorio

Procesadores de texto;

LibreOffice Writer
Abiword
Kword
Lix

Hojas de calculo:

LibreOffice Calc
Gnumeric
KSpread

Bases de datos:

Glom
Kexi

Presentaciones:

LibreOffice Impress
Kpresenter

Organizadores de información Personal

Evolution
Kontact
Mozilla Thunderbird
Chandler Project
Pimlico Suite

Visores y generadores de documentos electrónicos

PDFCreator
Evince
KPDF
SumatraPDF

Diagramas

Kivio
Día

5. Migración al Software Libre

Un factor crucial para el éxito de la migración es el análisis en profundidad de la situación de partida. Esta tarea usualmente consumirá gran parte de los recursos iniciales del proyecto, tanto en tiempo como en mano de obra. De todas maneras, un conocimiento detallado de los documentos o las aplicaciones de base de datos evita realizar ajustes imprevistos durante la migración y permite el establecimiento de planes de actuación con suficiente antelación. Además, la determinación de la situación de partida es también la base para identificar los requisitos funcionales del nuevo sistema. Aspectos importantes a tener en cuenta en este contexto incluyen, por ejemplo, los siguientes:

Bases de datos y estructuras de datos
Documentos y formatos de documentos
Aplicaciones y sus interfaces
Funcionalidades disponibles
Disponibilidad de datos y aplicaciones
Atajos y problemas
...

En este punto vamos a dar una visión global de qué es lo que debemos saber sobre la empresa, sus sistemas de información y su funcionamiento, para maximizar las posibilidades de éxito en una migración a software libre. Hay que tener en cuenta que la presente guía es sólo una guía de buenas prácticas, en ella se describen una serie de pasos para llevar a cabo una migración pero sin entrar en los detalles. Para clarificar un poco el contenido de esta guía, se van a utilizar ejemplos basados en una empresa ficticia en aquellos puntos que se consideren de interés concreto.

5.1. 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".

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.

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.

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.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.

5.2. Objetivos

Se debe identificar cuales van a ser los objetivos iniciales perseguidos por la migración. Aunque estos puede que cambien durante la planificación al encontrarnos con posibles obstáculos como por ejemplo aplicaciones no migrables.

¿Cual va a ser la finalidad de la migración?
¿Reducir costes?
¿Mejorar el sistema?
¿Obtener independencia frente a distribuidores?
¿Regularizar la situación de la empresa con respecto a las licencias de software?

5.3. Planificación

El trabajo del proyecto comienza estableciendo un plan que describa el camino a seguir para llegar al objetivo. El plan de migración debería contener como mínimo la siguiente información: fecha final del proceso de migración, recursos materiales y humanos, participación de terceras partes, hitos durante el proceso de migración y costes. La planificación del proyecto es también la base para una gestión eficiente de la migración.

Como en cualquier implantación de un nuevo sistema de trabajo, se debe estudiar muy detenidamente toda la información disponible y planificar todos lo pasos a seguir para garantizar el éxito. Una vez se ha llevado a cabo la toma de requisitos, ya se conoce perfectamente el estado de la empresa en cuanto a software se refiere. Es el momento de empezar a planificar la estrategia que se va a seguir para llevar la migración a buen término y lograr los objetivos establecidos en el punto anterior.

Este es el momento de tomar decisiones en base a la información recogida y de estas decisiones depende en gran medida el éxito de la migración.

5.3.1. Planificación técnica

Comenzaremos por la parte técnica de la planificación, en este punto se debe decidir que tipo de migración se va a llevar a cabo y cómo. Esto nos servirá para dividir la migración en pequeños pasos o tareas que hagan la gestión del proyecto mucho más fácil. Cuanto más nivel de detalle se alcance en la descripción de las tareas, más sencillo será después planificar que recursos humanos y temporales asignarle.

Cosas a tener en cuenta

Este documento no pretende ser un manual exhaustivo de cómo realizar una migración en términos técnicos. Solo es una guía en la que se intenta establecer una serie de pasos o procedimientos que ayudarán a planificar y ejecutar una migración a software libre.

Tipos de migración

Existen diferentes tipos de migración. No siempre es posible llevar a cabo todos los tipos de migración y se debe decidir cual conviene más en cada caso concreto.

Migración de los servicios (servidores)

En este tipo de migraciones solo las aplicaciones de los servidores se migran, esto es posible solamente si existe un reemplazo compatible (en la mayoría de casos para aplicaciones de servidores como correo electrónico, paginas web, etc... sí que existen alternativas libres) con los clientes.

Por ejemplo, si nuestro servidor ofrece servicio de autenticación de usuarios en un dominio Microsoft Windows, carpetas compartidas, servicios de correo electrónico y páginas web se puede migrar a un entorno con GNU/Linux como sistema operativo, OpenLDAP y Samba para la autenticación de usuarios en dominios Microsoft Windows y carpetas compartidas, Postfix o Sendmail para los servicios de correo electrónico y Apache Web Server o LightHTTPD como servidor de páginas web o directorios WebDAV.

La ventaja de este tipo de migración es que las aplicaciones instaladas en los clientes no se alteran en ningún momento, es decir, los usuarios de las aplicaciones cliente no notan ningún cambio. Además estos usuarios no necesitarán formación dado que continúan manejando las mismas aplicaciones. Esta es una gran ventaja, ya que los usuarios, al no tener que aprender a usar nuevas herramientas, seguirán siendo, al menos, tan productivos como antes de la migración del servidor.

Además, es muy probable que la productividad de los usuarios aumente, ya que en términos generales, los servidores basados en GNU/Linux soportan una carga mayor que aquellos utilizando software privativo. De esta manera, servidores que antes de la migración soportaban una carga alta de transacciones, al ser migrados podrán soportar aún más transacciones con el mismo hardware, con lo que los usuarios notarán una disminución del tiempo de respuesta del servidor, y por tanto la productividad de estos usuarios puede llegar a aumentar de manera considerable, ya que podrán realizar más tareas en mismo tiempo.

Los únicos usuarios que necesitan formación en las nuevas aplicaciones (si no la poseen ya) son los técnicos encargados del mantenimiento y buen funcionamiento de los servidores. Por lo general éste colectivo de profesionales suele ser mucho mas receptivo a los cambios, debido a su mayor conocimiento de los sistemas, que los usuarios finales.

Siempre que se realice una migración de algún servidor, es importante que el técnico o administrador encargado de dicho servidor sea participativo en la migración. De esta manera podrá aprender durante la migración las tareas básicas de administración del nuevo sistema.

Si conseguimos que el administrador sea participativo, podemos conseguir que los costes de formación sean nulos para tareas sencillas, y para tareas más sofisticadas podemos reducirlos considerablemente.

5.3.2. Planificación de comunicaciones

La responsabilidad de comunicar y motivar al personal es una tarea, claramente definida, de los encargados de la gestión del cambio. Esta tarea comienza y debe ser llevada a cabo incluso antes de que el proyecto de migración empiece realmente. El liderazgo se alcanza mediante la comunicación, así pues el liderazgo y el estilo de comunicación están inseparablemente conectados, requiriendo un grado particularmente alto de habilidad social. Esto significa que los proyectos que se planeen deben ser transparentes para todos los miembros, de la empresa o de fuera de ella, involucrados en la migración. Se deben identificar tanto las áreas que se van a migrar como las que van a permanecer inalteradas.

Además, diferentes canales de comunicación deben ser utilizados para diseminar la información, como por ejemplo reuniones generales informativas, charlas con los empleados, seminarios o circulares internas, también se puede utilizar la intranet de la empresa (en caso de que se disponga). Se deben establecer en una primera etapa los medios y las maneras de responder a las preguntas y las dudas, así como los miedos y preocupaciones del personal de la empresa, relacionados con el cambio.

Aconsejamos seguir el siguiente plan de comunicación con los empleados:

Para realizar esta tarea, se aconseja, antes de realizar la migración y cuando dispongamos de la planificación técnica realizada, notificar todos esos cambios al personal. De esta manera, el personal de la empresa sabe, antes de que ocurran los cambios realmente, dónde van producirse. También debemos notificarles cuándo van a realizarse estos cambios.
Establecer un sistema de comunicación de incidencias que puedan utilizar los empleados, para poder atender las dudas que les surjan. Este es un punto clave y no debe dejarse pasar, ya que si los empleados disponen de esta herramienta, la pérdida de productividad debida al cambio será menor, sobretodo durante las primeras semanas.
Establezca una reunión general inmediatamente posterior al cambio, para notificar las posibles modificaciones al plan inicial de migración.
Realice reuniones posteriores de control, para comprobar cómo los distintos usuarios se han adaptado al cambio y solucionar problemas de última hora.

Es recomendable utilizar una herramienta de gestión de proyectos, como por ejemplo dotProject, para facilitar la tarea de gestionar el proyecto de migración y todas sus actividades.

5.3.3. Planificación de recursos humanos

Una vez dividida la migración en tareas detalladas y bien definidas se debe detallar también qué recursos humanos se van a asignar a cada tarea. Es decir, quién va a llevar a cabo qué tareas. En este punto es importante la buena comunicación entre todos los miembros del proyecto para que todos tengan claras las tareas que deben realizar.

En este tipo de proyectos es muy importante el buen desarrollo del plan de comunicaciones elaborado en el apartado anterior.

También se deben planificar los recursos que se van a dedicar a la formación, calendario de formación, etc. Así como los posibles incentivos a aplicar al personal participante en el proyecto de migración.

Estas directrices no pretenden ser una guía de Gestión de Recursos Humanos, y las empresas ya se habrán encontrado anteriormente con estas cuestiones en otras áreas. Tendrán capacidad de hacerles frente de manera amable y favorable y así el personal de Recursos Humanos debería implicarse desde el principio. La intención es simplemente resaltar el tipo de cuestiones que han surgido en otros sitios que han migrado a software libre.

Es muy importante que se consulte a todo el personal y que se le mantenga informado de lo que se va haciendo. Un modo de hacerlo es crear una intranet que se pueda mantener actualizada fácilmente y en la que haya una sección dedicada a las opiniones de los usuarios.

Hay ciertas reacciones típicas a los cambios en las prácticas laborales que habrá que afrontar:

Miedo a lo desconocido

El uso del software libre será completamente nuevo para la mayoría de los usuarios y el personal de sistemas. El miedo a lo desconocido hará que las personas se resistan al cambio porque es nuevo para ellas.

Habrá usuarios que son más curiosos por naturaleza, que pueden sentirse felices de conocer cosas nuevas y son ellos las que deberían probar el software libre en primer lugar. Hasta ahora la experiencia indica que una vez que la gente vence sus reservas encuentra que el software libre no es muy diferente en su uso en comparación con el software propietario y está encantada de usarlo. Por ello es probable que este grupo inicial de usuarios se pase al software libre con entusiasmo. En cualquier caso, esta gente sería también la que proporcione los comentarios y sugerencias más útiles.

El primer grupo de usuarios podría utilizarse en pruebas piloto y una vez que tengan cierta experiencia ya pueden convencer y enseñar a sus colegas. En cualquier caso, ya en la segunda fase, los usuarios que pudieran ser más reservados necesitarán disponer de mayores facilidades de apoyo en forma de ventanillas de atención, intranets y usuarios locales con experiencia.

El mismo proceso se puede usar con el personal de sistemas pero el esfuerzo de formación podría ser importante si el entorno propietario existente no es como UNIX. El personal de sistemas en particular necesita desterrar sus temores desde el comienzo. Serán un punto focal para todos los problemas que indefectiblemente van a aparecer y si no creen en el proyecto no podrán animar a los usuarios de manera positiva.

El temor de que el CV pierda importancia

Tanto el personal de sistemas como los usuarios pueden pensar que no usar el software “estándar industrial” perjudicará su capacidad para desarrollar su carrera. Este es un problema delicado que hay que tratar con mucho cuidado. La empresa no querrá verse muy implicada en este enfoque pero hasta que el software libre sea de uso generalizado las empresas se pueden encontrar con él con cierta frecuencia.

Es importante tratar de darle la vuelta a este punto, es decir, enfocar el hecho de conocer el software libre como un complemento a su carrera profesional. No sólo podrán decir que utilizan el software "estándar industrial", sino que además saben utilizar software libre.

Saber es poder

La gente que conoce los sistemas y configuraciones existentes tiene un cierto poder y podrían sentirse bastante reacios a perderlo si el entorno de software libre es muy diferente del existente. Y otra vez aparece la necesidad de una gestión cuidadosa ya que esas personas tienen un papel fundamental en el funcionamiento de los sistemas existentes. Quizá sea necesario que estén entre los primeros en recibir formación sobre los nuevos sistemas para que su posición en la entidad se mantenga.

5.3.4. Plan de contingencia

Como en todo proyecto, durante la migración pueden surgir problemas. Por eso se debe estar bien preparado y organizado para poder asumir y resolver las posibles incidencias que aparezcan en el transcurso de la migración.

El conocimiento compartido es la base para poder ahorrar recursos cuando surgen problemas, por eso se debe establecer métodos para informar de errores para poder estudiar la causa, dar una solución y aprender del error cometido para evitar que vuelva a suceder.

Se recomienda la utilización de sistemas de gestión de incidencias. Para organizar, gestionar y priorizar los posibles imprevistos.

En un proyecto de este tipo, y sobre todo si no se tiene experiencia previa, se debe esperar lo inesperado, así que también se deben planificar las herramientas y recursos para realizar una vuelta atrás en el caso, muy desfavorable e improbable, de que la migración falle completamente.

5.3.5. Planificación temporal

La planificación temporal se usa para desmenuzar el proyecto en detalle. Esta planificación requiere que se establezcan las fechas y plazos de entrega de forma realista para cada paquete de trabajo. La planificación temporal del proyecto dependerá de la fecha límite establecida para el proyecto de migración. Además, la planificación temporal del proyecto especificará las fechas de comienzo, hitos y fechas de finalización de cada paquete de trabajo. Este calendario también sirve como una de las bases para una monitorización y gestión eficiente del proyecto.

Se establecerá cual es la fecha más adecuada para llevar a cabo la migración, por ejemplo puede ser adecuado realizarla durante el cierre vacacional de la empresa (en caso de haberlo). Si es necesario se establecerán horarios especiales para el personal encargado de la migración, de manera que la migración se pueda llevar a cabo alterando lo mínimo posible el buen funcionamiento de la empresa.

Planificación de pruebas

Modificar el calendario de migración para que incluya la realización de pruebas y un periodo de soporte post-migración.

5.3.6. Plan de evaluación

Establecer criterios para evaluar el éxito de la migración. Básicamente se trata de verificar si se han alcanzado los objetivos establecidos para la migración.

¿El nuevo software cumple con los requisitos?
¿Se han mejorado los procesos e infraestructuras de la empresa?
¿Se ha conseguido reducir los costes en TI?
¿Los usuarios se encuentran satisfechos con el nuevo sistema?

5.3.7. Planificación económica

Una estimación de costes se debe llevar a cabo para establecer qué inversiones y recursos van a ser necesarios. Las inversiones (dependiendo del trabajo a realizar) y el tiempo (dependiendo de la intensidad de trabajo) deben ser diferenciadas en este contexto. Los siguientes tipos de costes deben ser considerados cuando se planifican cada una de las tareas:

Costes de personal.
Costes materiales consumibles (como por ejemplo, costes de papel e impresión).
Costes de hardware (equipamiento a ser adquirido).
Costes de adquisición y compra de licencias (en caso de haberlas).
Costes de servicio, soporte y formación.
Costes varios (costes de desplazamientos, servicios externos, etc.).

5.4. Implantación

Ha llegado el momento de poner en práctica todo lo que se ha estado planificando, cuantos más recursos se hayan dedicado a la planificación del proyecto, menos incidencias se encontrarán a la hora de ponerlo en marcha y realizarlo. En este punto se debe empezar a ejecutar paso a paso todas las tareas planificadas, formación e implantación técnica.

5.4.1. Formación

Se llevarán a cabo las acciones de formación establecidas durante la planificación, cabe recordar que este es uno de los puntos importantes de la migración. Haber establecido un buen plan de formación ayudará a que la migración sea un éxito en todos sus aspectos.

Se recomienda la utilización de las herramientas "puente" previa a la implantación definitiva del nuevo sistema para evitar pérdidas de productividad.

Posteriormente a la migración, hay que formar al personal para que pueda realizar las tareas de su puesto de trabajo con el nuevo software. Gran cantidad del software es similar al que ya utilizan (navegadores web, aplicaciones ofimáticas) con lo que para estos casos sólo es necesario realizar tareas de formación para adaptarse a este software, explicándoles cuales son las pequeñas diferencias que puedan encontrar.

Es posible que haya software que sea completamente nuevo, por lo que es necesario realizar clases de formación para que los empleados comiencen a utilizar este software. Tenga en cuenta que debe incentivar esta formación, porque los usuarios del sistema generalmente se niegan al cambio.

¿Cómo realizar la formación?

Existen multitud de recursos para dar cursos de formación. Se pueden utilizar métodos tradicionales, como impartir clases dentro de la propia empresa o subcontratar esta formación externamente.

Estos métodos, aunque eficaces a la hora de formar a los empleados, suponen un gasto adicional en la empresa. Para minimizar este gasto, existen portales de formación que el propio empresario puede instalar en la intranet, de manera que los empleados no necesiten abandonar su puesto de trabajo para formarse.

Mientras dure la formación para habituarse a las nuevas herramientas de trabajo, es posible que haya una pérdida de rendimiento. Esto lo tenemos que tener en cuenta y es una de las consecuencias iniciales del cambio.

Entre el software disponible para realizar tareas de formación, destaca Moodle. Es un sistema de gestión de cursos de libre distribución (course management system CMS) que ayuda a los educadores a crear comunidades de aprendizaje en línea.

El acceso a la formación es muy importante. Algunos sitios permiten a los usuarios decidir por sí mismos si quieren asistir mientras que otros exigen la asistencia. La elección dependerá de la cultura de la empresa y de qué trate el curso de formación. Los manuales y la documentación general suelen estar sólo en inglés y esto podría causar problemas en algunos empleados. La traducción al idioma local podría considerarse como gastos de migración pero entonces aparece el problema de la traducción continuada de las actualizaciones.

La interfaz de usuario de OSS, en concreto, Gnome y KDE, permite elegir los idiomas pero la traducción puede no ser completa en algunos puntos del menú y las pantallas de ayuda son siempre en inglés. Gnome en particular tiene buenas facilidades de acceso para las personas con discapacidad visual. Y además no todas las aplicaciones tendrán pleno soporte de localización. Aunque todo esto está cambiando con rapidez y la estructura que permita el uso de un idioma que no sea el inglés está ahí por si la empresa quiere utilizarla.

5.4.2. Implantación técnica

En este tipo de proyectos es muy importante el buen desarrollo del plan de comunicaciones elaborado en el apartado anterior.

Hay ciertas reacciones típicas a los cambios en las prácticas laborales que habrá que afrontar:

Miedo a lo desconocido

El temor de que el CV pierda importancia

Saber es poder

5.4.3. Concejos de Implantación

Hay ciertas circunstancias que pueden hacer que la introducción del software libre sea más fácil.

Introducir nuevas aplicaciones en un entorno familiar

Muchas de las aplicaciones libres funcionarán con sistemas operativos propietarios y esto nos brinda la oportunidad de introducir estas aplicaciones sin tener que cambiar totalmente el entorno. Por ejemplo OpenOffice.org, Mozilla y Apache funcionarán con Windows y así pueden utilizarse en sustitución de Office, Internet Explorer e ISS respectivamente. Aparte de ser menos rupturista, este enfoque permite que la reacción del usuario pueda ser calibrada a pequeña escala y que los planes para la formación de los usuarios puedan hacerse sobre la base de la experiencia real. Además, problemas como la conversión de formatos de archivos, macros y plantillas se pueden facilitar si la antigua aplicación se mantiene disponible durante algún tiempo.

Este enfoque significa que la elección de la aplicación en el entorno final se va a ver limitada a las que trabajan en el actual. Por ejemplo, el navegador final puede ser otro, pero Mozilla es el único que funcionará tanto con Windows como con GNU/Linux.

Lo fácil primero

Los primeros cambios serán los que no afecten a la comunidad de usuarios. Eso quiere decir que los primeros cambios se harán en el servidor. Estos cambios van a proporcionar la plataforma para la posterior introducción de los cambios en el lado del cliente. Muchos de los cambios relativos al servidor serán compatibles con el entorno actual, con lo que se podrá minimizar el efecto de ruptura. Por ejemplo, los servidores de nombres DNS, los servidores DHCP y los servidores de bases de datos principales con bases de datos propietarias como Oracle podrían ser todos ellos candidatos a ser reemplazados por un sistema en software libre equivalente y seguir interactuando con el resto de los sistemas actuales como antes. Más adelante se hablará de esto en detalle.

Hay aplicaciones como Samba que no se usarían en un entorno de software libre puro, pero que permiten la coexistencia de los antiguos sistemas propietarios y el software libre. El uso temprano de éstas puede ser muy eficaz en la división de los entornos en partes manejables.

Mirar hacia adelante

Desarrollos web basados en estándares

Insistir en que los desarrollos web hechos tanto internamente como por contratistas produzca un contenido que se pueda visualizar en todos los navegadores actuales de la web, en particular los navegadores libres. Esta sería una buena práctica en cualquier caso ya que las empresas no deberían requerir software específico para visualizar su contenido. Hay herramientas web para validar si una web sigue perfectamente el estándar, como el W3C Validator para comprobar la compatibilidad de las páginas web.

Evitar las macros y los scripts

No fomentar el uso indiscriminado de macros y scripts en documentos y hojas de cálculo; encontrar otros modos de proporcionar la necesaria funcionalidad. Ésta también es una buena práctica ya que de forma habitual los virus se valen de las macros y los scripts para infectar los sistemas. Además, las macros se pueden usar fácilmente para robar datos y corromper documentos: por ejemplo, podrían hacer que el documento diga cosas diferentes dependiendo de quien lo esté visionando y que se imprima otra cosa.

Uso de formatos abiertos y estándar

Insistir en el uso de formatos de archivos abiertos y estándar, como PostScript y PDF. Hay cierta discusión sobre si PostScript y PDF son estándares abiertos o no. Es más una discusión sobre definiciones estrictas y en concreto sobre quién controla el estándar. En realidad, estos son los únicos formatos de archivos estándar que tienen un amplio uso en este momento, especificaciones públicamente accesibles y que se se pueden usar sin grandes restricciones.

Se están haciendo intentos para crear formatos de archivos estándar basados en XML y el Open Document Format (ODT) es un ejemplo. Sin embargo, sólo porque un archivo esté basado en XML ello no significa que vaya a ser abierto. En particular, no se deben usar formatos de archivos propietarios para archivos que son solamente para lectura y que el receptor no los va a editar. También en este caso sería una buena práctica, pues dichos archivos son una forma corriente de difundir virus. Usar esos formatos propietarios significa que la empresa se verá atrapada por el vendedor del software propietario durante bastante tiempo. Esos formatos propietarios también pueden incluir grandes cantidades de metadatos como, por ejemplo, texto previamente borrado, que si otros pueden visionar sería embarazoso para la empresa. Visualizar estos metadatos no es nada difícil.

Al escribir documentos en colaboración con otros, usar el formato que sea mínimo común denominador. Por ejemplo, hacer uso del formato Word 97 en lugar de Word 2000. Esto aumentará la posibilidad de que las aplicaciones libres puedan interactuar con el documento.

Usar protocolos abiertos y estándar

Utilizar protocolos abiertos estándar. Los protocolos abiertos estándar se definen como los que están libres patentes y cuentan con una implantación de software libre.

Desarrollar aplicaciones en 3 capas

Desarrollar sistemas basados en por lo menos un modelo de tres niveles donde el código de aplicación es independiente de la interfaz humana y de los métodos de acceso a los datos. Por ejemplo, si es posible, tener una interfaz de navegador que se pueda usar en un navegador web libre. Construir aplicaciones de esta forma modular facilitará hacer la migración bit a bit. Esto no sólo reducirá la escala de cualquier fase de migración sino que también reducirá el riesgo de fallo. Las tradicionales aplicaciones monolíticas de cliente son notablemente difíciles de manejar.

Utilizar tecnologías multiplataforma

Insistir en que las nuevas aplicaciones que necesite la empresa se escriban de manera que se sean portables. Esto incluye el usar lenguajes estandarizados portables como ANSI C, Java, Python y Perl, y usar sólo librerías multiplataforma y librerías de construcción de interfaces (GUI Toolkits) portables. Evitar lenguajes y APIs de arquitecturas específicas. Evitar la construcción de aplicaciones que requieran la presencia de otras aplicaciones propietarias.

5.5. Evaluación

Ejecutar el plan de evaluación y continuar monitorizando el sistema en el tiempo identificando carencias o mejoras para incrementar paulatinamente la calidad del sistema de información de la empresa.

Para evaluar si la migración ha tenido éxito, podemos valorar los siguientes puntos:

¿Se ha migrado el Sistema Operativo de manera satisfactoria?

Es decir, el nuevo sistema operativo funciona, da al menos los mismos servicios que el sistema anterior, y además lo hace de forma correcta. En caso de detectarse algún error en alguno de estos puntos, debemos revisar qué ha fallado en la migración.

Evidentemente, habrá casos en los que técnicamente no ha podido darse la migración del sistema, debido, generalmente a problemas con aplicaciones que sólo funcionen en el sistema anterior a la migración y que no puedan hacerse funcionar con los emuladores y las máquinas virtuales, como ya comentamos recientemente.

¿Se han migrado las aplicaciones?

Se tiene que valorar si se utilizan las mismas aplicaciones o alguna de sus alternativas, si no hay limitación de características por usar software libre, es decir, que al menos las aplicaciones ofrezcan la misma (o parecida) funcionalidad a las que se utilizaban anteriormente. En caso de que la aplicación cumpla con este requisito, se puede considerar un éxito.

Desafortunadamente, existen multitud de aplicaciones propietarias o desarrolladas por las mismas empresas que no van a poder ser migradas al nuevo sistema. Para ello tendremos que adaptar el software al nuevo sistema, o adaptar el sistema al software (como en el punto anterior, hay que realizar pruebas con emuladores y virtualizadores).

¿Se han adaptado los usuarios?

¿Cómo trabajan los usuarios? ¿En qué medida han mejorado/disminuido su productividad? Este es un punto clave, ya que pese a que normalmente la productividad decaiga inicialmente, esta variable debe estudiarse a más largo plazo. Como siempre, no sólo dependerá de lo fácil que sea la transición al nuevo software, sino también de la predisposición al cambio que los empleados tengan.

¿Se ha mejorado con el cambio?

Hay que valorar también si el cambio ha mejorado en algún aspecto respecto al anterior sistema, es decir, si ahora se pueden ofrecer servicios que antes no se podía o aplicaciones a las que no se podía acceder. Generalmente, los administradores de servicios ganarán con el cambio, ya que el sistema de acceso remoto y administración de un sistema GNU/Linux es mucho más potente y flexible que uno en un entorno Microsoft Windows. Los costes de mantenimiento se reducen, los costes de licencia también, e incluso los costes de actualización del hardware.

6. Conclusiones

Como ven en los temas que se trataron en el presente curso, muestra desde la definición misma del software libre, hasta los aspectos necesarios en la migración hacia el mismo.

Como un apoyo de todo esto se adjunta toda la documentación realizada para este fin en los siguientes enlaces:

La proxima semana iniciamos con las evaluaciones que se realizaran por partes, ante cualquier comentario y/o consulta estoy a sus ordenes.

Blog sobre la Migracion al Software Libre

domingo, 31 de agosto de 2014

Migrando hacia el Software Libre