Aquellos convertidos a software de origen libre en los últimos 10 años se encuentran entre los primeros adoptantes de Roger (1983). Si el modelo de Roger (1983) es válido para los movimientos de código abierto y software libre, deberíamos esperar un rápido repunte en la adopción a medida que entramos en las fases de adopción de mayoría temprana a mayoría tardía. La rapidez con la que esto sucederá puede explicarse más fácilmente a través del Modelo de Aceptación Tecnológica (TAM) que analiza cómo las percepciones sobre la facilidad de uso y la utilidad de una tecnología afectan la adopción a lo largo del tiempo (Davis, 1989). Otro factor que afectará la aceptación es la simple conciencia y conocimiento del software de código abierto y libre. Potter (2000) cita algunas preocupaciones que las personas tenían con respecto a las solicitudes de origen libre que se relacionan con el TAM de Davis (1989):
- preocupaciones del producto: viabilidad del producto y cuestiones técnicas tales como seguridad, escalabilidad y soporte técnico;
- preocupaciones contractuales: un contrato de compra que se firma con una empresa que no creó el producto adquirido; minimización de los derechos de autor para los programadores;
- preocupaciones de soporte de productos: incomodidad de las compañías de software al proporcionar garantías para productos que no crearon; antecedentes cortos y poder de permanencia desconocido de pequeñas empresas de software nuevas con respecto a la provisión de soporte de productos a largo plazo;
- preocupaciones de estandarización de productos: debido a la naturaleza colaborativa del código fuente, la funcionalidad, las mejoras y las alteraciones de la aplicación pueden agregarse a voluntad y comercializarse como versiones diferentes o más nuevas del programa, por lo que “La multiplicidad de productos y versiones puede resultar en sistemas incompatibles y productos inconsistentes”.
Si bien la preocupación de Potter (2000) por las alteraciones de la aplicación o la proliferación de versiones puede parecer preocupante, una vez que un programa de origen libre se está ejecutando en su sistema, bajo su administración, solo las personas que usted (o los administradores de su sistema) designen tienen permiso para acceder y modificar el código fuente. Si quieres cambiar a una versión más nueva, eres libre de hacerlo, pero no estás obligado a hacerlo. Nadie más podrá jugar con el código que ha instalado en su hardware a menos que se le otorgue dicho permiso y nadie podrá obligarle a actualizar a través de obligaciones contractuales o de licencia. Esto no quiere decir que un programador sin escrúpulos no pudiera ocultar algo en el código fuente para permitirle entrar y modificar el programa sin tu conocimiento, pero eso es muy poco probable si has seleccionado un programa de buena reputación con comunidades robustas de usuarios y programadores. En estas comunidades, las personas constantemente escudriñan el código. Tales temas serían descubiertos rápidamente y el programa se pandeaba en reseñas, blogs u otros formatos.
Otra barrera para la adopción puede ser la portabilidad percibida de los datos del software existente a una opción de fuente libre. A menudo muchas de las dificultades para migrar los datos de un instructor o institución a una nueva plataforma se atribuyen al software, y en un momento eso fue cierto. En el pasado, los programas comerciales patentados aseguraban la portabilidad del contenido entre sus versiones, con poca referencia a otras. Por ejemplo, con respecto a las plataformas de aprendizaje, muchas instituciones desarrollaron cursos, medios o datos sin referencia al diseño de documentos o etiquetado de datos, quizás nunca imaginando que contemplarían la migración a un proveedor de software diferente. Un curso diseñado por un instructor a menudo era significativamente diferente en estructura del diseñado por otro. Los materiales mostraron poca consistencia en el diseño o el diseño.12 Desde el movimiento de estándares, los temas de portabilidad e interoperabilidad se han convertido en consideraciones centrales a la hora de seleccionar software. En consecuencia, el diseño y la maquetación consistentes del curso han cobrado importancia en el entorno educativo. Con mayor frecuencia, los instructores u otros desarrolladores están siendo capacitados en formas de construir cursos que cumplan con los estándares. Es mucho más fácil construir un programa de software para mover el contenido a un nuevo entorno cuando las partes son comunes, correctamente identificadas y en ubicaciones similares. Incluso si no tiene la experiencia tecnológica dentro de su institución para construir el software de migración necesario, con cumplimiento estándar, buen diseño y previsión desde el principio, ese proceso puede ser subcontratado por un precio razonable.
Estos no son los únicos obstáculos para el software libre y abierto, otras amenazas se ciernen. Recientemente se han producido movimientos en marcha para prohibir efectiva y legalmente la ingeniería inversa del software. Potter (2000) analiza los recientes borradores de la Ley Uniforme de Transacciones de Información Informática (UCITA) diciendo:
Actualmente, la ingeniería inversa es legal por razones de “interoperabilidad” entre sistemas informáticos. Prohibir la ingeniería inversa inhibe el desarrollo de código abierto [y software libre] porque para que los productos... [software de origen libre] sean de cualquier valor, deben ser compatibles con otras aplicaciones informáticas. La forma de establecer la compatibilidad es realizar ingeniería inversa en el código del otro desarrollador... a los defensores les preocupa que la UCITA permita a los desarrolladores propietarios “establecer formatos y protocolos de archivo secretos, que no habría forma legal para que [los programadores] averigüen”.
Además Potter (2000), identificó problemas con los borradores legales de la UCITA que afianzarían las garantías implícitas en las licencias de software. Tradicionalmente, el software de origen libre no proporciona garantías a menos que se especifique expresamente por un individuo o compañía. Esto ha sido un beneficio ya que disminuye el riesgo de demandas. En consecuencia, esto crea barreras de entrada bajas para nuevos diseñadores de software y empresas. Sin requisitos previos de seguro o representación legal para limitar la responsabilidad, cualquier persona y cada uno puede contribuir a la programación del software. Potter (2000) afirma, “Colocar el riesgo de litigio en el desarrollador de código abierto [o software libre] puede a su vez aumentar el precio de... productos. Otra consecuencia negativa es la posible disuasión de los programadores de aportar código útil”.
Desde el fin del control del mercado de Unix, otra barrera importante para el software de origen libre ha sido la dominación de Microsoft. C. DiBona et al. (1992) escriben: “La pregunta realmente no es si el financiamiento de capital de riesgo fluirá hacia Open Source, sino por qué el flujo solo ha comenzado a gotear en esa dirección... ¿Por qué tardó tanto en ponerse al día?” (p. 10). Pasan a responder a esta pregunta:
Echando un vistazo al panorama informático, tienes una situación en la que una empresa muy grande con bolsillos muy profundos controla la mayor parte del mercado comercial. En Silicon Valley, los vendedores esperanzados de aplicaciones que buscan respaldo de la comunidad de ángeles y capital de riesgo aprenden muy rápidamente que si se posicionan contra Microsoft, no van a ser financiados. Cada startup tiene que jugar al juego de Microsoft o no jugar en absoluto. (C. DiBona et al., 1992, p. 10)
Según DiBona et al. (1992), los programadores obligados a jugar el juego de Microsoft están encerrados en el objetivo de asegurar la naturaleza propietaria de su trabajo, “el objetivo de hacer que el programa dependa completamente de las bibliotecas de Microsoft... haciendo que cualquier programa nativo de Windows sea muy difícil de portar a otros operativos sistemas” (p. 10). El autor también señala que una de las principales razones por las que Microsoft no ha dominado Internet ha sido la dedicación de la Red a “una poderosa colección de estándares abiertos mantenidos sobre el mérito de la participación individual, no el poder de una billetera corporativa” (C. DiBona et al., 1992, p. 10). Los autores señalan, que al igual que Internet, los desarrolladores libres y de código abierto “compiten en base a estándares abiertos y código compartido” y generalmente trabajan hacia la compatibilidad (C. DiBona et al., 1992, p. 10). Recientemente, parece que los movimientos de origen libre han afectado incluso a las estrategias de Microsoft. En septiembre de 2006, Microsoft prometió “no hacer cumplir las patentes de tecnología en especificaciones de servicios web, que se utilizan para conectar aplicaciones en arquitecturas orientadas a servicios y otras formas de computación distribuida basada en estándares” (Gonsalves, 2006). Gonsalves (2006) continúa diciendo que esto se hizo en un esfuerzo por parte de Microsoft “[para] ayudar a promover la adopción generalizada de los servicios web, que juegan un papel importante en la forma en que Microsoft relaciona su software con sus propios productos y otras aplicaciones” al dirigirse a “desarrolladores y clientes que trabajan con comerciales o abiertos- software fuente [/libre].”
Si bien la construcción de la comunidad y las relaciones interpersonales han sido un factor significativo en el éxito del software de origen libre, otros aspectos ayudan a impulsar su creciente aceptación. Potter (2000) dijo:
Económicamente, el código abierto [/software libre] es una forma más eficiente de asignar los beneficios del derecho de autor a la sociedad. Debido a que la ley actual de protección de software beneficia a relativamente pocos desarrolladores, hay una necesidad de cambio. El código abierto [/software libre] exhibe alternativas válidas, económicas y comercializables al desarrollo y distribución de software propietario.
Estas razones enumeradas por Potter (2000) hacen del software de código abierto y libre una opción cada vez más popular. Por ejemplo, el servidor Apache, una aplicación de código abierto con más de 11 años en la industria, ahora es utilizada por más del 62 por ciento de los mejores desarrolladores de la industria de servidores. En comparación, Microsoft tiene menos de la mitad de la cuota de mercado en aproximadamente el 30 por ciento (Netcraft, Ltd., 2006). La cuota de mercado de Apache aumentó desde su estimación de febrero de 2002 en poco más del 58 por ciento (Netcraft, Ltd., 2002). Además, el interés por otro software de código abierto y libre está creciendo. Un artículo de marzo de 2005, “Estimar el número de usuarios de Linux (o: por qué pensamos que somos 29 millones)” hizo una revisión de los éxitos de Internet en febrero de 2005 registrados por Teoma y Google (combinados). Los resultados se resumen en la Tabla 8.1, Open Source vs Windows Interest by Internet Hits.
| Sistema Operativo |
Éxitos |
| Linux + linspire |
269,000,000 |
| Solaris |
27, 000,000 |
| *BSD |
55, 000,000 |
| Total de fuentes libres |
351,000,000 |
| Win3.1/95/98/2000/ME |
88, 000,000 |
| Win2003/Servidor |
19, 000,000 |
| WinXP |
33, 000,000 |
| WinNT |
33, 000,000 |
| WinLongHorn |
33, 000,000 |
| Total de Ventanas |
206,000,000 |
Claramente, hay evidencia de un interés significativo en el software de código abierto y libre, si solo se mide a un nivel superficial por el interés del sistema operativo o los éxitos del sitio web.
Según Fima Katz, directora general de Exadel, “El verdadero problema es la desfamiliaridad generalizada y la falta de experiencia con el código abierto [y el software libre] en todos los niveles de la organización” (V world New Media [Designs4Nuke.com], 7 de febrero de 2006). Una encuesta de Exadel realizada en la Cumbre de Código Abierto de Gartner 2005 encontró que “más de la mitad (55%) de los encuestados informaron que sus organizaciones actualmente tienen un conocimiento interno limitado de código abierto [/software libre]” (como se cita en V world New Media [Designs4nuke.com], 7 de febrero de 2006). Además, el informe Gartner del 23 de febrero de 2005, “Posiciones 2005: Las soluciones de código abierto reestructurarán la industria del software”, encontró que “el 40 por ciento de los encuestados afirmó que el desconocimiento de su organización sobre el software libre [/software libre] es la principal vulnerabilidad a la adopción” (como se cita en V Mundo New Media [Designs4nuke.com], 7 de febrero de 2006).
A pesar de las diversas barreras, las tendencias actuales indican que el software de origen libre florecerá, como testigo de la proliferación de servidores Apache, sistemas operativos GNU/Linux, así como sitios ATutor, Sakai y Moodle, Para asegurar esto, Potter (2000) ofrece las siguientes sugerencias: formación de una organización sin fines de lucro y/ u organismo gubernamental para certificar la interoperabilidad y portabilidad de software de origen libre; usar código de software de origen libre como recurso legal para demandas de monopolio, antimonopolio y derechos de autor; así como el respaldo gubernamental de software de origen libre a través de sus propias políticas, adopción y uso.
La pregunta entonces es: ¿cuándo, si alguna vez, es el momento adecuado para migrar a software de origen libre? Sólo una evaluación contextual integral de su situación, así como aumentar sus conocimientos de software libre y código abierto, puede ayudarle a tomar esa decisión. Las siguientes secciones ofrecen una posible metodología para aumentar sus conocimientos, y pasar de consideraciones iniciales de opciones de origen libre a la implementación de proyectos piloto y la adopción organizacional generalizada.
