Treat open source software as critical infrastructure

A tale of 3 open source projects

Over the past two years, Ingress-Nginx, a major Kubernetes project, has moved into retirement, FFmpeg disclosed that its first governmental sponsor would help sustain maintenance, and Flux showed that a project can regain footing when companies step in with real backing. Those examples show that open source risk is not only about code quality or CVEs, but about the people behind the code, and whether they can keep doing the work. 

1. Ingress-NGINX goes unmaintained

Ingress-Nginx is considered vital infrastructure in many cloud-native environments. The CNCF announced in November 2025 that best-effort maintenance would continue only until March 2026, after which there would be no more releases, bug fixes or security updates. The Ingress-Nginx retirement post mentions that the project had only two people doing development work on their own time after work and on weekends. This is not an edge case. It is a governance and staffing failure.

"There were two people responsible for maintaining something that 50% of cloud-native environments rely directly on and nobody wants to help them," said Cosgrove.

2. FFmpeg draws government support

FFmpeg is a project many large organizations rely on to bring audio and video to billions of people every day. In 2024, the project briefly slowed development as maintainers warned that ongoing work was unsustainable. Thankfully, they soon announced that Germany’s Sovereign Tech Fund had become the project’s first governmental sponsor. This was a close call, and FFmpeg’s developer documentation still asks users to support the projects they rely on, so those projects keep getting maintained and developed.

"We've gotten very good at supply chain analysis. I think there needs to be a similar thing for who's funding these projects. Are they thriving? Are they living? Do they have a future or not?" said Morgan.

3. Flux receives concrete industry support, improves sustainability

In January 2024, Weaveworks, the creator of Flux, announced it was shutting down, leaving the future of the Flux project in jeopardy. However, in March, Flux announced enhanced backing from dedicated companies committed to ongoing maintenance and development. As of February 24, 2026, the project has released Flux 2.8. Its release notes point users who need broader backward compatibility or enterprise support to vendors such as ControlPlane.

That does not mean the economics are solved forever. It does show that projects can recover when maintainers have support, release continuity and a commercial path around the upstream codebase.

Any responsible company should be actively looking at the health of the open source projects they rely on.

"Any responsible company should be actively looking at the health of the open source projects they rely on. If one of those dependencies appears to be unhealthy or trending towards being unhealthy, devote a few hours a week of one or two engineer's time to help," said Cosgrove.

Security visibility is not enough on its own

Companies have improved their ability to assess risk in the software supply chain. OpenSSF Scorecard offers an automated security score for open source projects. The OpenSSF Criticality Score identifies which projects matter most to the broader ecosystem. SLSA defines controls around artifact integrity, and OpenSSF has argued that attestations add stronger provenance and validation than an SBOM can provide.

But those tools do not answer questions such as:

• Who is funding the project?
• How many maintainers are active right now?
• Is one employer carrying the whole release process?
• Is the project still shipping on a healthy cadence?
• Is there a support path if the upstream team burns out?

Organizations need a project health review alongside their security review. The point of this exercise is to spot fragility early enough to act while the project is still fixable.

A simple internal review can start with a short set of checks on every open source project being used:

• Maintainer depth and employer diversity.
• Release cadence over the last 12 months.
• Time to fix important bugs and security issues.
• Governance clarity and roadmap ownership.
• Availability of commercial support, donations or foundation backing.
• Migration effort if the project stalls or shuts down.

Develop an action plan for managing open source

Leaders do not need to fund every dependency equally. However, they do need a sharper policy than hoping the ecosystem sorts itself out.

A sensible plan looks like this:

• Rank open source dependencies by operational importance, not by package count.
• Add project health checks to the same review process used for security and license risk.
• Set aside engineering time for upstream fixes on projects that sit close to revenue, uptime or customer data.
• Budget for support subscriptions or direct funding where stable releases and long-term maintenance matter.
• Build migration plans early for projects already showing distress, especially where the replacement is not a drop-in swap.

Open source health is critical

The old enterprise habit was to think of open source as free inventory. That is getting harder to defend. Some projects will stay healthy because foundations, vendors and contributors keep the work moving. Some will need more direct support. Some will reach retirement and the migration bill will land on organizations that assumed someone else would keep it alive.

The real question is whether organizations understand which projects are healthy, which ones are drifting and where they are willing to pay, contribute or migrate before the warning turns into an outage.

Twain Taylor is a technical writer, musician and runner. Having started his career at Google in its early days, today, Twain is an accomplished tech influencer. He works closely with startups and journals in the cloud-native space.