Open source without maintenance is borrowed infrastructure

An open licence keeps code available. It does not assign responsibility for updates, releases, security, governance or continuity.

The dependency appears harmless.

It is a small library, one package among hundreds, pulled into the application by another component. Nobody selected it through a formal architecture decision. Nobody negotiated support. Nobody recorded an owner.

Years later, it sits beneath authentication, data processing or deployment. Replacing it would require changes across several systems. Updating it breaks an internal integration. The upstream project has two active maintainers, both working in their spare time.

The organisation calls the software free.

Operationally, it has built a critical service on labour it neither controls nor supports.

The central test

Open source becomes infrastructure when the organisation can identify, maintain, update, recover and replace the dependencies on which its services rely.

---

A licence removes one restriction, not every dependency

An open-source licence creates meaningful rights.

It can allow an organisation to inspect code, modify it, redistribute it and continue using it without renewing a supplier’s permission. Those rights reduce one form of lock-in: the legal ability of a single owner to prevent continued use.

They do not create a maintenance team.

They do not guarantee that vulnerabilities will be investigated, releases will remain compatible, documentation will stay current or a project will survive the departure of its maintainers.

An open licence prevents one kind of captivity.

It does not prevent neglect.

Common mistake

Treating permission to maintain software as proof that somebody will maintain it.

Better framing

Separate legal openness from operational stewardship. Ask who performs the work required to keep the component usable, secure and transferable.

The distinction is becoming harder to ignore. The EU Cyber Resilience Act recognises open-source software stewards as a specific category and distinguishes casual publication from structured support of software used in commercial activity. Its treatment of regular technical contributions and financial assistance reflects a simple reality: widely consumed software needs an operating structure around it. (EUR-Lex)

The real dependency graph is larger than the package list

A software inventory usually begins with direct dependencies.

The application imports a framework, a database driver, a logging library and a collection of development tools.

The operating system sees a much larger graph.

Each direct dependency may pull in dozens of transitive packages. Build tools depend on plugins. Release pipelines depend on registries, signing services and package indexes. Container images inherit system libraries. Deployment automation imports providers and modules. Documentation may depend on generators that no longer support the current runtime.

Some dependencies are present only during development. Others enter the final artifact. Some can affect a build without appearing inside the deployed service. Others are downloaded dynamically after deployment.

The OpenSSF and Harvard-led Census III analysed more than 12 million observations of open-source libraries in production applications. Among its findings were that many widely used components depend on very small contributor groups, legacy software remains present, and cloud-service-specific packages are becoming more common. (Linux Foundation)

That last point matters.

An application may appear portable because its main framework is open source while much of its dependency graph assumes the interfaces, identity model or managed services of one cloud environment.

The package is open.

The architecture around it may not be.

Application
    |
    +---- Direct dependencies
    |          |
    |          +---- Transitive dependencies
    |
    +---- Build tools and plugins
    |
    +---- Package registries and mirrors
    |
    +---- Base images and system libraries
    |
    +---- Release, signing and deployment services
    |
    +---- Cloud-specific interfaces

A dependency review that stops at the first level is a list, not a map.

Popularity is weak evidence of sustainability

Download counts, stars and contributor totals can help identify widely used projects.

They do not answer the questions that matter during failure.

A project can be popular while review responsibility remains concentrated in one person. It can have many occasional contributors but no clear release authority. It can publish frequently while carrying unresolved architectural debt. It can appear inactive because it is mature, or appear active because automated dependency updates create constant noise.

Project health is contextual.

A small, stable library with a narrow interface may be easier to sustain than a rapidly changing framework with hundreds of contributors. A mature component may need little development but still require a credible security contact and release path. A heavily governed foundation project may be sustainable yet unsuitable for the organisation’s operating model.

Useful review questions include:

• Who can merge and release?
• Can another maintainer assume that authority?
• Are security reports handled through a known process?
• Can releases be reproduced and verified?
• Are decisions recorded publicly?
• Does the project depend on one organisation for infrastructure or staffing?
• Could the organisation maintain its current version if upstream priorities changed?

No single health score answers all of them.

The point is not to predict whether a project will survive forever. It is to understand what the organisation would have to do if it did not.

Updating open source is internal product work

Teams often treat dependency updates as maintenance overhead outside the product.

That is a mistake.

An update can change behaviour, remove an interface, require a data migration, alter performance or invalidate an internal extension. The organisation must decide whether to adopt it, defer it, backport a fix or replace the component.

Those are product and architecture decisions.

A credible update process needs:

• an inventory connected to actual services
• named responsibility for critical dependencies
• compatibility and regression tests
• a way to assess security relevance
• defined support windows
• controlled release and rollback
• a record of accepted exceptions

Blindly applying every upstream release is not stewardship.

Neither is freezing every dependency until a vulnerability makes change unavoidable.

The organisation needs a maintained path between the software it currently operates and the versions it may need next.

That path decays when it is not used. Tests stop representing reality. Local modifications diverge. Build instructions age. The first update after several years becomes a migration project.

Maintenance debt is not created because open source changes too quickly.

It is created when the organisation consumes change without maintaining the ability to absorb it.

---

Contribution is a form of risk control

Contribution is sometimes described as good citizenship.

It can be that. It is also practical infrastructure management.

An organisation can contribute code, but code is only one form of support. It can fund maintainers, sponsor security work, provide testing environments, improve documentation, triage issues, participate in governance or pay a supplier that contributes upstream.

The appropriate contribution depends on the dependency.

A small organisation does not need to become a core maintainer of every library it uses. A large institution should not assume that submitting occasional patches creates continuity for a critical platform.

The useful question is:

What contribution would reduce the specific dependency risk we have identified?

If the risk is concentrated release authority, governance support may matter. If the risk is compatibility with an institutional workload, testing and upstream feedback may help. If the risk is maintainer time, unrestricted funding may be more useful than another feature request.

Contribution should not purchase control over a community.

It should strengthen the conditions that make continued collaboration possible.

A fork is not a continuity plan

Open source preserves the legal possibility of forking.

That possibility matters. It prevents the original project from being the only party permitted to continue the code.

But a fork begins with a repository, not a maintained product.

The organisation still needs people who understand the architecture, a build environment, dependency management, tests, release automation, security response, documentation and governance.

It must decide which upstream changes to follow, which local patches to keep and how compatibility will be managed.

A private fork can quickly become a new lock-in.

The code is available, but only one internal engineer understands the changes. Releases depend on an undocumented pipeline. Security fixes must be discovered and backported manually. The organisation has escaped an external dependency by creating a more concentrated internal one.

A credible fork decision should identify:

1. the version and history being adopted
2. the people or supplier who will maintain it
3. the build, test and release process
4. the security response path
5. the relationship with upstream
6. the conditions for returning, replacing or retiring the fork

Without those elements, “we can always fork it” is not an exit plan.

It is a sentence used to postpone one.

Sustainability needs technical, social and governance design

Open-source sustainability is often discussed as though it were primarily a funding problem.

Funding matters, but durable infrastructure also depends on how responsibility is organised.

Research on sustainable scientific resources has reached a similar conclusion. The Open Data, Open Code and Open Infrastructure guidelines combine technical workflows, contributor processes and distributed governance because resources frequently become inaccessible when funding changes, key personnel leave or institutional priorities move. (Nature Scientific Data)

The same pattern applies beyond research software.

Technical openness allows inspection and modification.

Social processes allow people to enter, understand and contribute.

Governance determines how authority moves when maintainers, employers or funders change.

A project with open code but closed decision-making may be difficult to sustain. A project with welcoming governance but fragile release infrastructure may still fail operationally. A project with good automation but no succession process may remain dependent on one person.

Sustainability appears when no single departure removes the project’s ability to make decisions and releases.

---

A practical dependency review

Area	Weak signal	Stronger evidence
Inventory	A software bill of materials exists	Dependencies are connected to services, owners and operating consequences
Project health	The project is popular	Release authority, contributor depth, governance and security processes are understood
Updates	A scanner opens tickets	Named teams can assess, test, deploy and roll back updates
Build	Source can be downloaded	Approved versions can be built reproducibly from controlled inputs
Security	Vulnerability alerts are enabled	Reports, patches, backports and accepted risks have accountable owners
Contribution	The organisation uses open source	Critical projects receive technical, financial or governance support where useful
Fork	The licence permits modification	A credible team, release process and maintenance horizon have been identified
Replacement	Alternatives exist in the market	Interfaces, data and configuration have been tested against a replacement path
Transfer	Documentation is available	Another qualified team can update and operate the dependency chain

The review should be proportional.

A small formatting library does not need the same governance attention as an identity platform, database engine or deployment system. The relevant measure is not package count. It is the consequence of losing safe access to a component.

Open source should create options the organisation can exercise

Open source can make infrastructure more inspectable, adaptable and transferable.

It can support competition between service providers. It can preserve access after a commercial relationship ends. It can allow institutions to collaborate on infrastructure none of them should have to build alone.

Those benefits are real.

They become durable only when the organisation treats maintenance as part of the architecture.

The strongest open-source strategy is not to maximise consumption or insist that every component be maintained internally. It is to identify which shared systems have become critical, preserve the ability to operate them, and contribute where doing so strengthens continuity.

Free access to code is not free infrastructure.

The unpaid cost reappears as delayed updates, concentrated knowledge, fragile releases and emergency migration work.

One question for the next architecture review

Choose the smallest open-source component whose failure would interrupt an important service.

Then ask:

Who is responsible for keeping it usable, and what would the organisation do if its upstream maintainers stopped tomorrow?