El Costo Oculto del Software de Código Abierto

Rate this content
Bookmark

Hay un costo que muchas empresas no consideran al usar software de código abierto. Puede costar mucho dinero y tiempo mantenerse actualizado con las versiones obsoletas.

El software de código abierto es gratuito para las empresas hasta que el autor obsoleta una versión.

Estas son algunas mejores prácticas que recomendamos al considerar la adopción de software de código abierto:

  • - ¿Quién es el autor? ¿Tienen una reputación sólida que va a perdurar en el tiempo? ¿Tienen los recursos para respaldar una biblioteca empresarial?
  • - ¿Cuánto soporte en línea hay en la comunidad para esta biblioteca? ¿Cuántas dependencias tiene esta biblioteca?
  • - ¿Tiene una política de fin de vida? ¿Qué sucederá cuando lancen una nueva versión? ¿Las empresas tendrán la opción de quedarse en versiones antiguas durante mucho tiempo?
  • - ¿Qué se debe considerar al migrar a un marco de trabajo compatible después de que una versión haya sido obsoletada?
11 min
12 May, 2023

Video Summary and Transcription

La charla de hoy analiza los costos ocultos del software de código abierto y la importancia de la planificación patrimonial para las pilas de código abierto. Destaca los desafíos que enfrentan los gerentes de productos en términos de actualizaciones de bibliotecas y prioridades conflictivas. La charla también enfatiza los pasos para establecer una política de fin de vida para las pilas de código abierto, que incluyen monitoreo, inventario, clasificación y planificación de actualizaciones. Además, enfatiza la necesidad de considerar el riesgo, las dependencias y el impacto comercial al identificar fechas de soporte y opciones de actualización. La charla concluye destacando la importancia de ser proactivo al formalizar una política de fin de vida para evitar proyectos costosos de migración.

Available in English

1. Hidden Costs of Open Source

Short description:

Hoy voy a hablar sobre los costos ocultos del software de código abierto y la planificación patrimonial para su conjunto de código abierto. Comencé una empresa llamada Freeplay, una aplicación móvil de fitness. Tuvimos que retrasar un cambio de precios debido a una versión de software no compatible. El software gratuito requiere actualizaciones y pruebas frecuentes, lo que puede ser costoso. Como gerente de producto, enfrenté desafíos con las actualizaciones de bibliotecas y prioridades conflictivas.

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.

2. Establishing an End-of-Life Policy

Short description:

Esta sección discute los pasos para establecer una buena política de fin de vida para su conjunto de código abierto. El primer paso es establecer un equipo y una frecuencia de revisión para monitorear sus necesidades de código abierto. El segundo paso es obtener un inventario del código abierto que está utilizando actualmente en su conjunto. Luego, clasifique el inventario por criticidad para su conjunto y identifique fechas clave para cada biblioteca crítica. Finalmente, evalúe los eventos y esboce un plan para abordar cada actualización a medida que ocurran.

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:

3. Identifying Support Dates and Outlining a Plan

Short description:

¿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? Ahora hemos realizado un inventario, clasificado por criticidad e identificado las fechas clave de fin de soporte para la biblioteca. Considere el alcance de los cambios de versión, la exposición a la seguridad, la experiencia, la capacitación, los beneficios de las características y el tiempo requerido para la actualización. Esperar demasiado tiempo puede llevar a proyectos de migración multimillonarios. No actualizar a la última versión no es la única opción; existen versiones con soporte comercial y soporte del proveedor. Sea proactivo al formalizar una política de fin de vida para evitar futuros dolores de cabeza y costos.

¿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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
JSNation 2022JSNation 2022
28 min
Full Stack Documentation
Top Content
Interactive web-based tutorials have become a staple of front end frameworks, and it's easy to see why — developers love being able to try out new tools without the hassle of installing packages or cloning repos.But in the age of full stack meta-frameworks like Next, Remix and SvelteKit, these tutorials only go so far. In this talk, we'll look at how we on the Svelte team are using cutting edge web technology to rethink how we teach each other the tools of our trade.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)