The Hidden Cost of Open Source

Rate this content
Bookmark

There is a cost that many companies don’t consider when using open source. It can cost a lot of money and time to keep upgrading sunsetted versions.

Open source is free for companies to use until the author sunsets a version.

These are some best practices that we we recommend when considering open source adoption:

  •         - Who is the author? Do they have a strong reputation that is going to be around for a long time? Do they have the resources to support an enterprise library?
  •         - How much online support is there in the community for this library? How many dependencies are on this library?
  •         - Does it have an end of life policy? What’s going to happen when they rev on a version? Will companies have an option to stay on older versions for a long time?
  •         - What should you consider when migrating to a supported framework after a version has been sunsetted?
Aaron Mitchell
Aaron Mitchell
11 min
12 May, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Today's Talk discusses the hidden costs of open source software and the importance of estate planning for open source stacks. It highlights the challenges faced by product managers in terms of library upgrades and conflicting priorities. The Talk also emphasizes the steps to establish an end-of-life policy for open source stacks, including monitoring, inventorying, ranking, and outlining upgrade plans. It further emphasizes the need to consider risk, dependencies, and business impact when identifying support dates and upgrade options. The Talk concludes by stressing the importance of being proactive in formalizing an end-of-life policy to avoid costly migration projects.

Available in Español

1. Hidden Costs of Open Source

Short description:

Today, I'm going to talk about the hidden costs of open source and estate planning for your open source stack. I started a company called Freeplay, a mobile fitness app. We had to delay a pricing change due to an unsupported software version. Free software requires frequent upgrading and testing, which can be costly. As a product manager, I faced challenges with library upgrades and conflicting priorities.

Thank you. Hello everyone. I'm Aaron Mitchell, president of HeroDevs, and today I'm going to talk about the hidden costs of open source and we're going to talk a little bit about estate planning for your open source stack.

But first, let's jump into a story. So I started a company about seven years ago. It was called Freeplay, and it was a mobile fitness app that you would use to make it really easy to go exercise with your friends. And a few years into Freeplay, we decided that we were going to start, we were going to change our pricing model. So we sent out all these emails to our partners, to our customers, we updated our website. We had all these changes made to the application. And a few days before we were ready to deploy the changes, we tried to ship to the app store and the app store denied our submission because we were on this unsupported version of Xcode and React Native that we couldn't ship with anymore. So we ended up having to walk back to all of our partners, all of our customers with our tail between our legs and delay the pricing change for the next eight weeks while we focused on upgrading and testing our software and getting to the latest version so that we could ship again.

And that's when I realized something as a founder and CEO of a startup. When my engineers came to me and pitched, hey, here's the stack that we're gonna use to develop this app on, they said, the best part of this is all this software is free. So I was like, all right. Free is great. I like free. So let's let's do it. What they didn't tell me was that while it's indeed free, you just have to spend a lot of your time upgrading and testing and re-upgrading and retesting the software. And if you don't upgrade, then you could be footing the bill for a really expensive upgrade that comes a few months or a few years later. And as a business guy, that was a lot different than any other paid software that I was using. So it prompted a question for me, which was, do we have some kind of an open source upgrade or end of life policy.

I was in product management for six years in my career before I started FreePlay. And I remember very vividly our sprint planning meetings where we had just gone through all the stories and everything for this sprint was laid out. We were ready to go. And it's always at the end, an engineer would raise their hand and say, hey, by the way, that library that we're using needs to be upgraded. And as a product manager, I have a road map that I've got to deliver against. And upgrading is not on the roadmap. So I lie and I tell them, we'll get that added to the next sprint. And then the next sprint rolls around and magically it's not there. And I don't remember the conversation at all.

2. Establishing an End-of-Life Policy

Short description:

This section discusses the steps to establish a good end-of-life policy for your open-source stack. The first step is to establish a team and a check-in cadence for monitoring your open-source needs. The second step is to get an inventory of the open-source you're currently using in your stack. Then, rank the inventory by criticality to your stack and identify key dates for each critical library. Finally, evaluate the events and outline a plan for addressing each upgrade as they occur.

This is the playbook of PMs, by the way, commit, do nothing, gas light, and then repeat. So if I just described a conversation that you have had or maybe currently having at your company, you're not alone. Teams working on shared code bases make this problem even harder because no one wants to foot the bill. No one wants to be the team that upgrades for everybody else. But most companies don't have a formal end-of-life policy for their open-source stack. And so this begs the question, then, well, what is a good end-of-life policy, an upgrade policy, look like? So today we're going to walk through very briefly how to establish a good end-of-life policy for your open-source stack. And there's five steps that I'm going to walk through really, really quickly here. The first step is you've got to establish a team and a check-in cadence for monitoring your open-source needs. The second thing is you've got to get an inventory of what open-source you're using in your stack currently. Then rank the inventory by criticality to your stack. Identify the key dates for each of the critical libraries. And then evaluate the events and outline a plan for addressing each upgrade as they occur. So let's get into this a little bit deeper.

The first step, establishing a team and a check-in cadence. Some roles that you may want to include as you're thinking about who do I put on this team that's going to check for our end of life policy and put together our end of life policy. You want to include a security team member if you have them. Include a QA team member, someone from your engineering team, and ideally somebody from your product team that can help monitor and weigh the pros and cons against the business roadmap that's been communicated. Secondly, from a cadence perspective, we typically recommend doing holding a monthly or a quarterly meeting with this team. Okay. So step two. We've got the team assembled. We've got our cadence set up. Now we want to get an inventory of our open source. So this is a very, very basic version of what an inventory might look like. And you can use inventory scanning tools that are available for free on the web, or you can also just do an internal survey to identify the software that's being used in your company. You want to make note of what is the most current version of these applications that we have deployed or these software packages that we have deployed, and what version are we currently on. And then it's nice to have a little description for people that may not be familiar with what these libraries are doing. The third thing that we want to do is we want to rank our libraries by criticality. We don't want to try and boil the ocean. A lot of companies have upwards of 100 or more libraries that they're using that are open source, so some criteria you may want to think about as you're ranking these open source software packages.

3. Identifying Support Dates and Outlining a Plan

Short description:

What's your risk surface area if a critical vulnerability is discovered within this package? How many developers do I have using this library? How many dependencies do I have on this library? And what's the business impact if the library was no longer available? Now we've taken inventory, ranked by criticality, and identified the key end of support dates for the library. Consider the scope of version changes, security exposure, expertise, training, feature benefits, and time required for the upgrade. Waiting too long can lead to multimillion-dollar migration projects. Upgrading to the latest version is not the only option; commercially supported versions and vendor support are available. Be proactive in formalizing an end of life policy to save future headaches and costs.

What's your risk surface area if a critical vulnerability is discovered within this package? How many developers do I have using this library? How many dependencies do I have on this library? And what's the business impact if the library was no longer available?

Okay, so now we've taken inventory, we've ranked by criticality, now what we want to do is we want to identify the key end of support dates for this library. I haven't included it in here, but you may also want to understand when was the last version shipped so we know how far into the release cycle we are. You can get data about end of life dates for a lot of your software stack on end of life.date. It's a free website you can go look at. They have a really good database of libraries and end of life dates. This is basically what you want to see, and then you can see here we've got Vue.js December 31, 2023, as end of life version 2.0 or 2.6, or 2.0 and beyond. Other libraries that may be reaching their end of life moments, you want to have those outlined in this spreadsheet here.

Then the last step, outlining a plan for the appropriate libraries. Some things you want to consider as we're making this plan. What's the scope of the version changes? How big are these changes that we have to make to complete the upgrade? How much security exposure do we have if we stay on the current version that we're on? Do we have subject matter expertise from the version that we're on today to the new version? And what kind of training do we have to do to our team to get them up to speed with the new version? What feature benefits do we get if we do upgrade? And what's the time required to complete the upgrade? At the beginning, I talked about an example where I was caught in this we haven't upgraded for too long and now we're stuck. Now we're blocked. But that was a relatively small example. It was eight weeks to get that fixed. At HeroDevs, we've consulted with dozens of Fortune 500 companies that have waited too long and they're now staring down the barrel of a multimillion dollar migration project because they've waited too long and they haven't stayed up to date with these upgrades. It's important to, it's okay to punt but understand the cost of punting on these upgrades.

The last thing I want to say here is that you do have options. Know that upgrading to the latest version of a software stack is not your only option. A lot of times there will be commercially supported versions of open source that may offer support beyond the end of life. And then you can also use a vendor like us, like HeroDevs, to get neverending support on out of support software. So, if you're interested in talking more about that you can come see us at our booth. The last thing I'll say here is it's important to be proactive now about formalizing an end of life policy. It can save you a ton of headache and a lot of money in the future.

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

Building Better Websites with Remix
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!
Don't Solve Problems, Eliminate Them
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.
Using useEffect Effectively
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.
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
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.
Full Stack Documentation
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.
Design Systems: Walking the Line Between Flexibility and Consistency
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 Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
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 Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
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, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
Paul Everitt
Paul Everitt
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.
Designing Effective Tests With React Testing Library
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Top Content
Featured Workshop
Josh Justice
Josh Justice
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
Building WebApps That Light Up the Internet with QwikCity
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Miško Hevery
Miško Hevery
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.
Back to the Roots With Remix
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
Alex Korzhikov
Pavlik Kiselev
2 authors
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)