Países Bajos migra a Forgejo: ¿por qué reemplazar GitHub es una decisión técnica estratégica?

Introducción

En noviembre de 2025, Jan Vlug —ingeniero de software del portal de desarrolladores del gobierno holandés— publicó un análisis técnico detallado sobre qué plataforma de hosting de código fuente debería adoptar el Estado neerlandés. El contexto no era menor: el Ministerio del Interior (BZK) ya estaba configurando una instancia Git dedicada, pero la decisión final aún no estaba clara. Hasta ese momento, el código gubernamental se alojaba en GitHub y GitLab, dos plataformas que, pese a su utilidad técnica, presentaban conflictos estratégicos con las políticas de software abierto del gobierno.

El problema radicaba en que GitHub es un servicio propietario, lo que viola el principio de preferir software de código abierto cuando existe una alternativa equivalente. GitLab, aunque su Community Edition es libre, mantiene un modelo open-core donde las funcionalidades avanzadas (CI/CD, autenticación avanzada, etc.) pertenecen a su rama Enterprise, creando dependencia de un proveedor. Estas limitaciones impulsaron la búsqueda de una solución que garantizara soberanía tecnológica, transparencia total y ausencia de vendor lock-in. La elección recayó en Forgejo, una bifurcación de Gitea con gobernanza comunitaria y licencia GPLv3+, que cumple con los requisitos de software exclusivamente libre.

Qué ocurrió

El proceso de selección, documentado por Vlug en su blog oficial, siguió un enfoque técnico riguroso. Se evaluaron tres alternativas principales:

1. GitHub Enterprise: descartado por su naturaleza propietaria (licencia comercial).
2. GitLab Community Edition (CE): avanzó en la evaluación, pero el modelo open-core generaba incertidumbre sobre el futuro de las funcionalidades críticas.
3. Forgejo: seleccionado por su licencia 100% GPLv3+, gobernanza democrática bajo Codeberg e.V. (una fundación sin fines de lucro), y ausencia de planos empresariales o upsells.

El 24 de abril de 2026, se lanzó en fase piloto code.overheid.nl, una instancia autohospedada de Forgejo ejecutándose sobre infraestructura gubernamental gestionada por SSC-ICT (DAWO). El lanzamiento no fue un despliegue tradicional, sino una invitación a colaborar: se enmarcó como un proyecto colectivo para construir la plataforma junto a los desarrolladores que la usarían. Los equipos pioneros fueron incentivados a reportar issues y abrir pull requests directamente en la instancia, siguiendo el modelo de desarrollo abierto que la plataforma promueve.

Componentes técnicos clave del despliegue

• Base de datos: PostgreSQL 15 (versión estable en abril 2026).
• Backend: Forgejo v1.21.0-0 (versión LTS en el momento del lanzamiento).
• Frontend: Interfaz de usuario basada en Gitea 1.21.0, con personalizaciones para integración con sistemas de autenticación gubernamentales (SAML2/OIDC).
• Infraestructura: Servidores bare metal en centros de datos soberanos de los Países Bajos, con balanceadores de carga Nginx y almacenamiento en Ceph.
• Autenticación: Integración con DAWO SSO, un sistema de autenticación única basado en Keycloak, configurado para cumplir con el estándar eIDAS de la UE.

Repositorios destacados en la fase piloto

La plataforma ya alberga contenido crítico, entre ellos:

• Abacus: software de conteo de votos y distribución de escaños, desarrollado por Kiesraad (Consejo Electoral Holandés).
• e-KS: sistema de nominación electrónica de candidatos.
• DAWO: iniciativa del Ministerio del Interior para un «lugar de trabajo digital autónomo».
• DigiD: código fuente liberado bajo una orden de acceso a la información pública.

En menos de tres meses desde el lanzamiento, múltiples instituciones se unieron al piloto:

• Ministerios nacionales: Finanzas, Asuntos Exteriores, Agricultura, Interior.
• Municipios: La Haya, Utrecht, Leiden, Arnhem.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps: soberanía y control

La migración a una instancia autohospedada de Forgejo resuelve problemas críticos en entornos gubernamentales:

1. Dependencia de proveedores: GitHub y GitLab operan bajo términos de servicio que pueden cambiar, afectando el acceso a repositorios en cualquier momento (ejemplo: bloqueos geográficos o políticas de contenido).
2. Compliance: Las leyes de soberanía digital en la UE (como el Reglamento eIDAS) exigen que los datos sensibles de ciudadanos se almacenen en infraestructura bajo jurisdicción europea. Una instancia autohospedada cumple este requisito sin depender de nubes públicas extranjeras.
3. Costos a largo plazo: Aunque GitLab CE es gratuito, las licencias Enterprise escalan exponencialmente. En un gobierno con cientos de agencias, esto puede significar millones en ahorros anuales.

Para equipos de Seguridad: reducción de la superficie de ataque

• Menor exposición a CVEs: GitHub y GitLab tienen historiales recientes de vulnerabilidades críticas (ejemplo: CVE-2023-22741 en GitLab afectando autenticación OAuth). Una instancia autohospedada permite aplicar parches en horas, no en días.
• Control de datos: El código fuente de sistemas electorales (como Abacus) no sale del perímetro nacional, reduciendo riesgos de fugas o ataques dirigidos.
• Auditoría continua: Forgejo permite inspeccionar el código fuente completo, algo imposible en servicios SaaS donde solo tienes acceso a APIs limitadas.

Para equipos de Cloud: flexibilidad y cumplimiento

• Evitar vendor lock-in: La infraestructura en DAWO usa Kubernetes (versión 1.28) con CNI Calico, desplegado sobre OpenStack. Esto permite migrar a otros proveedores de IaaS si es necesario, sin depender de servicios de AWS, Azure o GCP.
• Cumplimiento con estándares: La plataforma cumple con ISO/IEC 27001 y NEN-ISO/IEC 27018 (protección de datos en la nube), requisitos obligatorios para licitaciones públicas en Países Bajos.

Detalles técnicos

Arquitectura de la instancia Forgejo en DAWO

La infraestructura sigue un diseño high-availability con los siguientes componentes:

El equipo de DAWO documentó los siguientes pasos críticos para migrar repositorios desde GitHub/GitLab a Forgejo:

1. Exportación de repositorios:

   gh repo list --visibility public --source --limit 1000 | while read repo; do
     gh repo clone "$repo" -- --mirror
   done
   

Para repositorios privados, se usó el CLI de GitLab:

   gitlab-rake gitlab:backup:create
   

1. Migración de issues y pull requests:

– Los milestones se convirtieron a etiquetas (migrated:issue) para trazabilidad.

1. Integración con CI/CD:

– Ejemplo de pipeline para Go:

     pipeline:
       test:
         image: golang:1.21
         commands:
           - go test ./...
           - go build -o output .
     

Gobernanza y futuras mejoras

Forgejo es mantenida por Codeberg e.V., una organización sin fines de lucro con sede en Berlín. El proyecto sigue un modelo de gobernanza abierto:

• Roadmap público: Disponible en forgejo.org/roadmap.
• Proceso de releases: Cada 3 meses (ciclo LTS similar a Gitea).
• Seguridad: Recepción de vulnerabilidades a través de HackerOne.

El equipo de DAWO planea incorporar en 2026:

• Replicación geográfica entre centros de datos en Ámsterdam y Róterdam.
• Integración con SCIM para sincronización automática de usuarios desde el directorio activo.
• Soporte para GPG en commits (actualmente en desarrollo en Forgejo).

Qué deberían hacer los administradores y equipos técnicos

Para equipos gubernamentales o grandes organizaciones

1. Evaluar alternativas FOSS:

– Verificar compatibilidad con LDAP/Active Directory y SAML2.

1. Planificar la migración:

– Herramientas:

– Para repositorios pequeños: git push --mirror.

– Para repositorios grandes: usar rsync + git bundle para minimizar tiempo de inactividad.

1. Infraestructura:

– CPU: 4 núcleos (recomendado 8).

– RAM: 8 GB (con picos de 16 GB durante operaciones de garbage collection).

– Almacenamiento: 50 GB por cada 1000 repositorios (Git LFS requiere espacio adicional).

Para equipos de DevOps en empresas privadas

1. Análisis de riesgos:

– Calcular costos de licencias Enterprise en GitLab a 3-5 años.

1. Despliegue progresivo:

– Usar Forgejo como caché para repositorios públicos (ejemplo: clonar Kubernetes upstream para reducir latencia).

1. Automatización:

– Ejemplo con Forgejo + Drone:

     pipeline:
       sync:
         image: alpine/git
         commands:
           - git remote add github https://github.com/ORG/REPO.git
           - git push --mirror github
     

Para equipos de Seguridad

1. Hardened deployment:

– Limitar acceso a la API solo a rangos de IP internos.

– Auditar regularmente con herramientas como Trivy o Grype para detectar CVEs en dependencias Go.

1. Monitoreo:

– Ejemplo de dashboard en Grafana:

     rate(forgejo_api_request_duration_seconds_sum[5m]) / rate(forgejo_api_request_duration_seconds_count[5m])
     

Conclusión

La decisión del gobierno holandés de migrar a Forgejo no es un gesto político, sino una estrategia técnica con fundamentos concretos:

• Soledad de código: Elimina dependencias de proveedores privados y garantiza que el código gubernamental permanezca accesible y modificable por los ciudadanos.
• Colaboración interinstitucional: Reduce la duplicación de esfuerzos entre ministerios y municipios, centralizando el desarrollo en una plataforma común.
• Cumplimiento normativo: Cumple con regulaciones de soberanía digital europea sin sacrificar funcionalidades técnicas.

Para equipos de DevOps e infraestructura que enfrentan desafíos similares —ya sea en el sector público o en empresas con requisitos estrictos de compliance—, este caso ofrece un modelo reproducible. La clave está en empezar con un piloto pequeño, documentar cada paso de la migración, y priorizar soluciones que den control total sobre el código y los datos.

Forgejo no es la única opción (Gitea y GitTea también son viables), pero su gobernanza comunitaria y ausencia de vendor lock-in lo convierten en una alternativa robusta para entornos donde la soberanía tecnológica no es negociable.

FIN