Who Actually Maintains Open Source?

Behind the open source components in your software are people. Not companies, not departments, not service teams — but in many cases individuals who work in their spare time, without pay, without a contract, and without any obligation towards you.

The reality behind the foundation #

Open source forms the foundation of the modern software industry. The reality behind this foundation looks like this:

• Individuals carry the burden. Many critical projects are maintained by a single person. There is no deputy, no holiday rota, no handover.
• Voluntary, not obligatory. Maintainers work because they want to — not because they must. They can stop at any time, and nobody can prevent them.
• No budget. Most projects have no income. Hardware, CI/CD infrastructure, and test environments are privately funded or through donations that are rarely sufficient.
• Burnout is real. The combination of rising expectations, ungrateful users, and lack of support regularly leads to maintainers quitting.
• No SLAs, no response times. When a vulnerability is reported, there is no guarantee when it will be addressed. Days, weeks, months — or never.

What happens when a maintainer stops? #

When the maintainer of a project stops, initially nothing happens. The project continues to exist, the code remains available, downloads continue. But:

• New vulnerabilities are no longer fixed
• Security reports go unanswered
• The software becomes outdated — operating systems, compilers, dependencies move on, the project does not
• Pull requests with fixes pile up without review

The project becomes a security risk without any scanner raising an alarm. There is no CVE for "this project is no longer maintained".

Legal relevance #

EU legislation requires you to manage precisely this risk:

• DORA Art. 28(5): For critical functions, ICT third-party service providers must meet "the highest quality standards"
• DORA Art. 28(8): Exit strategies must also exist for open source dependencies
• DORA Art. 8(7): Assessment of legacy ICT systems at least annually
• NIS2 Art. 21(3): Assessment of vulnerabilities and the security of development processes of direct suppliers
• CRA Art. 13(5): Due diligence when integrating FOSS components — an orphaned project increases the due diligence risk
• ISO 18974 (4.1.5 No. 5): Post-release monitoring for new vulnerabilities

A project without an active maintainer meets none of these benchmarks. If you deploy it nonetheless, the burden of proof lies with you to show that you know the risk and manage it.

What does this mean for you? #

You are relying on people you do not know, who have no contract with you, and who can stop at any time. This is not a reproach to the maintainers — it is the structure of the ecosystem. But this structure means that you as a company must take active steps: monitor project health, detect abandonment risks, prepare alternatives, and be able to intervene when it matters.

Further reading #

• OTTRIA and open source projects
• Open source has no contractual partner
• Open source supply chain security

Want to know which of your dependencies rely on a single maintainer? OTTRIA monitors the health of your entire SBOM. Arrange an initial consultation.