Un hilo de debate en una comunidad de desarrolladores pregunta qué funcionalidades de GitHub resultan imprescindibles antes de plantearse una migración a otra plataforma de alojamiento de código (forge). El autor del hilo está construyendo juju.bi, un forge experimental basado en conceptos de Jujutsu, como el seguimiento de cambios mediante change-id y la operación evolog. Acaba de lanzar una versión alpha primigenia que está usando en su propio equipo, y su objetivo a corto plazo es pulir la experiencia para pequeños grupos con repositorios privados antes de abordar repos públicos.
Los participantes coinciden en que las funciones puramente técnicas —pull requests, gestión de equipos, cuentas de organización— son la base, pero el verdadero bloqueo no es tanto el conjunto de características como la ausencia de dependencias externas: la publicación confiable con OIDC en registros como npm, JSR o crates.io exige acuerdos con cada uno de esos ecosistemas. Además, valoran disponer de CI/CD gratuito en cantidad razonable, algo en lo que GitHub mantiene una ventaja considerable.
Varios comentarios defienden que los forges alternativos como Forgejo (Codeberg) y SourceHut ya cubren las necesidades reales y proponen, en cambio, priorizar criterios antimonopolio: evitar el lock-in del proveedor, impedir la degradación progresiva del servicio (enshittification) y facilitar la salida de la plataforma. Otros usuarios sugieren ir más lejos y reivindican herramientas minimalistas como gitweb o cgit, sin cuentas obligatorias, integradas con el sistema y compatibles con flujos de parches sin bifurcación previa, similares al agit flow de Forgejo. El debate ilustra la tensión entre replicar GitHub y diseñar alternativas que reduzcan la dependencia de un único proveedor.