Steve Klabnik construye un VCS que habla Git pero no almacena repositorios Git

Steve Klabnik lleva más de un año trabajando en East River Source Control y ahora ha contado en qué anda: un sistema de control de versiones que se usa con cualquier cliente de Git, habla el protocolo de Git, pero no guarda repositorios de Git por dentro. No hay anuncio de producto, ni fecha, ni demo. Lo que hay es una explicación de por qué creen que Git se queda corto y cómo piensan puentearlo.

El diagnóstico es conocido para cualquiera que haya visto crecer un repositorio en los últimos dos años. El desarrollo con agentes genera más código en menos tiempo, multiplica las ramas activas y mete presión en los merges. Los agentes además trabajan mejor con monorepos, porque acceden a más contexto de una sola vez, y necesitan clones rápidos cuando levantan entornos aislados en la nube. Lo que antes era un problema de plantilla grande, dice Klabnik, ahora le toca a cualquiera.

Un puente, no una ruptura

El diagrama que publican es casi idéntico al de cualquier proveedor de Git: cliente, protocolo, capa de servicio, almacenamiento. La diferencia está al final de la cadena. Donde otros guardan repositorios Git en disco, ellos meten un motor de almacenamiento propio tras un puente. También hay una API GraphQL que no aparece en el dibujo.

Las dos consecuencias que destacan: el sistema escala en horizontal de una forma que no permite una arquitectura donde el repositorio Git es la fuente de verdad, y cada cliente tiene su propio despliegue, así que el uso de otras empresas no condiciona el tuyo.

Sobre Git son directos: "no creemos que Git sea el futuro del control de código fuente". Argumentan que está diseñado para las restricciones de 2005, no para las de 2025 y menos para las de 2035. Nació para el kernel de Linux, un proyecto abierto, y por eso le faltan cosas que sí necesita una organización que no comparte su código. El kernel 7.2 ronda los 43 millones de líneas, pero en la industria hay monorepos de miles de millones de líneas desde hace años. A esa escala, las decisiones de diseño pesan.

El problema para cualquier alternativa es la inercia del ecosistema. Como resume el propio texto, no es SvnOps, es GitOps: demasiadas herramientas hablan Git. De ahí la estrategia de hablar el protocolo en lugar de pedir a nadie que cambie de cliente.

Jujutsu y lo que falta

Ese enfoque abre la puerta a hablar varios protocolos a la vez, y ahí entra Jujutsu, del que se declaran fans. Es la vía para features que Git no cubre sin obligar a migrar de golpe.

A la pieza le falta lo que suele faltar en un texto de intenciones: ni un número de rendimiento, ni una comparación medida, ni el modelo de licencia, ni si el motor de almacenamiento se podrá autoalojar. Klabnik reconoce que el sector es conservador con el control de versiones, y con razón: el código es de lo más valioso que tiene una empresa y cambiar la herramienta que lo guarda es una decisión de años. Habrá que ver qué enseñan cuando anuncien algo de verdad.