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.