Research and version note This is a version 0.1 research draft in Who Maintains the World? It concerns open-source components widely used in commercial and public systems. Governance, licences, and resources differ greatly among projects, so the article does not reduce open-source maintainers to one condition. The application dates and implementing guidance of the EU Cyber Resilience Act should be checked again before publication.
Who Maintains the World? · Article 4
Quick read
A modern application is rarely written by one team. It calls operating systems, language runtimes, cryptographic libraries, compression utilities, database drivers, and many packages. Customers see a product name while its dependency graph may reach components maintained by a few people, a foundation, or a volunteer community. Code that is free to obtain does not cost nothing to maintain, and access does not create a promise of support forever.
Open source has genuine maintenance advantages. Code can be inspected, forked, and repaired without leaving all knowledge inside one vendor. Yet a public repository does not guarantee enough reviewers, while download counts do not automatically produce money, time, and security capability. Many commercial users may each regard their reliance as marginal, collectively placing public risk upstream.
Software bills of materials and dependency scanning can answer what a product contains. They do not establish who can fix a vulnerability, how long an update will take, or how an obsolete component will be retired. A company that merely waits for an upstream patch treats product responsibility as a service bundled with the licence. Responsible users need accurate inventories, tested upgrade paths, material support or contribution to critical projects, and replacements for components that lose maintenance.
The EU Cyber Resilience Act distinguishes non-commercial open-source contributors, manufacturers placing digital products on the market, and certain legal entities that sustain open-source development. Its tailored role for open-source software stewards recognises that duties should follow commercial position and capacity for control rather than falling entirely on the individual who wrote the first code.
Metrics require similar caution. Stars, commits and release frequency say something about activity but little by themselves about review depth, maintainer fatigue or an available successor. A healthy dependency relationship needs contact routes, version and security policy, more than one person able to release, and downstream organisations capable of testing change. Where those conditions are absent, popularity can magnify fragility.
Open-source maintenance is digital supply-chain governance rather than charitable decoration. Code visibility creates the possibility of common maintenance; it does not prove that common maintenance is happening. Upstream projects need transparent vulnerability processes, downstream users must understand and test their composition, commercial beneficiaries should fund capability, and regulators should avoid imposing corporate obligations on non-commercial contribution.
Product names conceal dependency structures
Software buyers commonly encounter one vendor, subscription, and service agreement. The interface presents a single product, although the product consists of components from many sources. Developers reuse established libraries for reliability and efficiency. Reimplementing cryptography, parsers, and network protocols would be wasteful and may be less secure.
Reuse changes maintenance responsibility. A downstream failure may originate in product code, a commercial service, an open-source library, or an interaction among them. An update can repair a security flaw and break an old interface. The final product team has to decide whether to upgrade, how to test, and when to withdraw support for an old version.
Census III, published by Linux Foundation Research with OpenSSF and Harvard researchers, examines commonly observed open-source application libraries in production applications. Its importance is not a permanent popularity ranking. It makes dependency a supply-chain object rather than an issue confined to individual repositories. An organisation that does not know what it deploys cannot determine its exposure when a vulnerability, licence change, or maintenance cessation occurs.
Open code is not free maintenance
Open-source licences allow users, according to their terms, to use, inspect, modify, and redistribute code. They change the distribution of knowledge and control. A user need not depend entirely on the original vendor, a community can identify faults, and a project may be forked. These are real sources of resilience.
A licence does not generate labour. Reviewing patches, answering issues, making releases, maintaining build infrastructure, handling security reports, and coordinating contributors require time and expertise. A package may have many downloads and few continuous maintainers. Another may be supported by employees as part of paid work or organised through a foundation. It is equally misleading to describe all open source as spare-time volunteering.
The economic mismatch appears when benefit and obligation separate. Thousands of organisations use a component, and each has a small marginal effect on its operation, so each elects not to contribute. Aggregate dependence becomes critical without a corresponding increase in upstream resources. This resembles a public-goods problem, but moral exhortation alone cannot solve it. Organisations need to identify critical projects, understand whether funding improves security, and respect project governance.
Maintainers should not carry unlimited liability. Software is supplied under licences that generally do not guarantee every commercial application. A large company incorporating a component in a high-impact product chooses the context, performs integration, and may profit. Assigning final risk to an upstream individual moves responsibility away from the actor with greater control and resources.
Maintenance is more than vulnerability repair
Security incidents make maintenance visible, but daily work is broader. Maintainers assess feature requests, reject unsuitable changes, preserve documentation, update dependencies, migrate toolchains, and choose between compatibility and improvement. Rejection can be maintenance because every feature adds a future testing and support surface.
Project health cannot be inferred from commit count. A mature library may change rarely; high activity can reflect instability. Contributor numbers, response times, release patterns, and governance files provide partial evidence whose meaning depends on criticality, maturity, and use. Compressing an open-source project into one score would reproduce the visibility problem this series is examining.
Responsible ending is another maintenance activity. When support stops, a project should where possible state the final supported version, known risks, and migration options. Individuals have no duty to continue forever, but a downstream business cannot treat years without a release as automatic proof that everything is stable. It has to distinguish maturity from absence of capacity.
Who knows what is inside a product?
A software bill of materials records components and versions. Dependency tools identify direct and indirect packages, helping an organisation search for exposure after a vulnerability disclosure. This visibility is necessary, not sufficient.
Inventories become stale. Build and production environments differ. Package identity and version mapping are difficult, and a supplier’s list may omit server-side services. Even after an affected library is found, teams must assess whether the vulnerable path is reachable, whether the patch is compatible, whether a temporary control is adequate, and when deployment can occur.
Guidance from CISA and partner agencies on closing the software understanding gap directs producers and users towards understanding composition and risk. The direction is valuable, but “understanding” should not be reduced to purchasing a scanner. More alerts without people to assess them create another backlog.
Dependency knowledge has to move across organisations. Upstream maintainers disclose and fix; package distributors republish; downstream developers test; vendors notify customers; operators deploy. A patch can exist in a repository without reaching a running system because one interface in this chain stalls.
Why an update creates risk as well as reducing it
“Update promptly” is sound security advice, but a critical system cannot replace a component on sight. Releases change interfaces, performance, and data formats. Production services need testing and rollback. Rapid deployment reduces exposure to a known flaw and can introduce operational failure.
This is not an excuse for indefinite delay. It is a demand for maintenance capacity. Continuous integration, staged release, compatibility tests, and reversible deployment prevent safety and stability from becoming absolute alternatives. Organisations that remain on obsolete branches commonly do so because customisation and accumulated technical debt have obstructed an upgrade path.
Upstream cannot test every use. Downstream teams understand their configuration and consequences and therefore own integration. At the same time, an unreported compatibility fault cannot improve upstream. The strength of open-source maintenance is reciprocal learning. Treating a project as static free input breaks that relationship.
Why the EU created an open-source software steward
EU Regulation 2024/2847, the Cyber Resilience Act, introduces security and vulnerability-handling duties for products with digital elements. The legislation also recognises that an individual non-commercial contributor, a manufacturer of a commercial product, and a legal entity providing sustained support for open development should not bear identical obligations.
The Act uses the term open-source software steward for certain legal persons that support, on a sustained basis, open-source products intended for commercial activity and play a main role in their viability. The regime is more tailored than the manufacturer obligations and includes a cybersecurity policy, vulnerability handling, and cooperation with authorities in specified circumstances. Mere contribution to non-commercial software outside a person’s responsibility does not turn that contributor into a manufacturer.
Implementation will be difficult. Foundations vary in size, projects cross borders, and commercial intention is not always evident. Compliance cost could drive small bodies away; generous exclusions could let a commercial enterprise arrange itself around accountability. Any formal application must check commencement dates, guidance, and the actual role rather than concluding from the presence of open-source code.
The philosophically significant move is to connect responsibility with control, sustained support, and market role instead of tracing all duty to original authorship. Risk should not concentrate on the least resourced actor furthest from the final application.
What should commercial users contribute?
“Users ought to give back” is attractive but too general to govern. Contribution may take the form of money, code, tests, documentation, security review, infrastructure, or employee time. Needs differ, and an uncoordinated flood of patches can increase upstream workload.
A business should first know its critical dependencies and accept responsibility for integration. It can then ask projects what support is useful, funding ongoing capacity without purchasing opaque control. For widely shared components, pooled industry funds and foundations may work better than separate contracts.
Procurement can alter incentives. Public and private buyers may require suppliers to describe composition, support periods, vulnerability practice, and exit. The requirement should not move all responsibility to upstream projects again. A vendor must demonstrate that it can test and maintain what it supplies.
Funding does not automatically confer project authority. Communities have their own governance and users, while one sponsor’s short-term priorities may harm the whole. Sustainable maintenance requires resources and rules for priority, conflict of interest, and succession.
Is the ability to fork enough?
Open source is said to contain an ultimate exit: if a project stops, anyone can fork it. The legal permission is important, but it does not ensure that anyone has the knowledge to understand the code, form a community, run release infrastructure, and respond to security issues. A fork copies code, not trust and working relationships.
Resilience therefore depends on whether knowledge is distributed enough for succession. Documentation, reproducible builds, tests, clear licensing, and plural governance reduce transition cost. A repository can be public and still contain a critical single point if only one person controls release keys and architectural knowledge.
Not every small project needs a large committee. A few maintainers can operate clearly and efficiently. The obligation lies with downstream users to be honest about criticality. Once a component becomes infrastructure, users should help reduce its single points or maintain a substitute.
Will AI-generated code reduce the load?
Generative AI can draft tests, explain code, and suggest repairs. It also lowers the cost of generating new code and dependencies. Production can grow faster than review, integration, and long-term support capacity. An organisation may create more components that nobody deeply understands.
Generated code can repeat obsolete patterns or propose nonexistent packages. Even when it passes deployment tests, later patching and compatibility remain. Ambiguous authorship does not dissolve responsibility. The organisation placing an output in a product selects its context and risk.
Maintainers may receive more low-quality automated issues and patches, consuming scarce review. Projects need contribution policies; businesses should require human validation before sending changes upstream. AI is useful when it expands maintenance capability, not when a community becomes a free review layer.
Provisional judgment: open source is a relationship, not raw material
There is no stable count of maintainers on which “the internet” depends. Dependencies change by version and deployment; some projects have organisations and others are scarce in resources. A single number would provide false precision. The better question is whether each critical dependency has sustainable knowledge, governance, response, and succession.
The public value of open source lies in the possibility of inspection, modification, and shared maintenance. It does not guarantee that a community will materialise. Commercial and public users must identify composition, assess risk, test upgrades, plan exit, and support upstream capability in proportion to reliance. Projects need transparent support scope and security channels without acquiring unlimited responsibility for downstream uses.
Regulation should distribute duty by role. Corporate compliance imposed directly on individual contributors would shrink collaboration. Allowing products to disclaim responsibility because a component is open source would privatise benefit and move risk upstream. The EU’s role distinctions are an important experiment whose effects remain to be studied.
Evidence may revise the instruments. Funding may not consistently improve project security; mandatory inventories may create unusable volume in some contexts. Those tools should change. The more durable principle is that freedom to obtain source code and a promise of continuing support are different. An organisation depending on maintenance performed by others must understand the responsibility it has accepted.
Primary sources and further reading
- Linux Foundation Research, OpenSSF and Harvard LISH, Census III of Free and Open Source Software: Application Libraries, 2024.
- OpenSSF, Reports and publications.
- CISA and partner agencies, Closing the Software Understanding Gap, 2025.
- European Union, Regulation (EU) 2024/2847 — Cyber Resilience Act.
- Steven J. Jackson, “Rethinking Repair”, 2014.
Series navigation: Who Maintains the World? series overview
Discover more from Geoffrey Chen
Subscribe to get the latest posts sent to your email.