Con la crísis económica actual, muchos entusiastas del software libre que gustan de realizar actividades de evangelización ven una oportunidad para promover el uso de software libre en empresas y otras instituciones (escuelas por ejemplo). Está bien que promovamos el uso del software libre (independientemente de que haya crísis o no), pero antes de alentar a una empresa o institución a migrar de software privativo a software libre, debemos tener en cuenta los siguientes puntos:
1. Que los dueños, directivos, etc. tengan bien claro el concepto de software libre
Es importante que los dueños de la empresa, etc. tengan bien claro que software libre no significa necesariamente software grátis (aunque la mayoría del software libre sea además software grátis). Si la única motivación de los dueños para migrar a software libre es porque instalando alguna distribución de GNU/Linux (de las que son grátis) y OpenOffice en sus equipos se van a ahorrar el costo de las licencias del sistema operativo y la suite de oficina que usan actualmente, entónces ese proyecto tiene 90% (o más) probabilidades de fracasar.
Las verdaderas ventajas de migrar a software libre son la independencia tecnológica, la seguridad, estabilidad, etc. que el software libre ofrece. Debe quedarles bien claro a los dueños que el software libre no es cuestión de precio, sino de libertad.
Si es posible, también se debe capacitar a los usuarios finales sobre los conceptos de software libre, para que lo conozcan, comprendan la decisión de la empresa de hacer la migración y se vayan sintiendo parte del proyecto.
2. Tener un plan para capacitar a los usuarios en el software que se va a instalar
Si pretendemos instalar por ejemplo Ubuntu en todas las máquinas de los usuarios de un dia para otro y esperar que solitos sepan como usarlo definitivamente somos muy ingenuos y eso va a ser un caos y van a empezar a llover las quejas de los usuarios.
La capacitación debe ser obligatoria para «todos» los empleados que usen una PC en la empresa, debe ser por fases y en grupos relativamente pequeños, de preferencia va a tener que hacerse en su horario normal ya que no van a estar dispuestos a quedarse tiempo extra por tener que asistir a la capacitación, eso ya de entrada va a generar una resistencia al proyecto por parte de los usuarios.
3. Los dueños deben estar 100% convencidos y apoyar el proyecto
A los usuarios finales normalmente no les agrada el cambio, ellos aplican la ley del menor esfuerzo, parece que sus pensamientos son algo asi como:
«Si OpenOffice me ofrece ventajas sobre la suite de oficina que uso actualmente pero no se usa «exactamente igual» entónces prefiero no usarla. Es decir, si tengo que invertir tiempo y esfuerzo porque hay una pequeña curva de aprendizaje, por mínimo que este sea, no estoy dispuesto a hacerlo.»
Con esta actitud, al quitarles a los usuarios su suite de oficina a la que están acostumbrados e instalarles OpenOffice, los usuarios siempre buscan pretextos para ser menos productivos echandole la culpa al nuevo software, es decir, no pude terminar a tiempo la hoja de cálculo de x cosa porque no supe como hacer esto que en el otro programa se hacía asi. Es ahí en donde se requiere la interveción de los directivos para transmitir a los usuarios de una manera firme, para que no haya dudas, de que es una decisión tomada y no hay marcha atras, que se requiere de su apoyo ya que esto va a traer beneficios en el mediano y largo plazo; yo agregaría definitivamente que el que no esté dispuesto a brindar el apoyo que se les solicita no cumple el perfíl de empleado que la empresa necesita y por lo tanto la empresa tendrá que buscar otra persona que ocupe su lugar, aunque bueno, esto ya dependerá si quieren correr el riesgo de que les boicoteen el proyecto o si quieren estar aguantando caprichos de los usuarios (el clásico ejemplo «es que en el otro programa el botón era de color azul y aquí es naranja» o, «en el otro programa la opción tal estaba en tal menú y aquí esta en otro, por eso no le entiendo, me cuesta trabajo»)
4. Hacer un análisis para determinar el software que se va instalar en cada caso
Dependiendo del tamaño de la empresa, el número de equipos, las aplicaciones que usa y sus nececidades, se determinará que sistema operativo se instalará en los servidores y que sistema operativo en las máquinas de escritorio. Por ejemplo, en una empresa se puede llegar a la conclusión que para su servidor de correo se va a instalar FreeBSD, a las secretarias se les va a instalar Ubuntu y a las portátiles de la fuerza de ventas se les va a instalar otra distribución de GNU/Linux; y en otra empresa talvez se decida que todos los equipos van a tener instalado Linux Mint.
5. Hacer la migración por fases
Lo mas recomendable es empezar migrando lo que podamos migrar sin afectar al usuario final, por ejemplo, si la empresa tiene un servidor de correo que usa software privativo, migrar ese servidor a software libre de tal manera que sea transparente para el usuario, es decir, el usuario ni cuenta se va a dar de que ya no es el mismo software el encargado de hacer el envio y recepción de sus correos.
Si la aplicación de software libre que se va a utilizar para x cosa tiene una versión para el sistema operativo que actualmente se usa en la empresa, instalar esa versión sobre ese sistema operativo (después de la capacitación sobre la misma desde luego) y una vez que los usuarios estén cómodos usando todas las aplicaciones que estén en este caso, ya migrar el sistema operativo, así el cambio no es tan brusco.
Por ejemplo, si el sistema operativo que usan los usuaarios finales es Microsoft XP y la suite de oficina es Microsoft Office y se decidió que se va a usar como suite de oficina OpenOffice y como sistema operativo Ubuntu, primero instalarles a los usuarios la versión de OpenOffice para windows y una vez que se hayan acostumbrado a usar OpenOffice y se sientan cómodos trabajando con el, ya migrar el sistema operativo (de XP a Ubuntu en este caso) y no van a sentir diferencia al usar OpenOffice sobre Ubuntu debido a que ya lo venían usando, sólo que sobre Windows.
Si no tomamos en cuenta estos puntos, probablemente el proyecto fracase y tanto los dueños como los usuarios de la empresa se queden con la impresión de que el software libre no funciona, es difícil de usar, etc. Cuando en realidad la culpa fue nuestra ya que insistimos en hacer un proyecto de migración en un lugar en donde no se tenían las condiciones para hacerlo.
Por esto, antes de hacer una migración, se debe concientizar a los dueños que tienen que poner de su parte y hacer que sus empleados pongan de su parte también, si no es así, mejor no iniciar la migración, ya que sería un proyecto destinado al fracaso.
Código Fuente 