⏱️ Lectura: 13 min
La idea de un forge federado volvió al centro del debate en abril de 2026. Después de varias semanas con caídas intermitentes en GitHub, fallos de autenticación y problemas con GitHub Actions reportados desde múltiples regiones, una parte de la comunidad open source comenzó a hacerse en voz alta una pregunta incómoda: ¿es razonable que el 90% del código abierto del mundo dependa de un único proveedor centralizado? El proyecto Tangled, construido sobre AT Protocol, publicó un manifiesto reclamando lo que muchos vienen pidiendo desde hace una década: una federación de forges donde cada uno hospede su propio servidor git y, aun así, pueda colaborar con repositorios alojados en máquinas ajenas.
📑 En este artículo
- Qué pasó: GitHub tropieza y la conversación reavive
- Contexto e historia: del email a los forges
- Cómo funciona Tangled bajo el capó
- Datos y cifras: por qué el problema es real
- Impacto y análisis: qué cambia con un forge federado
- Qué sigue: el camino realista a 2027
- Cómo empezar a experimentar hoy
- Preguntas frecuentes
- Referencias
El planteo no es nuevo. Desde el inicio, la colaboración en código combinó dos protocolos: uno para transferir el código y otro para comunicarse alrededor de él. El flujo clásico de Linus Torvalds y la lista de correo del kernel usa git para mover los commits y email para discutir parches. GitHub reemplazó el segundo carril por una web propietaria. ForgeFed lleva años explorando ActivityPub. Tangled propone una tercera vía con AT Protocol, el mismo stack detrás de Bluesky. La promesa: que un forge federado se sienta tan natural como mandar un parche por email pero con la ergonomía social a la que GitHub nos acostumbró.
Qué pasó: GitHub tropieza y la conversación reavive
Durante abril de 2026 la página de status de GitHub registró varios incidentes de impacto significativo: degradación en GitHub Pages, problemas con webhooks, lentitud en operaciones de clone para repositorios grandes y un par de eventos relacionados con el plano de control de Actions. Ninguno fue catastrófico de forma aislada, pero la acumulación encendió alarmas. Para proyectos críticos —el kernel de Linux migra parches por correo, pero la mayoría de las librerías que sostienen npm, PyPI y crates.io viven en GitHub— una hora caída es una hora en la que millones de pipelines se detienen.
En ese contexto, el equipo de Tangled publicó “we need a federation of forges”, un texto corto pero contundente. La tesis es directa: los sistemas centralizados terminan colapsando, y los protocolos que sobreviven al paso del tiempo son los que descentralizan responsabilidades. Email, git e IRC siguen vivos décadas después de ser creados. Las plataformas web propietarias del mismo período, en cambio, han ido y venido. La conclusión que sacan es práctica: no se trata de matar a GitHub, sino de no depender de un único punto de fallo para colaborar en software libre.
Contexto e historia: del email a los forges
Para entender por qué un forge federado vuelve a ser noticia, conviene repasar la línea histórica.
- Era email + git (2005-2008) — git nace en 2005 con la salida del kernel de Linux de BitKeeper. La comunicación gira en torno a listas de correo: parches enviados con
git format-patch, revisados congit am, discutidos en hilos públicos. Este flujo todavía manda en proyectos como el kernel, Postgres y Git mismo. - Era GitHub (2008-2020) — GitHub estandariza el pull request, las issues y los releases dentro de una web única. La curva de adopción se acelera porque la UX baja la barrera de entrada para un colaborador casual. El precio es centralización: tu identidad, tus issues, tus reviews y tu CI viven en un solo proveedor.
- Era de los forges autoalojados (2014-presente) — Gitea, Forgejo, GitLab self-hosted y Sourcehut crecen como respuesta. Pero todavía falta lo más importante: poder hacer fork y abrir un PR entre instancias diferentes.
- Era de la federación (2020-2026) — ForgeFed propone vocabulario ActivityPub para repositorios. Forgejo lo está implementando. Tangled aparece con una apuesta paralela usando AT Protocol.
El punto crítico de toda esta evolución es el mismo: federar significa que el repositorio puede vivir donde sea, pero el evento social —issue, PR, review, fork— viaja entre servidores con identidad verificable. Sin federación, autoalojar tu git es como tener tu propio servidor de email pero solo poder enviarle correos a vos mismo.
Cómo funciona Tangled bajo el capó
Tangled le llama knots a los servidores git que participan de la red. Cada knot es, en esencia, una instancia que aloja repositorios y expone los protocolos git tradicionales: git clone, git push y git pull funcionan exactamente igual que con cualquier otro forge. La diferencia está en la capa de eventos sociales —issues, pull requests, follows, stars— que viaja por AT Protocol.
AT Protocol fue diseñado para Bluesky con tres ideas centrales: identidad portable mediante DIDs, almacenamiento personal de datos en repositorios PDS y federación basada en eventos firmados criptográficamente. Aplicado a un forge, eso significa que tu identidad de desarrollador no pertenece al servidor donde abriste el primer issue: pertenece a vos, y la podés mudar a otro knot sin perder tu historial.
El equipo de Tangled describe el flujo así:
$ git clone https://knot1.example/usuario/proyecto
$ cd proyecto
$ git checkout -b feature/login
# editar archivos, hacer commits
$ git push fork feature/login
# abrir un PR contra el repo original alojado en knot1
# desde tu propio knot personal en knot2.example
$ tangled pr open --base knot1.example/usuario/proyecto \
--head knot2.example/yo/proyecto:feature/loginEl comando tangled pr open emite un evento firmado con tu DID que se publica en la red AT. El knot del repositorio destino lo recibe, lo verifica y lo asocia a un PR local. Issues y comentarios funcionan de manera análoga. Las llaves SSH y las invitaciones a colaborar se distribuyen como registros AT, no como filas en una base de datos central.
Datos y cifras: por qué el problema es real
La centralización del open source no es una percepción: es medible. Algunas cifras que ayudan a dimensionar la dependencia actual:
- Más de 100 millones de desarrolladores registrados en GitHub al cierre de 2025, según datos públicos de la propia compañía.
- 420+ millones de repositorios alojados en la plataforma, contando públicos y privados.
- ~92% de proyectos open source con tracker público usan GitHub Issues o GitHub Discussions, según mediciones cruzadas hechas sobre el archivo de OpenSSF.
- Cada caída relevante de GitHub Actions se traduce en miles de pipelines bloqueados; en el incidente del 22 de marzo de 2026, npm reportó retrasos de hasta seis horas en publicaciones automatizadas.
⚠️ Ojo: que GitHub funcione el 99,9% del tiempo no resuelve el problema de fondo. La discusión no es de uptime, es de soberanía: quién decide qué proyectos pueden existir, qué cuentas se suspenden y qué bloqueos geográficos se aplican.
En 2019, GitHub bloqueó cuentas de desarrolladores en Crimea, Irán, Siria, Cuba y Corea del Norte por sanciones de Estados Unidos. Aunque la situación se relajó después, dejó claro que un forge centralizado opera bajo la jurisdicción de un solo país. Para América Latina, eso es relevante: cualquier cambio en política exterior estadounidense puede dejar afuera a un proyecto regional sin previo aviso.
Impacto y análisis: qué cambia con un forge federado
El impacto inmediato de un forge federado exitoso no es reemplazar a GitHub. Es ofrecer una salida creíble si un día hace falta. Esa sola opcionalidad cambia la dinámica:
1. Resiliencia operativa
Si tu organización corre su propio knot, una caída de GitHub no detiene tus reviews internas ni tu CI. Los integrantes externos pueden seguir abriendo PRs desde otros knots. Es la misma lógica que llevó a empresas a duplicar registros DNS y a no depender de un único proveedor cloud.
2. Identidad portable
El historial de un desarrollador deja de ser propiedad del forge. Si te mudás de proveedor, tus contribuciones, follows y stars te siguen porque están firmadas con tu DID, no almacenadas en una tabla de Postgres ajena.
3. Autoalojamiento útil
Hoy correr Gitea o Forgejo en un VPS es trivial, pero los proyectos terminan replicando el repo en GitHub para que los colaboradores casuales no tengan que crear una cuenta más. La federación elimina ese roce: el contribuyente abre PR desde su knot favorito.
4. Riesgo: fragmentación
El contraargumento clásico es que la federación fragmenta. Si Tangled, ForgeFed y un eventual nuevo protocolo de Codeberg se desarrollan en paralelo sin acordar un esquema común, el ecosistema termina con tres redes que no se hablan entre sí. Es exactamente lo que pasa hoy entre Mastodon (ActivityPub) y Bluesky (AT Protocol). Para el mundo del código, donde ya existe la fricción cultural de que hay quienes prefieren correo y quienes prefieren web, multiplicar protocolos podría ser contraproducente.
💭 Clave: la federación no es magia: requiere acuerdos de protocolo, herramientas de migración y, sobre todo, masa crítica de proyectos importantes que adopten knots como espejo oficial, no solo como respaldo.
Cómo se ve la arquitectura
flowchart LR
Dev1["Dev en knot A"] -->|push| KnotA["Knot A (git server)"]
Dev2["Dev en knot B"] -->|push| KnotB["Knot B (git server)"]
KnotA -- "evento AT: PR abierto" --> ATNet["Red AT Protocol"]
KnotB -- "evento AT: comentario" --> ATNet
ATNet --> KnotA
ATNet --> KnotB
KnotA -. "git pull" .-> KnotBQué sigue: el camino realista a 2027
Tangled reconoce en su propio post que el proyecto está temprano. La hoja de ruta inmediata, según comunicaciones del equipo y discusiones públicas en su instancia, contempla:
- Vouches — un sistema de respaldo entre desarrolladores que ayude a curar la red contra spam y cuentas falsas. Reemplaza, en parte, lo que el verificado azul resolvió en GitHub.
- CI federado — ejecutar pipelines en runners autoalojados pero coordinados por eventos AT. Esto es el verdadero cuello de botella: GitHub Actions es lo que retiene a más de un proyecto que ya querría irse.
- Compatibilidad ForgeFed — algunos integrantes empujan para que Tangled hable también ActivityPub, de modo que un knot federe con instancias Forgejo. Esto sería el equivalente al bridge Mastodon-Bluesky.
- Cliente CLI estable — el comando
tangleddebería cubrir el flujo completo de fork, PR y review sin abandonar la terminal.
💡 Tip: si querés probar Tangled sin migrar nada, montá un knot como espejo de tus repos públicos. git remote add tangled ... y un push periódico te da redundancia gratis y te enseña el flujo sin romper tu setup actual.
Para América Latina hay un ángulo extra: la región históricamente paga el costo de depender de infraestructura cloud del norte. Un knot autoalojado en Buenos Aires, Bogotá o San Salvador acerca el repositorio a sus desarrolladores, reduce latencia y, sobre todo, blinda a comunidades locales contra decisiones unilaterales de plataformas externas. No es casualidad que iniciativas como CONICET (Argentina), Centro Nacional de Computación (Costa Rica) y varios laboratorios universitarios brasileños vengan reclamando hace años infraestructura de código soberana.
Cómo empezar a experimentar hoy
Si querés probar la idea sin esperar al lanzamiento estable, hay tres caminos accesibles:
1. Forgejo con federación experimental
# Linux / macOS
docker run -d --name forgejo \
-p 3000:3000 -p 222:22 \
-v forgejo:/data \
codeberg.org/forgejo/forgejo:8
# Windows (PowerShell)
docker run -d --name forgejo `
-p 3000:3000 -p 222:22 `
-v forgejo:/data `
codeberg.org/forgejo/forgejo:8Una vez arriba, activá el módulo de federación experimental en app.ini y registrá tu instancia contra otra Forgejo amigable.
2. Knot de Tangled (alpha)
El equipo publica binarios precompilados y un Dockerfile en su repo principal. Requiere una identidad AT Protocol, que podés crear con tu cuenta de Bluesky o con un PDS propio.
3. Espejo de repos en Sourcehut
Sourcehut no es federado, pero ofrece el flujo email-based clásico bien implementado. Tener un espejo ahí es una forma de practicar el mundo descentralizado sin depender de protocolos jóvenes.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es exactamente un forge federado?
Un forge federado es una plataforma de colaboración en código donde el repositorio puede vivir en un servidor independiente y, aun así, recibir issues, pull requests y comentarios desde usuarios alojados en otros servidores. Es la misma idea que ya funciona con email entre Gmail y un servidor propio.
¿Tangled reemplaza a GitHub?
No, al menos no en el corto plazo. Tangled es un experimento alpha en 2026. Su objetivo realista es ofrecer una alternativa creíble para proyectos que quieran soberanía sobre su infraestructura, no desplazar a GitHub de la noche a la mañana.
¿En qué se diferencia Tangled de ForgeFed?
Ambos buscan federar forges, pero usan protocolos distintos. ForgeFed se apoya en ActivityPub (el mismo de Mastodon). Tangled usa AT Protocol (el de Bluesky). En la práctica, eso impacta cómo se firma la identidad y cómo se distribuyen los eventos entre servidores.
¿Mi código está más seguro en un forge federado?
No automáticamente. Un forge autoalojado o federado te da control sobre el plano de gestión, pero la seguridad operativa depende de cómo administres tu servidor. La ventaja es de soberanía y resiliencia, no de seguridad criptográfica intrínseca.
¿Puedo migrar mi repo de GitHub sin perder historial?
Sí. Git es agnóstico al servidor: git clone --mirror seguido de git push --mirror a tu nuevo knot mueve commits, ramas y tags. Lo que no se migra automáticamente son issues, PRs y reviews, y ahí es donde la federación todavía está madurando.
¿Qué pasa si mi knot deja de existir?
El código sigue clonable mientras alguien tenga una copia (eso es git). Tu identidad AT Protocol también se preserva si tu PDS sigue activo o si moviste la identidad antes de que el knot cayera. Es un argumento extra a favor de hacer espejos cruzados entre instancias amigas.
Referencias
- Tangled blog — we need a federation of forges — Manifiesto original del equipo de Tangled sobre la necesidad de federar los forges.
- ForgeFed — Especificación complementaria que extiende ActivityPub para repositorios git, issues y pull requests.
- AT Protocol — Documentación oficial del protocolo que sustenta Bluesky y, ahora, Tangled.
- Forgejo — Fork comunitario de Gitea que está implementando federación basada en ActivityPub.
- Hacker News — Discusiones técnicas frecuentes sobre incidentes de GitHub y alternativas federadas.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios