Dejar GitHub y pasarse a Forgejo

 (jorijn.com)
1 puntos por GN⁺ 5 시간 전 | 1 comentarios | Compartir por WhatsApp
  • El motivo directo para dejar GitHub no es la caída de abril de 2026, sino el problema de propiedad del código y los flujos de trabajo que se ejecutan en GitHub
  • Desde agosto de 2025, GitHub quedó integrado en la división CoreAI de Microsoft sin un CEO propio, y el código pasó a quedar bajo la organización de IA de Microsoft
  • Desde abril de 2026, Copilot Free, Pro y Pro+ cambiaron a un esquema de exclusión voluntaria en el que los datos de interacción se usan por defecto como datos de entrenamiento
  • GitHub y Microsoft son empresas de EE. UU., por lo que están bajo la jurisdicción de FISA 702 y la CLOUD Act, y la residencia de datos en la UE por sí sola no resuelve el problema
  • Forgejo v15 LTS se ejecuta en una sola NUC de code.jorijn.com, y el runner está aislado con KVM, gVisor, reconstrucciones semanales y filtro de salida

La razón para dejar GitHub no es la caída, sino la propiedad

  • La caída de abril de 2026 fue lo bastante grave para los desarrolladores, pero la razón central para dejar GitHub no es la caída en sí, sino la propiedad del código y de los flujos de trabajo que se ejecutan en GitHub
  • El 27 de abril de 2026, el Ministerio del Interior de los Países Bajos hizo el soft launch de code.overheid.nl, una instancia autohospedada de Forgejo para el código fuente del gobierno
    • El project manager Boris Van Hoytema explicó que la plataforma surgió del requisito de que los ministerios publiquen legalmente el código fuente en un “lugar que posean”
    • Forgejo fue elegido por encima de GitLab porque es completamente open source y ofrece la libertad necesaria para la soberanía digital
  • El host Git predeterminado para el código personal también se movió a code.jorijn.com, donde Forgejo v15 LTS corre en una configuración reforzada sobre una sola NUC
    • Algunos repositorios ya se movieron y el resto está en espera
    • Cuando termine la migración, el plan es archivar los repositorios públicos de GitHub y hacer que cada archivo apunte a la nueva ubicación

Caídas y carga de IA

  • El 23 de abril de 2026, la ruta de código squash-merge de merge queue revirtió silenciosamente commits ya fusionados en 658 repositorios y 2,092 pull requests, tras un despliegue incompleto detrás de un feature flag
    • Empresas como Modal y Zipline recuperaron los datos manualmente
    • Cuatro días después, un clúster de Elasticsearch sobrecargado dejó fuera de servicio Pull Requests, Issues y Packages durante más de 6 horas
  • Solo en febrero de 2026 se registraron 37 incidentes, incluido uno de 3 horas y 40 minutos en el que cayeron al mismo tiempo Actions, Copilot Coding Agent, Code Review, CodeQL, Dependabot y Pages
  • El 1 de octubre de 2025 también hubo una caída de 10 horas de runners de macOS
  • Según el recuento de IncidentHub, entre mayo de 2025 y abril de 2026 GitHub registró 257 incidentes y 48 caídas mayores, con alrededor de 112 horas totales de inactividad
  • Al disculparse el 28 de abril, el CTO de GitHub, Vlad Fedorov, dijo que haría falta aumentar la capacidad en 30 veces para seguir el ritmo de la carga provocada por el “agentic AI workflow growth” desde diciembre de 2025
    • Los problemas de confiabilidad se interpretan como un resultado secundario de la expansión de funciones de IA
    • GitHub está empujando aún más fuerte las funciones de IA, en vez de frenarlas
  • The Pragmatic Engineer señaló que GitLab, Bitbucket, Vercel, Linear y Sentry no pasaron por el mismo año
    • Como estas también están bajo presión por la demanda de los desarrolladores, el patrón de caídas de GitHub parece ser un problema particular de GitHub

Cambios organizacionales en GitHub

  • El 11 de agosto de 2025, Thomas Dohmke dejó el cargo de CEO de GitHub, y Microsoft no nombró un CEO sucesor
  • GitHub fue absorbido por la división CoreAI de Microsoft
  • Los ingresos, la ingeniería y el soporte de GitHub reportan a la división de desarrolladores de Microsoft bajo Julia Liuson
    • El CPO de GitHub reporta al VP de plataforma de IA de Microsoft
    • La marca sigue, pero el liderazgo independiente desapareció
  • La evaluación de que Microsoft operó GitHub con cierta distancia entre 2018 y 2024 fue en la práctica correcta, pero desde agosto de 2025 esa premisa se volvió difícil de sostener
  • Hoy, hacer push de código a github.com significa hacer push de código a una unidad bajo la organización de IA de Microsoft

Cambio en la configuración predeterminada de datos de entrenamiento de Copilot

  • El 25 de marzo de 2026, GitHub anunció cambios a su declaración de privacidad que entraron en vigor el 24 de abril
    • Los datos de interacción de los usuarios de Copilot Free, Pro y Pro+, en particular entradas, salidas, fragmentos de código y contexto relacionado, se usan para entrenar y mejorar modelos de IA a menos que el usuario lo rechace
  • El cambio clave es que no es opt-in, sino opt-out
    • Los usuarios de Copilot Free, Pro y Pro+ contribuyen al entrenamiento del modelo si no lo desactivan en la página de configuración de Copilot
  • No existe bloqueo a nivel de repositorio
    • Los administradores no pueden indicar a GitHub que no aprenda de las interacciones dentro de un repositorio específico
    • El opt-out es una configuración por cuenta de usuario, por lo que cada colaborador debe elegirlo por su cuenta
    • Como resultado, si un usuario de Copilot Free/Pro/Pro+ trabaja con un repositorio, la base de código puede convertirse en material de entrenamiento sin importar la licencia
  • La excepción para repositorios privados también se aplica de forma limitada
    • GitHub dice que no usa para entrenamiento el contenido “at rest” de repositorios privados
    • Pero sí recopila los “code snippets and interaction context” generados mientras se usa Copilot dentro de un repositorio privado
    • La frontera entre el “código en reposo” y los “fragmentos generados durante la edición” es difusa
  • Los clientes de Copilot Business y Copilot Enterprise quedan excluidos porque se les aplican acuerdos de protección de datos separados
    • La estructura es que, si pagas lo suficiente, tus interacciones no son datos de entrenamiento; si no, sí lo son
  • El interés estratégico de GitHub en los datos de interacción de los usuarios ya no es un elemento opcional, sino un elemento estructural

El riesgo jurisdiccional no se resuelve con la ubicación de los datos

  • GitHub Inc. y Microsoft Corp. son empresas de Estados Unidos, y los datos que poseen quedan dentro del alcance de leyes estadounidenses, incluidas la FISA Section 702 y la CLOUD Act de 2018
    • Ambas leyes pueden aplicarse sin importar dónde se encuentren físicamente los datos
  • La Section 702 fue reautorizada por dos años el 20 de abril de 2024, y sigue vigente mediante una prórroga de 45 días firmada a finales de abril de 2026
    • Permite la recopilación por parte de agencias de inteligencia de Estados Unidos dirigida a personas no estadounidenses a través de proveedores de servicios de comunicaciones electrónicas ubicados en Estados Unidos
  • La CLOUD Act puede obligar a empresas con sede en Estados Unidos a entregar datos almacenados en cualquier parte del mundo
  • GitHub anunció en octubre de 2024 la disponibilidad general de la residencia de datos en la UE para Enterprise Cloud
    • Esto aborda el problema de la ubicación de los datos, pero no resuelve el problema jurisdiccional
    • La exposición a la CLOUD Act sigue la estructura de control corporativo, no la ubicación geográfica
  • En una audiencia del Senado francés en junio de 2025, un abogado de Microsoft respondió bajo juramento que no podía garantizar que los datos franceses almacenados en centros de datos europeos de Microsoft estuvieran a salvo de un acceso silencioso del gobierno de Estados Unidos
  • Mientras el código esté en github.com, ese código está dentro del ámbito legal de Estados Unidos
    • La residencia de datos en la UE puede dar tranquilidad, pero no es una solución

La elección del gobierno neerlandés por code.overheid.nl

  • El trasfondo legal de la decisión del gobierno neerlandés es la política “Open, tenzij”, vigente desde 2020
    • El software desarrollado con fondos públicos pasa a ser de código abierto por defecto, salvo que se requieran seguridad o confidencialidad
    • Para cumplir con eso, los ministerios necesitaban un lugar para publicar código que realmente controlaran
  • La Comisión Europea opera desde septiembre de 2022 su propio code.europa.eu, basado en GitLab y autoalojado
  • El openCode de Alemania también está basado en GitLab
  • El code.gouv.fr de Francia no es un forge propio, sino un agregador que indexa repositorios alojados en otros lugares
  • El gobierno neerlandés eligió deliberadamente Forgejo en lugar de GitLab
    • Según OSOR, la razón fue que Forgejo es completamente de código abierto, no tiene separación open-core y ofrece todas las libertades necesarias para la autonomía digital
    • Van Hoytema agregó que la hoja de ruta de Forgejo estaba “way more aligned” que la de las alternativas
  • El gobierno neerlandés no quería solo un forge soberano, sino uno soberano que no quedara encerrado detrás de los niveles premium de un proveedor comercial
  • El gobierno vio la misma estructura del problema y tomó la misma decisión, y la elección de Forgejo ya difícilmente puede verse como una opción periférica

Por qué se eligió Forgejo

  • GitLab también fue considerado seriamente
    • GitLab CE autoalojado es una opción conocida, con un ecosistema comercial más grande y una UI más pulida

  • Licencia

    • GitLab sigue un modelo open core
      • Community Edition tiene licencia MIT, pero muchas funciones deseables en un entorno operativo están en el tier Enterprise con licencia no libre
    • Forgejo se mueve en la dirección opuesta
      • Desde la v9.0 de agosto de 2024, fue relicenciado de MIT a GPLv3+
      • El objetivo explícito es mantener el copyleft y evitar una futura captura comercial del codebase
    • La razón por la que Forgejo se bifurcó de Gitea en diciembre de 2022 también fue que Gitea Ltd controló la marca y el dominio sin consentimiento de la comunidad
      • Esa lección se reflejó en la elección de licencia

  • Gobernanza

    • Forgejo está bajo Codeberg e.V.
      • Codeberg e.V. es una organización sin fines de lucro registrada en Berlín desde septiembre de 2018
      • Tiene una junta elegida por sus miembros, presupuesto público y más de 300,000 repositorios en su instancia alojada
    • Los miembros votan el presupuesto cada año
      • El plan de 2025 fue aprobado con 88 votos a favor, 0 en contra y 1 abstención

  • Lanzamientos y madurez

    • Forgejo v15.0 LTS se lanzó el 16 de abril de 2026
      • Es el lanzamiento número 100 del proyecto
      • El soporte a largo plazo continúa hasta el 15 de julio de 2027
    • Forgejo Actions alcanzó en v15 el nivel necesario
      • Incluye ephemeral runner, OpenID Connect y reusable workflow expansion
    • Desde el fork, los lanzamientos han sido constantes y los informes mensuales siguen activos

  • Límites del ecosistema comercial

    • El ecosistema comercial de Forgejo existe, pero es reducido
    • Actualmente, el producto comercial más pulido es Codey by VSHN
      • Es un Forgejo gestionado con hosting en Suiza, lanzado en Servala en marzo de 2025
      • Empieza en 19 CHF al mes
    • No existe una suscripción de soporte empresarial al estilo Red Hat
    • Si necesitas soporte telefónico 24/7 y un proveedor que se haga responsable, tendrás que montarlo por tu cuenta o esperar

Configuración de code.jorijn.com

  • code.jorijn.com corre en un único Intel NUC en una oficina en casa
    • Tiene 64 GB de RAM
    • Forgejo v15 LTS, Postgres 17 y Traefik corren dentro de Docker
    • Una máquina virtual KVM administrada con Incus corre al lado como runner de Forgejo Actions
  • Más importante que la disposición de Forgejo, Postgres y el reverse proxy es la decisión sobre cómo configurar el runner

El runner es la parte más peligrosa

  • En un forge autoalojado, el forge en sí es la parte fácil; la parte difícil es el entorno donde se ejecutan los trabajos de CI
  • El runner tiene que ejecutar npm install, composer install y pip install todos los días según el calendario de Renovate
    • El objetivo es el lockfile generado en el propio repositorio
    • Eso implica ejecutar lifecycle scripts
    • Cada trabajo puede ejecutar código potencialmente no confiable
  • Existe un riesgo similar al del reciente worm de npm y al ataque a la cadena de suministro de axios, que viajaron a través de dependency bots con auto-merge en menos de una hora
  • La función del runner no es ejecutar código, sino aislar el código que se está ejecutando
    • Se asume que una sola capa de defensa puede fallar, y se diseña para que la siguiente capa absorba ese fallo

Capas de defensa del runner

  • Máquina virtual KVM persistente

    • El runner está dentro de una VM KVM separada, no en un contenedor del host
    • El entorno de trabajo no comparte el kernel del host
    • Para que un CVE del kernel de Linux dentro del runner llegue al NUC, primero tendría que romper el límite de KVM

  • Uso de gVisor como runtime de Docker predeterminado dentro de la VM

    • Los contenedores de trabajo se ejecutan bajo runsc
    • runsc no pasa las llamadas al sistema directamente al kernel del host, sino que las intercepta en espacio de usuario
    • Para escapar del contenedor habría que romper tanto gVisor como la capa de KVM que lo rodea

  • Reconstrucción destructiva semanal

    • Todos los lunes a las 02:00 UTC se elimina la VM completa y se vuelve a crear desde una nueva imagen base de Ubuntu
    • También se vuelve a emitir un nuevo registro de runner persistente hacia Forgejo
    • La imagen base se reconstruye el domingo, por lo que la nueva VM refleja los parches de apt y del kernel de esa semana
    • Ningún estado persistente puede permanecer más de 7 días

  • Filtro de salida nftables del bridge del runner

    • El runner puede acceder a los destinos públicos :443, :80, :22, :53
      • Esto incluye npm, pypi, ghcr y su propio Forgejo accedido por nombre de host público mediante hairpin NAT
    • No puede acceder a 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12
    • Un trabajo comprometido no puede escanear la LAN ni acceder a la interfaz de administración del router ni a otros servicios del host

  • Token de runner con alcance limitado

    • Los dos registros de runner persistente están vinculados, respectivamente, a un único alcance de usuario y a un único alcance de organización
    • La administración usa el scope PAT write:user,write:organization
    • Un token filtrado no puede registrar runners fuera de su alcance ni realizar acciones de alcance admin
    • Las capas están diseñadas intencionalmente para superponerse
    • Cada capa es una valla, y juntas crean un límite en profundidad
    • El aislamiento con KVM, gVisor, la reconstrucción semanal y el registro de runner vinculado al alcance son elementos que Forgejo e Incus soportan de forma nativa

Lo que se perdió

  • Descubribilidad y grafo social

    • GitHub es donde los colaboradores encuentran los repositorios
    • Quien quiera enviar una corrección pequeña a un repositorio público espera trabajar en github.com, no en un dominio desconocido
    • Cuando se complete la mudanza, el plan es archivar cada repositorio público en GitHub y hacer que el README apunte a code.jorijn.com
    • La ruta de descubrimiento se mantiene
      • La gente seguirá encontrando el repositorio en GitHub, verá el aviso de archivo y luego se moverá a la sede canónica
    • Aún no está completo: solo algunos repositorios están en code.jorijn.com y el resto sigue pendiente

  • Compatibilidad frágil del ecosistema de GitHub Actions

    • Forgejo Actions apunta a la familiaridad, no a la compatibilidad
    • La mayoría de las cosas funcionan, pero algunas no
    • El bloque permissions: a nivel de workflow se ignora silenciosamente
    • actions/checkout@v6 rompió el checkout autenticado en runners que no son de GitHub a inicios de 2026, así que quedó fijado en v5
    • actions/upload-artifact@v4 requiere un fork alojado por Forgejo
    • OIDC funciona, pero usa una clave de workflow distinta, enable-openid-connect: true, en lugar de permissions: id-token: write de GitHub
    • Si tus workflows dependen mucho de funciones exclusivas de GitHub, la migración no se resuelve en una sola tarde: se convierte en un proyecto

  • Ausencia de Dependabot

    • Forgejo no tiene Dependabot
    • Renovate se ejecuta en el mismo runner autohospedado cada 3 horas
    • Cumple la misma función, pero requiere más configuración, y la puesta a punto tomó un día

  • Soporte del proveedor 24/7

    • GitHub Enterprise ofrece un número de teléfono y un SLA
    • Forgejo ofrece un issue tracker y una sala de chat
    • Es suficiente para una operación de una sola persona, pero quizá no lo sea para una organización de 200 ingenieros

Cuándo no vale la pena mudarse

  • Si el equipo no tiene ninguna disposición ni capacidad para operar infraestructura, es mejor no mudarse a un Forgejo autohospedado
    • Codey, que es Forgejo administrado, o Codeberg para FOSS, cierran gran parte de la brecha, pero el costo de migración sigue existiendo
  • No encaja si ya invertiste profundamente en funciones exclusivas de GitHub como GitHub Apps marketplace, Codespaces, Copilot Workspace o Advanced Security
    • Forgejo es un forge, no una developer-platform-as-a-service
  • Si tu base de colaboradores depende del grafo social de GitHub, la descubribilidad puede importar más que la propiedad
    • Puedes quedarte donde están los colaboradores, o aceptar la fricción, completar la mudanza, archivar luego los repositorios públicos en GitHub para que apunten a la nueva ubicación y reevaluar más adelante
  • Si no tienes una respuesta operativa confiable para los runners, será difícil mudarte
    • Esta es el área que hay que tratar con más seriedad
    • Si no estás preparado para pensar en aislamiento con KVM, gVisor, nftables y reconstrucciones semanales, es mejor ejecutar los trabajos de CI en un host de runners administrado o quedarse en GitHub
  • Ni siquiera el gobierno neerlandés movió todo de una vez
    • code.overheid.nl es una plataforma de lanzamiento suave para que los ministerios compartan código open source, no un reemplazo total de todo lo que usan
    • La configuración de code.jorijn.com tiene la misma forma
      • Forgejo es el host canónico y GitHub es el mirror; el mirror puede reevaluarse más adelante

Lecturas relacionadas

1 comentarios

 
GN⁺ 5 시간 전
Comentarios en Hacker News

  • Parece que, mientras todos abandonan GitHub, se olvidan del espíritu original de git
    git fue pensado desde el inicio para ser descentralizado, y el problema es que GitHub era más pulido, escalaba mejor y estaba mejor administrado, así que todas las herramientas alrededor de git terminaron centralizándose en GitHub
    Aun así, estaría bien que siguiera existiendo un mirror con sincronización automática hacia GitHub. Llevo años viendo proyectos que se van a hosting propio o a hosts de nicho, luego su mirror en GitHub muere o lo borran, y al final el proyecto desaparece con el tiempo
    git es descentralizado y GitHub es solo uno de los lugares donde puedes subir código; puedes hacer push a varios servidores remotos

    • No olvidé el espíritu de git, pero también recuerdo que GitHub entrenó al primer Copilot con todos los repositorios públicos sin avisarle a nadie
      Por eso ya no voy a hacer commits de código personal ahí
      Tampoco me interesan las funciones sociales como el descubrimiento, las estrellas o los issues que vomitan bots de IA. Con el estado actual me basta
      Y también hay que recordar que “Open Source is not about You”
    • Sí, pero GitHub es más que git
      El aspecto más importante de la plataforma que todos olvidan es el componente social, y el hecho de que hizo muy fácil crear repositorios externos persistentes y colaborar entre repositorios
    • Forgejo está haciendo mucho trabajo para descentralizar incluso las herramientas
      Usa protocolos abiertos y estándares para conectar forges autoalojados entre sí
    • No todos usan git porque estén fascinados con el “espíritu de git”
      Muy pocos lo han usado en el modelo de parches por correo electrónico para el que originalmente fue pensado, y la gran mayoría probablemente tampoco tiene intención de aprenderlo
      En la práctica, la gente usa git porque GitHub lo usa o, siendo más generosos, porque funciona bien cuando se combina con un host central como GitHub
      Lo que atrae es el modelo de desarrollar código localmente y discutir issues y parches en un portal web; de todo eso, git en sí aporta una parte pequeña
    • De acuerdo. Mover un repositorio git es fácil, pero mover toda la superficie del proyecto es lo difícil
      Issues, releases, CI, documentación, avisos de seguridad, búsqueda y descubrimiento tienden a quedar atados a GitHub con el tiempo
      Si es un proyecto open source, me parece buena idea mantener el hosting propio como fuente de verdad, pero conservar un mirror de solo lectura en GitHub para que la gente realmente lo pueda encontrar

  • Lo que de verdad cambiaría el panorama sería un soporte de federación completo
    Por eso dono a Forgejo y Codeberg, y recomiendo que todos aporten más tiempo y recursos para que el equipo de Forgejo lo implemente bien
    Otro buen candidato es Radicle, que es completamente descentralizado sobre Git
    https://codeberg.org/forgejo-contrib/federation/src/branch/m...
    https://liberapay.com/forgejo
    https://donate.codeberg.org/
    https://radicle.dev/
    https://radicle.network/nodes/seed.radicle.dev

    • La federación es el peor modelo de descentralización. La cooperación es demasiado laxa

  • Yo también moví mi repositorio git a un NUC autoalojado
    Todavía no le puse un frontend HTTP para compartirlo con el mundo, porque no quiero servir contenido a scrapers de IA ni quiero dedicarme a bloquearlos
    Es vergonzoso que empresas que se beneficiaron del open source hayan contaminado así la industria

    • Uso Gitea en un NUC, y como es hardware usado me costó unas 50 libras
      Lleva tres años funcionando. Si lo dejas accesible solo en la LAN y no lo expones a internet, se siente sólido y duradero
    • Tengo Forgejo autoalojado en una Pi como mirror de GitHub, pero probablemente no dure mucho
      Los repositorios se espejan bien durante unas semanas y luego se detienen. Le puse un token PAT que no expira, pero insiste en que venció, aunque probado en otro lado el token funciona bien
      A veces no aparece nada en los logs, y otras veces dice que la base de datos está bloqueada. Forgejo es lo único que usa esa base de datos
      Hasta ahora no he podido distinguir si es un problema de Forgejo, si los bloqueos vienen del pésimo I/O de la SD de la Pi, o si Forgejo simplemente no sirve para hacer de mirror
    • El open source y la OSI son un mecanismo plantado por la industria. Solo hay que ver quién los financia
      Las megacorporaciones propietarias de la nube obtienen trabajo gratis, y con eso construyen el mundo que odiamos: redes de rastreo y vigilancia, teléfonos en los que no puedes instalar lo que quieras, attestation de dispositivos y una monocultura de navegadores sin bloqueo de anuncios
      Google logró que la gente amara BSD/MIT, y ahí están los resultados
      Una táctica típica es “eso ahora es nuestro”. Si un vendor crea algo como Elasticsearch o Redis, una hiperescala de nube lo toma como producto propietario y se queda con toda la ganancia, mientras el autor original y su empresa se mueren de hambre
      Otra es “adoptar, extender y extinguir”. Toman proyectos open source como KHTML o Linux, hacen su propia versión, la lanzan al mercado para desplazar a la competencia, la ponen delante de todos mediante medios anticompetitivos y, cuando ganan cuota, meten rastreo y eliminan la libertad
      El open source debería ser reemplazado por “libertad para las personas, las empresas pagan”. Necesitamos shareware con código visible y con dientes para enfrentarse a las hiperescala de nube
      Ni siquiera las licencias de Richard Stallman son lo bastante fuertes; me parece mejor CC BY-NC-SA
      El open source “puro” fue bienestar corporativo y un error. Dejamos que los gigantes nos ahorcaran con nuestra propia cuerda
    • Si alguien decide ofrecer voluntariamente su trabajo como open source, no veo por qué trazar una línea cuando la IA lo lee y lo convierte en conocimiento para ayudar a más programadores después
      Yo sí quiero activamente que la IA lea mi código

  • En la sección “What I gave up”, el autor menciona su grafo social, pero con GitSocial puedes llevarte tu grafo social y tu historial de colaboración
    También permite hacer pull requests entre forges y entre distintos hosts git, todo sin dependencias de terceros

    • GitHub es una red social, y el hosting git es apenas una función pequeña
      Por eso estas alternativas casi nunca despegan

  • Al leer la parte donde dice que “el CTO se disculpó públicamente y dijo que para soportar la carga impulsada por IA tendrían que multiplicar por 30 la capacidad”, espero que GitHub no empiece a cobrar por el uso normal
    Pero viendo a algunos vibe coders hacer miles de commits al día, cada vez soy más escéptico
    Sería una lástima enorme si dejara de ser posible compartir código gratis y colaborar

    • Podrían cobrar por la cantidad de commits por día después de cierto límite. Problema resuelto
    • Sinceramente, creo que los LLM también ayudarán a resolver este problema que ellos mismos crearon
      Una persona con experiencia detecta en segundos cuando un repositorio tiene este tipo de problema, así que un sistema ajustado también debería ser posible
      La parte complicada es redactar los términos legales que permitan aplicar una cuota de vibe
      Anthropic ya lo hace en Claude Code, y supongo que GitHub y GitLab probablemente harán algo parecido. El precio será el odio de los desarrolladores de Twitter y de una parte pequeña de reddit, pero parece bastante asumible
      Por otro lado, cuando veo en /r/vibecoding a gente pagando suscripciones de 200 dólares al mes para hacer proyectos hobby o sitios casi de juguete, sí me sorprende bastante
      Yo también he hecho gastos tontos cuando podía permitírmelos, pero esto se siente distinto
      Tal vez se trate de pagar 2400 dólares al año por un servicio que te da sentido y propósito. Si llegas a los 40 y entiendes que no vas a ser rico ni famoso, quizá sea un precio manejable frente a otras alternativas

  • También escuché de Tangled, un servicio descentralizado construido sobre AT Protocol, como Bluesky
    Incluso tiene funciones realmente útiles, como apilar pull requests, algo que GitHub tardó tanto en implementar que aparecieron empresas dedicadas a agregar esa función sobre GitHub
    Me pregunto si alguien aquí ya lo probó
    https://tangled.org/

    • Hace poco configuré Knot autoalojado, aunque todavía no he usado mucho las demás funciones
      https://tangled.org/h14h.com/knot
      En general, la plataforma parece bastante prometedora. La forma en que AtProto separa servidor de datos personales, relay y AppView me parece una buena solución intermedia
      Puedes alojar un repositorio git como un servidor headless dedicado solo a datos, así que para ser autoalojado casi no da trabajo
      Comparado con soluciones ActivityPub como Forgejo, a mí me importa sobre todo el control de los datos, y está bueno poder evitar la lata de alojar y escalar toda la webapp
      Desde la configuración inicial, el mantenimiento operativo ha sido solo actualizar la versión de knot-server y volver a desplegar. tangled.org muestra un banner de advertencia si estás en una versión vieja
      Quiero usar más Tangled en otros proyectos y probar mejor sus funciones. Me interesa en particular el soporte nativo para jj y stacked PR
    • Claramente es software alfa, pero para open source sí se puede usar
      También hay experimentos interesantes como tack para conectar CI personalizada
      Si algún día ATProto soporta datos privados, quizá también pueda soportar repositorios privados, aunque eso podría tardar
      https://tangled.org/mitchellh.com/tack
    • Acaban de recibir una gran inversión de venture capital
      Todavía no han mencionado modelo de negocio, así que de verdad me intriga en qué terminará eso
    • Quiero usarlo por la compatibilidad con jj y la implementación limpia de CI, pero necesito repositorios privados, así que por ahora no me sirve
    • Para mi gusto está demasiado descentralizado
      Mejor usaría radicle.xyz

  • También vale la pena considerar Fossil
    Empaqueta en un solo archivo todo el estado del repositorio, incluyendo historial de código, wiki, tickets y foro, y ese estado se replica
    Incluso si tienes que cambiar de proveedor de hosting, en Fossil no pierdes datos por eso
    https://fossil-scm.org/

    • Me gusta Fossil. Hay algo en su flujo de trabajo opinado que encaja con mi forma de pensar
      Pero el problema son los efectos de red. No logro llevar a mi equipo a Fossil
      El equipo necesita compartir código con otras personas y otros departamentos, y todos, en la práctica más del 99 %, usan git
      Obligar a usar Fossil más bien se siente contraproducente, y es un callejón sin salida
      Se parece a muchas otras cosas en tecnología. Igual que cuando intentas hacer que otros desarrolladores usen modismos de estilo funcional o imponer inmutabilidad
      Da la impresión de que tendría que aparecer algo grande, como un proyecto de Facebook o Google, para forzar a la comunidad a moverse
    • Hace unos años evalué Fossil y me pareció realmente genial. Que todo esté integrado es excelente
      Pero filosóficamente Fossil no me gusta. No hay forma de limpiar el historial y conserva todo tal cual
      Si eso es lo que quieres, perfecto, pero en mi flujo de trabajo con git me gusta experimentar con distintas cosas y luego ordenar y reorganizar los commits antes de hacer push

  • La gente no para de hablar de descentralización
    Pero en la práctica la mayoría de los sistemas terminan centralizándose
    Quizá cuando la gente pide descentralización, lo que en realidad busca es un nuevo centro donde ellos puedan ser los nuevos pioneros
    Si sienten que no tienen posibilidad de ganar bajo las reglas actuales, parece que usan la descentralización como pretexto para patear el tablero

    • Habría bastado con leer la primera línea debajo del título: “I moved my code from GitHub to a self-hosted Forgejo”
    • Descentralización significa que no hay un único centro
      La razón por la que la gente la quiere es que esa gestión central única no les basta por una u otra razón
      No hay diferencia entre que la gente lo diga a gritos y que realmente lo quiera
    • La gente quiere las ventajas de la descentralización, pero no quiere pagar el precio
      Peor todavía, los sistemas centralizados funcionan muy bien la mayor parte del tiempo, y el dolor llega en periodos cortos pero muy intensos, como una fusión o un aumento repentino de precios
      La descentralización duele un poco todo el tiempo, pero te da una gran alegría en esos raros momentos en que la alternativa centralizada se derrumba
    • Solo dicen descentralización porque son desarrolladores
      En lenguaje normal eso sería un boicot. No dices “las galletas están demasiado centralizadas en Nestlé, hay que descentralizar las galletas”
    • Creo que la respuesta a lo que la gente realmente necesita no es la descentralización, sino la portabilidad

  • Me estoy mudando a Tangled, que está construido sobre AT Protocol y usa la misma cuenta que Bluesky, entre otros
    Lo he probado y me gusta bastante
    https://vale.rocks/micros/20260511-0440

  • Hace un año me cambié a Gitea autoalojado en mi homelab, con el acceso público desactivado
    Ni siquiera tiene HTTPS, el registro está deshabilitado y los repositorios no son públicos
    Estoy pensando si crear una instancia pública y usar HTTPS minimizando la superficie de ataque; sobre todo me interesan recomendaciones relacionadas con Gitea/Forgejo

    • Yo lo hice así. Corro nginx y fail2ban en un proxy de fly.io, y lo reenvío a mi tailnet, donde Caddy resuelve hacia la instancia real
      Es importante desactivar el registro local. En mi caso uso authentik como IdP, pero solo es accesible desde la tailnet. Si no, puedes crear tu cuenta y luego desactivar el registro
      Bloqueé con robots.txt algunas partes como la vista renderizada individual de commits git. Si no, los scrapers entran en un loop infinito
      También prohibí estrictamente el acceso al repositorio de paquetes de Forgejo, porque tengo paquetes privados y la granularidad de permisos ahí todavía no llega a lo que necesito, así que sigo ajustándolo
      Lo sigo vigilando y hasta ahora no he tenido problemas importantes. Tengo más detalles en docs.eblu.me y, si quieres, hasta podría pasarte directo el código de infraestructura
    • Lo hice en el pasado, y todavía corro una instancia Forgejo interna/LAN, pero ahora no tengo instancia pública
      Antes levanté una instancia pública de solo lectura que espejaba la instancia interna, con una sola conexión por reverse proxy desde la interna hacia la pública para que la pública pudiera obtener los datos git
      Después de eso, en general funcionó sola y bien; si cambiaba algo en el Forgejo interno, la parte pública también se actualizaba
      Issues, CI, etc. podían quedarse completamente privados dentro de la LAN
    • Me pasé a Forgejo porque no me gustaron las disputas políticas alrededor de un problema de seguridad que Forgejo le planteó a Gitea y que Gitea ignoró
      Me da curiosidad por qué sigues usando Gitea. Ahora me pregunto si debería volver a probar Gitea en vez de Forgejo