When an engineer adds an open source package, the cost discussion usually ends at the license. The package is free to download, so nobody estimates it. Then it stays in the codebase for years, and every CVE, breaking upgrade, and maintainer change that touches it gets paid for out of sprint capacity that was meant for the roadmap.

Engineering leaders should estimate that cost the way we estimate features, in engineer-weeks, over a window long enough to see it. In the example below, one well-used package comes to roughly 2.4 to 3.6 engineer-weeks over 3 years, and the part most teams estimate up front is about 6 to 8 percent of it. Two weeks ago I argued for making the governed path the fastest path at intake. That led me to putting a number on everything that comes after intake.

Key takeaways

• An open source package costs nothing to download, and Engineering pays for it in sprint capacity for as long as it stays in the codebase.
• Four kinds of work recur over three years on each new dep: intake, CVE remediation, breaking-change upgrades, and end-of-life decisions.
• Intake is usually the only one teams estimate, and it is the smallest.
• In an illustrative model, one well-used package costs roughly 2.4 to 3.6 engineer-weeks over three years.
• Engineering leaders can decide whether that work stays unplanned, goes to an internal team, or moves to a provider with remediation SLAs.

Why estimate in engineer-weeks over three years

Roadmaps are already planned in engineer-weeks, so an estimate in the same unit shows which planned work a dependency displaced. If upgrading one package takes two weeks in a quarter, the team ships two fewer weeks of something else that quarter.

The three-year window matters because the expensive work rarely happens in year one. Breaking upgrades, maintainers stepping away, and a steady stream of CVEs in the package's own dependencies tend to show up after other code already relies on it.

Four kinds of work over a dependency's life

I group the recurring work into four buckets. Teams usually estimate only the first.

1: Intake and integration

Someone (or something) evaluates the package, wires it in, and writes tests around it. The package also brings in its own dependencies, and those rarely get evaluated separately. It's the smallest of the four, and AI coding assistants make it smaller still, which is why teams now add packages faster than they budget for the other three.

2: CVE remediation

Most of this work exists because your security team, and the CISO behind it, requires it, and they're right to. A known CVE shipping to customers is real exposure for them and for the customer. The cost of meeting that requirement, though, lands almost entirely in engineering. Each CVE in the package, or in anything it depends on, turns into unplanned work for someone. They triage it, find a fixed version, test it, ship it, and then go back to the task they dropped. In ActiveState engineering, and with our customers, we’ve measured 4 to 8 developer hours reclaimed per CVE when customers receive remediated components instead of patching on their own. Across a full dependency tree, year after year, this is usually the largest of the four.

3: Breaking-change upgrades

Sometimes a security fix ships only in a new major version, and that version changes an interface your code calls. A patch that should have taken an afternoon becomes a migration, and it lands in whatever sprint the CVE happens to arrive in. These upgrades belong on the roadmap as a recurring item with time set aside in advance, the same way teams plan infrastructure renewals.

4: End of life

When maintainers stop shipping fixes, a team has three options. It can fork the package and maintain it, replace it, or isolate it so less of the codebase depends on it. Each option costs engineer-weeks, and tracking package health lets a team make that call before an incident forces it.

An example for one package

These inputs are illustrative. Replace them with your own numbers.

• Intake and integration: one engineer-day (0.2 engineer-weeks), including infosec assessment.
• CVE remediation: 4 CVEs a year across the package and its dependencies, at 4 to 8 hours each. That is 16 to 32 hours a year, or 1.2 to 2.4 engineer-weeks over three years.
• One major-version upgrade with breaking changes: about 3.5 engineer-days (0.7 engineer-weeks).
• One end-of-life decision in year three: about 1.5 engineer-days (0.3 engineer-weeks).

That adds up to roughly 2.4 to 3.6 engineer-weeks for a single package. The intake work, which is the part most teams estimate, is about 6 to 8 percent of the total.

Where release delays come from

The engineer-weeks are only part of the cost. When a CVE or a forced upgrade arrives close to a release, the release slips. In ActiveState's research report The AI Remediation Bill, 98% of the enterprises with the most urgent open source control gap had an open source-related release delay in the past year, and 88% had more than one.[1] That group is 40 organizations, so treat the numbers as directional.

Deciding who does the work

Someone in engineering does this work either way. What leaders get to choose is how it's staffed, and there are three common setups.

• Leave it in sprint “ktlo” capacity. This is the default. The work arrives unplanned and usually falls to whoever is closest to the next release.
• Staff an internal team that builds, patches, and upgrades components for the rest of engineering. Some organizations should, and they should budget it as permanent headcount (here's everything that comes with building your own private artifact registry).
• Use a provider with contractual remediation SLAs. ActiveState builds components from source and delivers remediated solutions within 5 business days for critical CVEs, 10 for high, and 30 for all others, once a fix is available upstream. Customers see roughly 95% fewer CVEs than with community open source artifacts, so there is less to remediate in the first place, and what remains sits in a contract instead of in your sprints.

Start with five packages

Pick the five packages your product depends on most. For each one, look back over the last year and count the CVEs your team handled, the upgrades it shipped, and any releases it delayed, then convert that work to engineer-weeks. Put the total next to the roadmap for Q1 planning. That number is the input for the staffing decision above. If yours comes out very different from mine, I'd like to know which bucket moved, and why.

Eric Thompson is VP of Engineering at ActiveState, with more than 20 years building and scaling enterprise software and developer-tools organizations.

Footnotes

[1] ActiveState, research by Moving Horizon, "The AI Remediation Bill," September 2026, published October 20, 2026 (n=307; Ready-to-Act Leaders n=40, directional). https://go.activestate.com/ai-remediation-bill. Figures: 98% and 88% (p21). Self-reported.