ADR-023: Software libre como requisito obligatorio¶
Estado: aceptado Fecha: 2026-05-17
Contexto¶
La filosofía de SmallCountry exige soberanía tecnológica y libertad de software. Sin un criterio firme y documentado, existe el riesgo de normalizar herramientas privativas por conveniencia, erosionando los principios fundacionales. Sin embargo, en algunos nichos (firmware de dispositivos IoT comerciales, algunas herramientas de diagnóstico) las alternativas libres son inexistentes o inviables. Es necesario un estándar claro que defina el compromiso sin caer en dogmatismo impráctico.
Decisión¶
Toda la infraestructura central de SmallCountry debe ser software libre (licencias GPL, MIT, Apache, AGPL o compatibles con la FSF/OSI). Esto incluye el hipervisor, sistema operativo, bases de datos, mensajería, automatización, backups, monitoreo y aplicaciones principales. Las excepciones solo se permiten para herramientas no críticas, con una justificación explícita documentada en un ADR específico que explique por qué no existe alternativa libre viable y qué plan de migración se contempla si en el futuro aparece una.
Alternativas consideradas¶
| Opción | Por qué se descartó |
|---|---|
| Pragmatismo sin reglas: usar lo que funcione, libre o no | Viola los principios fundacionales de SmallCountry. Abre la puerta a dependencia de proveedores, riesgo de vendor lock-in y pérdida de soberanía sobre los datos. |
| Software privativo como norma (Windows, Google, AWS) | Opuesto al Manifiesto de SmallCountry. Sin control sobre el código, los datos o la infraestructura. |
| Dependencia de SaaS (nube pública) | Entrega los datos y la operación a terceros. La conectividad intermitente de la zona rural hace inviable depender de servicios externos. |
| ## Consecuencias | |
| - ✅ Soberanía tecnológica total: SmallCountry controla su código, sus datos y su infraestructura. | |
| - ✅ Sin vendor lock-in: si un proyecto cambia de dirección o desaparece, siempre hay acceso al código fuente. | |
| - ✅ Comunidad y auditoría: el software libre permite inspeccionar el código, corregir bugs propios y beneficiarse de contribuciones comunitarias. | |
| - ✅ Alineación con los Principios Inmutables del proyecto. | |
| - ❌ Algunas herramientas excelentes quedan excluidas por ser privativas. Esto puede implicar más trabajo manual o funcionalidad reducida en ciertos nichos. | |
| - ❌ Requiere disciplina: cada nueva herramienta debe pasar por evaluación de licencia antes de ser adoptada. | |
| - ❌ Posible fricción al colaborar con externos que usan herramientas privativas (archivos .docx, videollamadas propietarias). | |
| ## Referencias | |
| - Manifiesto: Software Libre | |
| - Principios Inmutables |