El Costo Oculto del Software de Código Abierto

Gracias. Hola a todos. Soy Aaron Mitchell, presidente de HeroDevs, y hoy voy a hablar sobre los costos ocultos del software de código abierto y también vamos a hablar un poco sobre la planificación patrimonial para su conjunto de código abierto.

Pero primero, vamos a contar una historia. Así que hace unos siete años, comencé una empresa. Se llamaba Freeplay, y era una aplicación móvil de fitness que usarías para hacer que sea muy fácil hacer ejercicio con tus amigos. Y unos años después de Freeplay, decidimos que íbamos a comenzar, íbamos a cambiar nuestro modelo de precios. Así que enviamos todos estos correos electrónicos a nuestros socios, a nuestros clientes, actualizamos nuestro sitio web. Hicimos todos estos cambios en la aplicación. Y unos días antes de que estuviéramos listos para implementar los cambios, intentamos enviar a la tienda de aplicaciones y la tienda de aplicaciones rechazó nuestra solicitud porque estábamos en una versión no compatible de Xcode y React Native con la que ya no podíamos enviar. Así que terminamos teniendo que retroceder con todos nuestros socios, todos nuestros clientes con la cola entre las piernas y retrasar el cambio de precios durante las próximas ocho semanas mientras nos enfocamos en actualizar y testing nuestro software y llegar a la última versión para poder enviar nuevamente.

Y fue entonces cuando me di cuenta de algo como fundador y CEO de una startup. Cuando mis ingenieros vinieron a mí y me presentaron, hey, aquí está el conjunto de tecnologías que vamos a usar para desarrollar esta aplicación, dijeron que la mejor parte de esto es que todo este software es gratuito. Así que pensé, está bien. Gratis es genial. Me gusta lo gratis. Así que vamos a hacerlo. Lo que no me dijeron fue que si bien es gratuito, simplemente tienes que pasar mucho tiempo actualizando y testing y volviendo a actualizar y volver a probar el software. Y si no actualizas, podrías terminar pagando una actualización muy costosa que llega unos meses o unos años después. Y como hombre de negocios, eso fue muy diferente a cualquier otro software de pago que estaba usando. Así que me planteó una pregunta, que era si tenemos algún tipo de política de actualización o fin de vida del software de código abierto.

Estuve en gestión de productos durante seis años en mi career antes de comenzar FreePlay. Y recuerdo muy vívidamente nuestras reuniones de planificación de sprint donde acabábamos de pasar por todas las historias y todo para este sprint estaba listo. Estábamos listos para comenzar. Y siempre al final, un ingeniero levantaba la mano y decía, por cierto, esa biblioteca que estamos usando necesita ser actualizada. Y como gerente de producto, tengo una hoja de ruta que debo cumplir. Y la actualización no está en la hoja de ruta. Así que miento y les digo que lo agregaremos al próximo sprint. Y luego llega el próximo sprint y mágicamente no está allí. Y no recuerdo la conversación en absoluto.

Este es el manual de los gerentes de producto, por cierto, comprometerse, no hacer nada, desviar la atención y luego repetir. Entonces, si acabo de describir una conversación que has tenido o tal vez estás teniendo actualmente en tu empresa, no estás solo. Los equipos que trabajan en bases de código compartidas hacen que este problema sea aún más difícil porque nadie quiere pagar la factura. Nadie quiere ser el equipo que actualiza para todos los demás. Pero la mayoría de las empresas no tienen una política formal de fin de vida para su conjunto de código abierto. Y esto plantea la pregunta, entonces, ¿qué es una buena política de fin de vida, una política de actualización? ¿Cómo se ve? Así que hoy vamos a ver brevemente cómo establecer una buena política de fin de vida para su conjunto de código abierto. Y hay cinco pasos que voy a explicar muy rápidamente aquí. El primer paso es establecer un equipo y una frecuencia de revisión para monitorear sus necesidades de código abierto. Lo segundo es obtener un inventario del código abierto que está utilizando en su conjunto actualmente. Luego clasifique el inventario por criticidad para su conjunto. Identifique las fechas clave para cada una de las bibliotecas críticas. Y luego evalúe los eventos y esboce un plan para abordar cada actualización a medida que ocurran. Así que profundicemos un poco más.

El primer paso, establecer un equipo y una frecuencia de revisión. Algunos roles que es posible que desee incluir al pensar en quién debe formar parte de este equipo que verificará nuestra política de fin de vida y elaborará nuestra política de fin de vida. Debe incluir a un miembro del equipo de seguridad si lo tiene. Incluya a un miembro del equipo de control de calidad, a alguien de su equipo de ingeniería e idealmente a alguien de su equipo de producto que pueda ayudar a monitorear y evaluar los pros y los contras en función de la hoja de ruta empresarial que se ha comunicado. En segundo lugar, desde una perspectiva de frecuencia, generalmente recomendamos realizar una reunión mensual o trimestral con este equipo. De acuerdo. Paso dos. Tenemos el equipo reunido. Tenemos nuestra frecuencia establecida. Ahora queremos obtener un inventario de nuestro código abierto. Esta es una versión muy básica de cómo podría verse un inventario. Puede utilizar herramientas de escaneo de inventario disponibles de forma gratuita en la web, o también puede realizar una encuesta interna para identificar el software que se utiliza en su empresa. Debe tomar nota de cuál es la versión más actual de estas aplicaciones que hemos implementado o de estos paquetes de software que hemos implementado, y en qué versión estamos actualmente. Y luego es bueno tener una breve descripción para las personas que pueden no estar familiarizadas con lo que hacen estas bibliotecas. Lo tercero que queremos hacer es clasificar nuestras bibliotecas por criticidad. No queremos intentar abarcarlo todo. Muchas empresas tienen más de 100 bibliotecas o más que están utilizando de código abierto, por lo que algunos criterios que puede tener en cuenta al clasificar estos paquetes de software de código abierto son:

¿Cuál es tu área de superficie de riesgo si se descubre una vulnerabilidad crítica en este paquete? ¿Cuántos desarrolladores están utilizando esta biblioteca? ¿Cuántas dependencias tengo en esta biblioteca? ¿Y cuál es el impacto comercial si la biblioteca ya no estuviera disponible?

Bien, ahora hemos realizado un inventario, lo hemos clasificado por criticidad, ahora lo que queremos hacer es identificar las fechas clave de fin de soporte para esta biblioteca. No lo he incluido aquí, pero es posible que también desee saber cuándo se envió la última versión para saber en qué punto del ciclo de lanzamiento nos encontramos. Puede obtener data sobre las fechas de fin de vida de gran parte de su conjunto de software en endoflife.date. Es un sitio web gratuito al que puede acceder. Tienen una base de datos muy buena de bibliotecas y fechas de fin de vida. Básicamente, esto es lo que desea ver, y luego puede ver aquí que tenemos Vue.js el 31 de diciembre de 2023, como fin de vida para la versión 2.0 o 2.6, o 2.0 en adelante. Otras bibliotecas que pueden estar alcanzando su fin de vida, debe tenerlas detalladas en esta hoja de cálculo aquí.

Luego, el último paso, esbozar un plan para las bibliotecas correspondientes. Al hacer este plan, hay algunas cosas que debe tener en cuenta. ¿Cuál es el alcance de los cambios de versión? ¿Qué tan grandes son estos cambios que debemos hacer para completar la actualización? ¿Cuánta security exposición tenemos si nos mantenemos en la versión actual en la que estamos? ¿Tenemos experiencia en el tema desde la versión en la que estamos hoy hasta la nueva versión? ¿Y qué tipo de capacitación debemos brindar a nuestro equipo para que se pongan al día con la nueva versión? ¿Qué beneficios de características obtenemos si actualizamos? ¿Y cuánto tiempo se requiere para completar la actualización? Al principio, hablé de un ejemplo en el que me encontré en el que no habíamos actualizado durante demasiado tiempo y ahora estamos atrapados. Ahora estamos bloqueados. Pero ese fue un ejemplo relativamente pequeño. Se tardaron ocho semanas en solucionarlo. En HeroDevs, hemos asesorado a docenas de empresas de Fortune 500 que han esperado demasiado tiempo y ahora se enfrentan a un proyecto de migración multimillonario porque han esperado demasiado y no se han mantenido actualizados con estas actualizaciones. Es importante, está bien posponer, pero comprenda el costo de posponer estas actualizaciones.

Lo último que quiero decir aquí es que tienes opciones. Sepa que actualizar a la última versión de un conjunto de software no es su única opción. Muchas veces habrá versiones con soporte comercial de código abierto que pueden ofrecer soporte más allá del fin de vida. Y también puede utilizar un proveedor como nosotros, como HeroDevs, para obtener soporte continuo para software sin soporte. Entonces, si estás interesado en saber más al respecto, puedes visitarnos en nuestro stand. Lo último que diré aquí es que es importante ser proactivo ahora al formalizar una política de fin de vida. Puede ahorrarte muchos dolores de cabeza y mucho dinero en el futuro. Gracias por escuchar mi charla y espero hablar más contigo en el stand.