Every so often someone declares that free software "lost" to closed platforms and proprietary business models. The funny thing is that whoever makes that claim probably wrote the comment in a Chromium-based browser, on a Linux kernel, through infrastructure running on servers that mostly run free software. The narrative of defeat doesn't survive the slightest technical scrutiny.

The invisible backbone

Almost all of the internet's critical infrastructure runs on free software: Linux dominates servers, Kubernetes orchestrates workloads for the world's largest clouds, PostgreSQL and MySQL sustain databases for companies billing billions, and tools like Git, LLVM, or Nginx are invisible precisely because they work so well that we stop noticing them.

This isn't a coincidence. The open development model —with public code review, incentives aligned toward technical correctness instead of the fiscal quarter, and iteration cycles that don't depend on a single company— produces systems that are more robust in the long run than any equivalent closed alternative.

What changed: from ideology to pragmatism

In the 2000s, choosing free software was partly an ideological stance. In 2025 it is, above all, a pragmatic architecture decision:

  • Avoiding lock-in. A stack based on open standards (Kubernetes, OpenTelemetry, OCI) can move between cloud providers without rewriting the entire architecture.
  • Auditing security. When code is public, vulnerabilities are found and patched faster — not because free software is inherently more secure, but because the review surface is larger than that of any internal team.
  • Real cost. Enterprise licenses for proprietary software grow with usage; a technical foundation built on free software allows scaling without licensing cost becoming the business's bottleneck.

The risk that is real: maintainer sustainability

The legitimate concern isn't the technical quality of free software, it's the sustainability of those who maintain it. Projects critical to global infrastructure have depended for years on one or two volunteer maintainers without compensation proportional to the responsibility they carry. That imbalance is the ecosystem's real point of fragility, not a lack of technical merit.

As an architect, this changes a question I used to ask less often: when adopting a critical open-source dependency, I don't just evaluate whether the project solves the technical problem, I also evaluate the health of its maintenance community — number of active contributors, funding, response speed to reported vulnerabilities.

# A simple heuristic I apply before adopting a critical dependency
- ¿Tiene más de un mantenedor activo en los últimos 6 meses?
- ¿Existe un proceso documentado de disclosure de seguridad?
- ¿Hay financiamiento (sponsors, fundación, empresa) detrás del proyecto?
- ¿El historial de releases muestra cadencia sostenida, no solo picos aislados?

Why keep betting on it

Free software didn't win because it's free of charge. It won because the open development model, sustained over time, produces better technical decisions than the closed incentives of any individual company. Continuing to bet on it in 2025 isn't a nostalgic stance: it's recognizing that the infrastructure sustaining today's innovation —from AI to cloud computing— was built, and continues to be built, on that open foundation. The relevant question for any architect is no longer whether it's worth using free software, but how to contribute to keeping it sustainable.