Why it matters:The software behind much of the public web is kept alive by small teams, volunteer attention, and funding models that rarely match the dependency.
Open source software is often described as a commons. The metaphor is helpful until it suggests that a resource maintains itself. In practice, a large share of the digital world depends on libraries, protocols, and tools maintained by a few people who may be unpaid, underfunded, or exhausted.
The problem becomes visible when a critical project is compromised or abandoned. Suddenly everyone that relied on it asks who was responsible. The answer is often uncomfortable: the people with the clearest understanding of the code had no formal relationship with the organisations whose products depended on it.
Visibility creates free riders
Open code makes reuse easy. That is an advantage. It also makes it difficult to see the hidden dependency chain. A company may use a large framework and never realise that one small package in the tree is maintained by a single volunteer.
Software bills of materials and dependency scanning can improve visibility, but visibility alone does not fund maintenance. Organisations need a process for identifying critical dependencies and contributing money, code review, documentation, or staff time.
Fund the work, not just the launch
Grants and sponsorship can help open-source maintainers, but they often reward new features more readily than boring upkeep. Security patches, compatibility work, and documentation are less exciting to fund and more important to long-term reliability.
Public institutions have a particular responsibility because they increasingly rely on open tools for public services. When a government builds on open source, it should plan for the maintenance it needs and contribute improvements where possible. Otherwise, the public sector is simply moving a recurring cost onto someone else.
A digital commons needs maintenance just as a park needs paths cleared and trees pruned.
Governance matters
A project can be open and still have a narrow decision-making structure. That is not automatically bad: clear ownership can help a project move. But critical infrastructure should be prepared for succession. Documentation, contributor pathways, and transparent security processes make a project less dependent on a single person.
Foundations can provide a stable home for such projects, though they are not a cure-all. They need sustainable revenue and a mandate to support maintenance rather than only promotion.
Treat dependencies as public risk
The language of risk can be more persuasive than the language of community. A city that depends on a library to process payments, a hospital that relies on an authentication tool, or a school system built on an open platform should know what would happen if that dependency disappeared.
Mapping the risk is the first step. The second is a budget. The third is a culture that values the unglamorous work of keeping shared tools healthy. Open source is not free. It is shared, and sharing requires care.
Reference desk
Sources and further reading
Fieldwork publishes explanatory journalism and independent analysis. This story follows our editorial standards.
Updated throughout the editorial cycle.
