The Hidden Cost of Open Source

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.

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.

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.