Cada cierto tiempo alguien declara que el software libre "perdió" frente a las plataformas cerradas y los modelos de negocio propietarios. Lo curioso es que quien hace esa afirmación probablemente escribió el comentario en un navegador basado en Chromium, sobre un kernel Linux, a través de infraestructura corriendo en servidores que ejecutan mayoritariamente software libre. La narrativa de la derrota no resiste el mínimo escrutinio técnico.

La columna vertebral invisible

Casi toda la infraestructura crítica de internet corre sobre software libre: Linux domina los servidores, Kubernetes orquesta las cargas de las nubes más grandes del mundo, PostgreSQL y MySQL sostienen bases de datos de empresas que facturan miles de millones, y herramientas como Git, LLVM o Nginx son invisibles precisamente porque funcionan tan bien que dejamos de notarlas.

Esto no es casualidad. El modelo de desarrollo abierto —con revisión pública de código, incentivos alineados hacia la corrección técnica en vez de hacia el trimestre fiscal, y ciclos de iteración que no dependen de una sola empresa— produce sistemas más robustos a largo plazo que cualquier alternativa cerrada equivalente.

Lo que cambió: de ideología a pragmatismo

En los 2000, elegir software libre era en parte una postura ideológica. En 2025 es, sobre todo, una decisión pragmática de arquitectura:

  • Evitar lock-in. Un stack basado en estándares abiertos (Kubernetes, OpenTelemetry, OCI) se puede mover entre proveedores cloud sin reescribir la arquitectura completa.
  • Auditar seguridad. Cuando el código es público, las vulnerabilidades se encuentran y parchean más rápido — no porque el software libre sea inherentemente más seguro, sino porque la superficie de revisión es mayor que la de cualquier equipo interno.
  • Costo real. Las licencias empresariales de software propietario crecen con el uso; una base técnica en software libre permite escalar sin que el costo de licenciamiento se vuelva el cuello de botella del negocio.

El riesgo que sí es real: sostenibilidad de mantenedores

La preocupación legítima no es la calidad técnica del software libre, es la sostenibilidad de quienes lo mantienen. Proyectos críticos para la infraestructura global han dependido durante años de uno o dos mantenedores voluntarios sin compensación proporcional a la responsabilidad que cargan. Ese desbalance es el verdadero punto de fragilidad del ecosistema, no la falta de mérito técnico.

Como arquitecto, esto cambia una pregunta que antes hacía poco: al adoptar una dependencia crítica de código abierto, no solo evalúo si el proyecto resuelve el problema técnico, evalúo también la salud de su comunidad de mantenimiento — número de contribuidores activos, financiamiento, velocidad de respuesta a vulnerabilidades reportadas.

# Una heurística simple que aplico antes de adoptar una dependencia crítica
- ¿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?

Por qué seguir apostando

El software libre no ganó porque sea gratuito. Ganó porque el modelo de desarrollo abierto, sostenido en el tiempo, produce mejores decisiones técnicas que los incentivos cerrados de cualquier empresa individual. Seguir apostando en 2025 no es una postura nostálgica: es reconocer que la infraestructura que sostiene la innovación actual —desde IA hasta cloud computing— se construyó, y se sigue construyendo, sobre esa base abierta. La pregunta relevante para cualquier arquitecto ya no es si vale la pena usar software libre, sino cómo contribuir a que siga siendo sostenible.