Cinco problemas de código abierto y cómo manejarlos

1. No conocer sus fuentes

La facilidad de obtener y usar código abierto es una gran parte de su atractivo, pero también puede causar dolores de cabeza a los ejecutivos de TI que no desarrollan y aplican políticas sólidas sobre cuándo y qué fuente abierta está permitida para uso empresarial.

"La mayoría de las compañías realmente no saben qué fuente abierta están usando hoy, y eso es un problema", dijo Paul Chandler, abogado de la firma internacional de abogados Mayer Brown. "Si no sabe qué fuente abierta tiene en su ecosistema o cartera de productos, ¿cómo sabe qué vulnerabilidades podría tener y qué parches buscar?".

Él dijo que los CIO deberían emplear herramientas de escaneo para encontrar el código de fuente abierta que se ejecuta en sus organizaciones. Esto incluye solicitar a sus proveedores de software comercial que revelen cualquier código de fuente abierta utilizado en sus productos, y exigir que dichos proveedores asuman los riesgos y la responsabilidad asociados con la fuente abierta.

"Los contratos de compras tienen que considerar el código abierto y deben anticipar que los productos de código abierto vendrán a través de productos comerciales y proporcionar protección para la compañía contra los riesgos", dijo Chandler.

Además, dijo que los CIO deberían crear una estrategia que establezca cuándo se puede usar el software de código abierto y bajo qué circunstancias. El programa debe tener formas de examinar el código abierto por cuestiones de seguridad y preocupacioens de licencias basadas en las necesidades de la empresa y debe establecer sistemas de gobierno que determinen quién es responsable de administrar y mantener el OSS dentro de la empresa.

2. Pasar por alto las reglas y los requisitos de licencia

La Open Source Initiative, una organización sin fines de lucro que promueve el software de código abierto, enumera las aproximadamente 80 licencias de código abierto que ha aprobado, todas las cuales vienen con reglas y requisitos individuales. Las organizaciones que utilizan OSS deben comprender qué significan para ellos las reglas y los requisitos de las licencias.

"A pesar de que el código abierto es gratuito, viene con muchos compromisos", dijo Robert Kriss, socio de Mayer Brown, cuya práctica se centra en parte en resolver conflictos relacionados con la externalización de TI, el desarrollo de software, la ciberseguridad y el comercio electrónico.

Estos requisitos de licencia pueden ser técnicamente complejos; algunas licencias requieren que los desarrolladores compartan cualquier cambio que realicen en el código fuente, mientras que otras no lo hacen. Algunas tienen restricciones de represalias de patentes. Otras afectan si el software de código abierto se puede utilizar en productos para venta comercial. Además, los desarrolladores que utilizan más de un OSS en un producto podrían encontrar que los términos de licencia para un componente de código abierto contradicen los términos de licencia asociados con otro.

"Las empresas tienen verdaderos dolores de cabeza al tratar de cumplir con los términos de la licencia, en parte porque los términos no siempre son claros", dijo Kriss. "Pero la conclusión es que existen riesgos dependiendo del lenguaje de las licencias y usted tiene que leer las licencias para saber qué riesgos corre".

3. Subestimar el costo del software de código abierto

Un atractivo importante de OSS es adquirir un código sin pagarle a nadie por ello. Pero la ausencia de una factura de un proveedor no significa que el código abierto llegue sin costos.

Mark Driver, vicepresidente y director de investigación de Gartner, dijo que las organizaciones a menudo no calculan el costo total de propiedad del software de código abierto que optan por usar.

Además, las organizaciones subestiman el compromiso de tiempo necesario para que el personal mantenga el código de fuente abierta y administre cualquier problema de software de fuente abierta.

"Muchas organizaciones elegirán la ruta no comercial porque creen que están obteniendo la mayor inversión posible, pensando que solo van a utilizar recursos internos para realizar el [trabajo de mantenimiento] diario", dijo Driver. "Pero es muy fácil ofuscar o perder la capacidad de saber realmente cuánto se está gastando cuando solo es tiempo de la gente".

Para evitar esto, Driver dijo que TI necesita establecer los niveles de servicio requeridos para el código de fuente abierta utilizado en las aplicaciones, teniendo en cuenta qué tan críticas son esas aplicaciones.

Con eso, TI puede determinar el costo de soportar adecuadamente el código fuente abierto, los costos relacionados con las fallas potenciales de las aplicaciones asociadas con ese código y si ese costo neto supera las alternativas comerciales.

"Estamos empezando a ver un entusiasmo desenfrenado por el código abierto, pero no es así como se maneja un negocio. Hay que mirar seriamente su valor", dijo Driver.

4. Escatimar en usabilidad

Los desarrolladores están utilizando OSS para entregar rápidamente las funciones y características exigidas por los usuarios en sus aplicaciones, pero Michael Fauscette, director de investigación de G2 Crowd Inc., dijo que los desarrolladores deben considerar si el código abierto ofrece el mismo nivel de usabilidad que un producto comercial.

Los problemas de usabilidad son una preocupación mayor cuando una empresa opta por un producto de código abierto en lugar de usar código de código abierto como parte del desarrollo de un producto terminado, explicó. Sin embargo, incluso cuando el software de código abierto es solo una parte de una aplicación más grande, puede hacer que una característica o función particular sea mucho menos fácil de usar.

Los desarrolladores no tienen que renunciar automáticamente a la opción de código abierto en esos casos, dijo Fauscette, pero deberían evaluar si los beneficios del código abierto son mayores que la capacidad de uso limitada. "Hay mucha menos tolerancia por parte de los empleados hoy en día para usar algo que no es fácil de usar", agregó.

5. No gestionar y mantener la cartera de código abierto

El código abierto no tiene un proveedor principal que libere actualizaciones de software o aplique parches al sistema. Teóricamente, los desarrolladores experimentados saben que están enganchados a buscar actualizaciones del software de código abierto que tienen en producción, pero a menudo no lo hacen.

"Los activos de código abierto tienden a no ser administrados en las carteras de TI", dijo Driver.

Los ejecutivos de tecnología necesitan implementar programas de gobierno que aseguren que sus equipos gestionen adecuadamente el OSS que están ejecutando. Ese programa debe incluir un proceso para buscar, revisar y probar las actualizaciones de software para determinar si son seguras y funcionarán en el entorno empresarial.

Driver dijo que aconseja a los líderes tecnológicos que establezcan un sistema de administración de múltiples niveles, con los OSS que se ejecutan en aplicaciones de misión crítica obteniendo el nivel de servicio más riguroso.

Aunque es una tarea desalentadora, eludir la administración de problemas del software de código abierto puede ser catastrófico. Welty señaló la brecha de datos de Equifax de 2017, donde Equifax reconoció que los hackers explotaron una vulnerabilidad conocida en un código de fuente abierta, una vulnerabilidad que Apache Software Foundation ya había identificado y había ofrecido un parche para corregir.

"Debe tener un proceso para monitorear y traer actualizaciones", dijo Welty, y agregó que el proceso de administración debe incorporar el hecho de que las actualizaciones de fuente abierta y los parches vienen en un horario irregular y deben abordarse de manera rápida y constante.