Public services, banks, manufacturers and cloud platforms all depend on open-source components. The sustainability question is not whether every project should become a company; it is whether critical software has enough governance, maintenance capacity and security response for the role organizations assign to it.
Open source is often treated as free inventory: install a package, scan it, and assume someone else will maintain it. But a dependency may be a solo maintainer’s weekend project, a foundation-backed project, or a product with commercial support. License availability tells us what users may do with code; it does not promise response times, compatible releases or a funded security team.
The European Commission announced a new Open Source Strategy in June 2026 as part of its technological sovereignty package, highlighting support for solutions, skills, infrastructure and reuse by public administrations. That is a policy direction, not proof that an individual maintainer or library receives funding. Engineering teams still need to understand their own dependency exposure and procurement obligations.
Download counts and stars are weak proxies for operational importance. A small cryptographic library or parser may sit on a critical path in thousands of products, while a popular UI tool may be replaceable. Build a dependency graph from SBOMs and runtime evidence; enrich it with service criticality, reachable attack surface, data handled, update constraints, support status and alternatives. Prioritize components by consequence and exposure, not by headline CVE count alone.
| Signal | What to record | Why it matters |
|---|---|---|
| Operational role | Services, products, safety/security boundaries and data paths | Estimates the blast radius of failure or compromise. |
| Maintenance | Release history, supported branches, bus factor, issue response | Shows whether fixes can plausibly arrive and be adopted. |
| Security process | Disclosure channel, patch policy, provenance and build controls | Reduces uncertainty during vulnerability response. |
| Exit options | Fork cost, API compatibility, replacement and migration time | Turns dependency choice into a recoverable decision. |
Maintainers need time to review changes, triage reports, test releases, publish advisories and keep build infrastructure healthy. Support can include recurring grants, paid maintenance contracts, employer time, foundation fiscal hosting, security audits, reproducible-build work or shared incident-response capacity. The arrangement should be transparent about deliverables and governance without making one sponsor the sole authority over a community project.
Organizations that depend on a library can contribute upstream instead of accumulating private patches. A practical contribution plan may fund a maintainer, fix a difficult bug, improve test coverage, document upgrade paths or maintain a compatibility branch. Contributions should follow project governance and avoid placing confidential customer data or unreviewed security details in public issue trackers.
The EU Cyber Resilience Act distinguishes commercial product responsibilities from open-source stewardship; the precise role depends on activity and circumstances. Do not flatten the law into “all maintainers are manufacturers” or the opposite claim that open source is exempt from every obligation. Product makers should map which components they incorporate, define vulnerability handling, preserve technical evidence and assess their own role with qualified legal support. A project’s public license does not transfer a product manufacturer’s responsibilities to volunteer contributors.
Governance needs clear escalation contacts, supported-version policy, disclosure expectations and a way to coordinate fixes across downstream users. For critical projects, a lightweight security policy and signed release process may matter more than an impressive badge that nobody maintains.
Public-sector buyers can ask for open standards, exportable data, source availability where appropriate, upstream contribution options and long-term support plans. Requirements should reward interoperability and maintainability rather than demand a particular license without considering project fit. Procurement can fund a support contract or shared maintenance pool, but contracts must specify security response, release ownership, intellectual property and what happens when funding ends.
Measure sustainability outcomes that engineering can verify: percentage of critical dependencies with named owners, time to remediate, supported-version coverage, upstream patch acceptance, reproducible releases, documented alternatives and funded maintenance hours. These are better signals than counting repositories or announcing that an organization “uses open source.”
I would join SBOM generation to service ownership and a dependency-risk register. Each high-criticality component would have an accountable internal owner, upstream contact, support status, patch and disclosure path, upgrade window, fallback and exit cost. A quarterly review would compare dependency criticality with actual maintainer capacity and funding; procurement teams would see the unresolved risk before contract renewal. Contributions and sponsorship would be tracked as part of resilience planning, not as a marketing metric.
For a project receiving support, publish the governance model, funded work, release criteria and conflict-of-interest process. Preserve contributor independence, keep security reports confidential until coordinated disclosure, and avoid promising service levels that community maintainers cannot sustain.
Open-source sustainability is an operational concern: critical software needs maintenance capacity, security processes, governance and credible recovery options. Europe’s renewed policy interest can help create demand and shared infrastructure, but each organization still has to fund and manage the dependencies it relies on. Build a map from software inventory to service risk, contribute upstream, procure support deliberately and keep legal roles precise.
Editorial note: This is a software-engineering discussion, not legal advice. CRA obligations depend on product and actor roles; seek qualified counsel for a specific deployment.