The Hidden Cost of Open Source


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?


♪♪ ♪♪ ♪♪ 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 e-mails 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 going to use to develop this app on, they said the best part of this is all the software is free. So I was like, all right. Free is great. I like free, so 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 the 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 roadmap that I've got to deliver against, and upgrading is not on the roadmap. So I lie and I tell them, well, 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. This is the playbook of PMs, by the way, commit, do nothing, gaslight, and then repeat. So if I just described a conversation that you have had or are maybe currently having at your company, you're not alone. Teams working on shared code bases make this problem even harder, right, 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 does 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 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, right? 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, 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 It's a free website you can go look at. They have a really good database of libraries and end of life dates. But this is basically kind of what you want to see, and then you can see here we've got vue.js December 31, 2023 as end of life of version 2.0, or 2.0 and beyond. And then 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? So 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 multi-million dollar migration project because they've waited too long and they haven't stayed up to date with these upgrades. So 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 never-ending 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. Thanks for listening to my talk, and I hope to talk to you more at the booth. ♪♪♪
11 min
12 May, 2023

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

Workshops on related topic