Lanzamiento HN: Diversion (YC S22) – Alternativa Git nativa en la nube

Discusión en Hacker News ↗

Una startup respaldada por YC que presentó Diversion como una “alternativa Git nativa en la nube” recibió reacciones mixtas de desarrolladores. Muchos estuvieron de acuerdo en que la UX de Git, el manejo de activos binarios grandes y su idoneidad para el desarrollo de videojuegos y otros flujos de trabajo con muchos medios dejan vacíos reales, pero criticaron el mensaje de Diversion centrado en denigrar a Git, su diseño centralizado y solo en la nube, y la falta de código abierto o autoalojamiento como barreras importantes de confianza y adopción. El hilo converge en que hay espacio para nuevos modelos de control de versiones—especialmente para activos grandes y no programadores—pero el éxito dependerá de una diferenciación clara frente a Git/Perforce, una sólida historia de uso offline y seguridad, y una gobernanza creíble de la tecnología central.

Posicionamiento y mercado objetivo

  • Muchos sostienen que Diversion en realidad compite con el hosting de Git y con Perforce/Plastic, no con Git en sí.
  • Se sugiere con fuerza centrar el mensaje en estudios de videojuegos, binarios grandes y flujos de trabajo para no programadores, en lugar de “Git es malo”.
  • Varios ven potencial específicamente como una alternativa más simple y cloud-first a Perforce para estudios de videojuegos pequeños/medianos y equipos creativos.

Git: crítica vs. defensa

  • Críticas:
    • Git es conceptualmente complejo y propenso a errores para quienes no son expertos; comandos como push --force y reset --hard se ven como “footguns”.
    • Mala UX para quienes no programan (artistas, científicos de datos, etc.).
    • Soporte nativo débil para archivos binarios grandes y repositorios muy grandes; Git LFS se percibe como torpe y frágil a escala.
  • Defensas:
    • La pérdida real de datos es difícil debido a reflog y a los clones distribuidos; la historia de “destruido un mes de trabajo” es ampliamente cuestionada y luego se matiza.
    • Muchos problemas se atribuyen a mala configuración, poca formación o flujos de trabajo deficientes, no a Git en sí.
    • Las funciones existentes (shallow clones, filters, fsmonitor, herramientas para monorepos) alivian algunas preocupaciones de escalabilidad.

Nativo en la nube, centralización y trabajo sin conexión

  • El diseño de Diversion (serverless, API REST, estado siempre en la nube) es elogiado por su escalabilidad, sincronización en tiempo real e integración más fácil con CI/desarrollo en la nube.
  • Los críticos ven “cloud-native” como:
    • Una regresión respecto a los VCS distribuidos con capacidad offline.
    • Un único punto de fallo arriesgado y una mala opción para redes inestables (trabajo remoto, aviones, algunas regiones).
    • Posible dependencia del proveedor, especialmente en AWS, y un enfoque problemático para estudios con requisitos estrictos de on‑premise/seguridad.

Seguridad, apertura y confianza

  • Los datos se cifran en tránsito y en reposo, pero no de extremo a extremo; algunos consideran esto un bloqueo para código sensible.
  • Muchos insisten en que no confiarán el control de código fuente central a una startup cerrada y solo en la nube; hay una fuerte presión para abrir el código fuente (idealmente con copyleft) y admitir autoalojamiento/nube privada.

Funciones deseadas y sugerencias

  • Hay gran interés en:
    • Soporte de primera clase para binarios grandes, bloqueo de archivos (especialmente entre ramas), checkouts parciales y operaciones rápidas en repositorios grandes.
    • Mejores GUIs y “guardrails” para no expertos, flujos de trabajo opinados y conceptos simplificados frente a Git.
    • Integración más rica: CLI amigable con CI, diffs semánticos/a nivel de AST, hooks integrados, patch stacking y versionado más amplio de documentos/configuración.
  • Tono general: escepticismo sobre el pitch actual y el modelo de confianza, pero reconocimiento claro de que el VCS—especialmente para binarios y no desarrolladores—sigue siendo un problema abierto que merece ser abordado.