5 puntos por GN⁺ 1 일 전 | 3 comentarios | Compartir por WhatsApp
  • Las caídas repetidas de GitHub han llegado a un punto en que realmente bloquean la revisión de PR y el trabajo diario, dejando en evidencia una dependencia de issues, PR y Actions que no se resuelve solo con un repositorio Git distribuido
  • Durante el último mes, los problemas de GitHub afectaron el trabajo casi todos los días, y el mismo día en que se escribió el texto una falla de GitHub Actions bloqueó la revisión de PR durante unas 2 horas
  • El destino de la migración todavía no está definido; se están evaluando varias opciones entre servicios comerciales y proveedores FOSS, con el plan de reducir gradualmente la dependencia de GitHub
  • En la URL actual se dejará un espejo de solo lectura, y este cambio se aplicará primero solo a Ghostty; otros proyectos personales seguirán en GitHub por el momento
  • Esta decisión no surgió de apuro por la gran caída del 27 de abril de 2026, sino que se venía discutiendo desde hace meses, y un posible regreso no dependerá de promesas sino solo de mejoras reales verificables

Motivos de la migración

  • Ghostty decidió dejar GitHub y considera que las caídas recientes han llegado al nivel de bloquear el trabajo real
  • Durante el último mes se llevó un registro aparte de los días en que las caídas de GitHub afectaron el trabajo, y se afirma que los problemas continuaron casi a diario
  • Incluso el día en que se escribió el texto, una falla de GitHub Actions impidió avanzar con la revisión de PR durante unas 2 horas
  • La infraestructura alrededor de GitHub, como issues, PR y Actions, es el centro del problema, y se deja claro que el simple hecho de que Git sea distribuido no lo soluciona
  • Al mantenerse una situación en la que el trabajo queda bloqueado durante varias horas al día, se concluyó que ya no es posible verlo como un espacio de trabajo serio

Plan y alcance

  • El destino de la migración de Ghostty todavía no está confirmado, y continúan las conversaciones con varias opciones entre servicios comerciales y proveedores FOSS
  • El plan es no cortar la dependencia de GitHub de una sola vez, sino eliminarla gradualmente
  • En la URL actual de GitHub se planea dejar un espejo de solo lectura
  • Este cambio se aplicará primero solo a Ghostty, mientras que los proyectos personales y otros trabajos seguirán en GitHub por ahora
  • Como Ghostty es el proyecto con mayor impacto para él, para los mantenedores y para la comunidad de código abierto, el foco de este cambio también está puesto ahí

Contexto adicional

  • Aunque coincide en el tiempo con la gran caída del 27 de abril de 2026, el plan de salir de GitHub se venía discutiendo desde hace meses, y la decisión final recién se tomó esta semana
  • El texto principal fue escrito antes de la gran caída de Elasticsearch, y la falla del mismo día mencionada en el texto fue una caída distinta
  • Si GitHub realmente mejora, podría haber un regreso algún día, pero la condición no serán palabras o promesas, sino resultados y mejoras reales

3 comentarios

 
carnoxen 22 시간 전

Quienes ya se mudaron a otro lado (como Codeberg) probablemente, al ver esta situación, estén aún más convencidos de que hicieron bien en irse.

 
xguru 1 일 전

Mitchell Hashimoto escribió incluso en un comentario de HN que realmente se le salieron las lágrimas al verlo.
https://x.com/mitchellh/status/2049213597419774026
Dice que se registró en febrero de 2008 como el usuario número 1299 de GitHub.

Parece que últimamente GitHub sí ha estado teniendo muchos problemas. Hace unas horas también publicaron GitHub está presentando una caída en este momento.

 
GN⁺ 1 일 전
Opiniones de Hacker News
  • mitchellh: al escribir esto de verdad lloré, y no es una exageración
    GitHub no era solo un SaaS para mí, significaba mucho más, así que terminé desarrollando una relación bastante profunda, quizá hasta poco saludable
    Lo hablamos de forma intermitente durante meses, y en las últimas semanas la conversación se puso seria; tomé la decisión final hace unos días, pero recién al publicar el post se sintió totalmente real
    A algunos les puede dar risa, pero de verdad le tengo cariño a GitHub y espero que vuelva a encontrar su rumbo

    • Está bien sentir eso, yo me siento parecido
      Soy el usuario 22723 de GitHub, y considerando que hoy debe haber como 180 millones de cuentas, en la práctica eso significa que estoy ahí desde casi el principio
      Dicho a mi manera, GitHub solo puede mejorar si la gente que todavía le tiene cariño se queda para ayudar a hacerlo mejor
      Cuando dejé Heroku hace unos 6 años, después de haberlo usado feliz casi durante una década, no volví a abrir el dashboard, y al final sentí que Salesforce sí lo arruinó de verdad
      Pero con GitHub no siento que pueda irme así nada más
      Se desordenó al mismo tiempo por el agentic coding y por un crecimiento explosivo, pero esto no se ve como una catástrofe al estilo Heroku/Salesforce
      Más que explicarlo por más AI coding o por un Microsoft malvado, parece más creíble que cambió la escala y cambió por completo el terreno bajo los pies de los desarrolladores
      Ojalá lo hagan tan bien que den ganas de volver, y no tiene nada de tonto sentir algo fuerte por algo que está en el centro de la vida de los desarrolladores
    • Se siente clarísimo la frustración, y expresarla no es exagerar
      Me pegó mucho esa sensación de querer trabajar y sentir que te estorban, de querer desplegar software y sentir que el servicio no quiere que lo hagas
      Y esto no es solo cosa de GitHub; parece que la web en general últimamente va hacia algo más descuidado y de menor calidad
      Hay demasiadas caídas constantes, bugs, asperezas de UI y funciones incompletas, y ya no sé qué está pasando
    • Si alguien se burla de ti por sentir eso, ni siquiera vale la pena escucharlo
      Gracias por hacer ergonomic software para la gente
    • El meme de Spool of Wire Guy describe justo este sentimiento
      La idea es que, aunque a otros les parezca un objeto insignificante, para quien lo tiene está cargado de cariño y recuerdos acumulados durante mucho tiempo
      https://knowyourmeme.com/memes/spool-of-wire-guy
    • Esto no es ninguna exageración
      En la vida hay cosas que te gustan y que amas, y es normal entristecerse cuando algo del bando que apoyabas se arruina
      Yo tampoco me burlaría por algo así, y de hecho me enoja la gente que sí lo hace
      Dicho eso, sinceramente no soy optimista con que GitHub vaya a encontrar el rumbo
  • Fue bastante impactante ver cómo GitHub se está desmoronando como organización
    Se mencionan muchas explicaciones —la incorporación a Microsoft, el traslado de recursos hacia Copilot, la estructura organizacional, cosas como vibe coding—, pero sea cual sea la razón, cuesta negar que hay un problema serio
    El historial que muestra la página de estado no oficial también es bastante terrible
    Me gustaría escuchar la perspectiva interna, pero en este momento parece un barco que se hunde sostenido por la inercia, y en un momento donde toda la industria del software se está sacudiendo, no parece que la inercia sola vaya a alcanzar

    1. https://mrshu.github.io/github-statuses/
    • Ni siquiera hace falta una mirada interna para imaginar más o menos qué está pasando
      Lo están operando como suelen terminar operándose los servicios comprados por una gran empresa
      Al principio siguen bien, luego se deterioran poco a poco, después colapsan, y todo se convierte en un juego de números
      Hay muchos casos parecidos en Microsoft, Oracle, VMware, CA y Salesforce, y son poquísimos los equipos que manejan bien fusiones y adquisiciones
    • Con el valor actual de 87.25% uptime, eso equivale a sufrir interrupciones parciales unas 3 horas al día
      https://onlineornot.com/uptime-calculator/87.25
    • Desde hace años me pregunto cuánto falta para que GitHub termine como SourceForge
      Cuando algo crece demasiado sin liderazgo adecuado, al final se viene abajo
    • Lo peor es que hay fallas que ni siquiera aparecen en la página de estado no oficial
      En la práctica, la cifra real se siente todavía peor
    • Echarle toda la culpa a Microsoft me parece casi distorsión de la memoria
      Incluso antes de la adquisición, hubo épocas en las que usar GitHub era como lanzar una moneda para ver si el sitio iba a funcionar bien ese día
      Tuvo éxito porque estaba en el lugar correcto en el momento correcto, pero en esencia siempre fue un sistema medio improvisado y pegado con cinta por todos lados
  • Entiendo el afecto genuino que Hashimoto siente por GitHub y por el mundo open source
    Pero creo que, si hubiera tenido un poco más de esa actitud estilo Richard Stallman de desconfiar de que el software no libre es inherentemente sospechoso y poco ético, esta herida sería menor
    GitHub en 2008 y GitHub hoy siguen siendo software no libre que corre en servidores ajenos, bajo reglas ajenas, y operado al final para beneficiar a sus dueños
    Yo también lo usé durante mucho tiempo, y muchas veces tuve que usarlo por trabajo, pero nunca desarrollé un apego emocional
    Siempre me molestó que, aun estando construido sobre git, que es free-software, su estructura empujara a atrapar a los usuarios dentro de la plataforma
    Nunca pude amar un software que requiere una cuenta de email y aceptar términos de uso, y que ni siquiera funciona en Irán por las leyes de sanciones de EE. UU.
    Por eso me alegra sin reservas que ghostty se vaya de GitHub


    • En KDE casi nunca se consideró seriamente GitHub; operamos nuestra propia git infra y después, junto con Gnome, colaboramos con GitLab para lograr que ciertas funciones imprescindibles de la Enterprise Edition pasaran a la Community edition
      En los últimos 16 años creo que tuvimos exactamente una sola caída de git que duró varias horas
    • Al final todo es una cuestión de value proposition
      Solo hay que ver si vale tu tiempo y tu dinero
      Igual que con los aumentos de precio de Netflix o con los juegos, uno puede desgastarse emocionalmente, pero si ya no tiene valor, simplemente te vas
      Claro, entiendo que se formen conexiones emocionales, como con los recuerdos de la computación de los primeros años
    • Llevo un tiempo siguiendo de cerca este tipo de tecnologías
      Cada vez me parece más sensato integrar cosas como el issue tracker dentro del git repo
    • De acuerdo
      Creo que este dolor aparece por no haber llevado hasta el final la crítica al closed source software
      Desde que vendió Hashicorp, le tengo mucho menos respeto
  • Hace un tiempo vi respuestas en un hilo de X donde Mitchell criticaba a GitHub, diciendo que GitHub debería contratarlo como CEO, y la verdad me pareció que tenían bastante sentido
    Para girar un barco así no basta con un simple administrador; hace falta alguien con convicciones fuertes, capacidad de ejecución y además poder para atraer talento
    Creo que al final va a aparecer un nuevo GitHub, y si encuentra el momento justo, podría crecer rápido, igual que OpenClaw o el viejo GitHub lo hicieron en la era de SVN y SourceForge
    Ya parece haber muchos intentos apuntando a ocupar ese espacio

    • El problema es que GitHub hace demasiadas cosas
      Y aun así, si uno lo mide por su servicio principal, siento que sigue sin haber una buena UI, sobre todo para proyectos complejos
      En cambio jujutsu parece tener una dirección base bastante buena, pero todavía no tiene un forge decente
    • Quizá ya es momento de volver a mirar fossil
      Código, wiki e issues quedan distribuidos prácticamente como una sola herramienta
    • Lo que los usuarios esperan de GitHub y lo que su dueño, Microsoft, espera de GitHub no están alineados
      Tal vez se vuelvan a alinear si la AI llega a reemplazar el desarrollo de software del modo en que lo imaginan los ejecutivos de big tech, pero hoy la gente quiere un git remote estable y en cambio recibe una mezcla de hosting inestable con funciones improvisadas de vibe coding
    • GitLab sinceramente está bastante bien, y en general está subvalorado
    • Yo sigo esperando un forge de git distribuido y federado
      La razón principal por la que todo el mundo se concentra en GitHub es que permite colaborar fácilmente en issues y PR aunque los self-hosted forge no abran registro de usuarios, y eso se podría resolver sin meter todo el código del mundo en una sola infraestructura que se está cayendo a pedazos
      Probablemente sea difícil que ocurra, pero sería buenísimo
  • Tengo bastante curiosidad por cómo cambiará el ecosistema de desarrolladores en 5 años, y por qué forma tendrá GitHub dentro de 5 años
    Yo casi no abro la web de GitHub y uso mucho github cli
    Solo con gh ya puedo hacer casi todo lo que necesito, y como Actions corre en GitHub y un agente recoge los resultados, revisa issues y corrige código, todo el flujo de trabajo ya cambió

  • Si tanta gente coincide en que GitHub ya no es un lugar agradable, y que da la sensación de impedirte trabajar o desplegar, entonces Redmond tiene que reaccionar fuerte
    Si este sentimiento realmente se extiende, podría ser un golpe muy duro para Microsoft
    Hace 8 años gastó casi 8 mil millones de dólares para convertir a los desarrolladores en un pilar central, y también puso 2 mil millones en Minecraft para atar incluso a las generaciones jóvenes de desarrolladores
    Ya perdió el terreno de los OS y de los servidores; si también pierde a los desarrolladores, podría terminar siguiendo un camino parecido al de Xerox en el siglo XXI

    • Me parece una exageración muy de HN
      Microsoft puede no dominar claramente juegos, móvil o AI, o incluso tener muchas chances de perder ahí, pero sigue reteniendo a una enorme cantidad de oficinistas comunes a quienes les basta con Word y Excel
      Hay demasiada gente que no tiene interés en la tecnología pero sigue atada a Office
      El hecho de que una de las habilidades prácticas que Claude aprendió bien al principio fuera generar archivos .docx también muestra eso
  • El problema no es git en sí, sino la infraestructura montada encima: issues, PR, Actions y demás
    Mi sugerencia es que, aunque se migre a otro forge, se use también git-bug
    Guarda issues, PR y demás dentro del propio git, en refs especiales en vez de ramas, y también soporta sincronización bidireccional con distintos proveedores
    Otros VCS como fossil también guardan los issues junto al repo, y eso me parece correcto porque los issues, como la documentación, son parte de lo que le da significado al código

    • Hace unos días vi a un colega inclinarse por completo hacia un agentic workflow con un tablero kanban local inspirado en OpenAI Symphony, y eso me hizo pensar otra vez en fossil
      Sí simplifica las cosas tener todo dentro del repo
      Aunque ahora que todo eso también lo manipula un LLM coding agent casi sin restricciones, se vuelve más difícil limitar el alcance de acceso
    • git-bug es excelente, pero no puede manejar PR, y todavía no hay manera de que usuarios sin permisos de commit reporten bugs
      Según entiendo, en esto último están trabajando en una dirección tipo web UI, pero hasta que eso llegue, si quieres permitir que usuarios comunes reporten issues, al final igual necesitas infraestructura pública
      Yo lo uso en mi proyecto con https://github.com/stryan/materia, y sirve bien para centralizar el repositorio y los issues
      Pero para entradas aleatorias de usuarios sigo usando GitHub Discussions como un pseudo bug tracker
      Si es realmente un bug, lo agrego a git-bug y lo sincronizo con GitHub issues para que quede visible públicamente, pero para reportes de bugs de usuarios a gran escala este enfoque no encaja muy bien
      Ironicamente, esta idea de flujo de trabajo la saqué de ghostty y de mise: ambos reciben primero los bugs por discussion y solo crean issues etiquetados cuando el caso es accionable
    • También me imagino a Mitchell tan frustrado que termine escribiendo él mismo, como Linus en un fin de semana, una infraestructura distribuida de issues, PR y Actions
    • No conocía esto, pero ese mecanismo de special ref se ve realmente genial
      Muy buen dato
  • Me pregunto qué tiene la mayor responsabilidad en esta gran caída de calidad de GitHub
    Algunos dicen que el código generado por AI degradó la calidad de la codebase, y otros que tras la compra por Microsoft se extendió una mala cultura de ingeniería
    Puede que haya un poco de ambas cosas

    • De las explicaciones que he oído, la que más sentido me hizo fue la Azure migration
      https://news.ycombinator.com/item?id=45517173
    • Como tercer factor, también habría que incluir un aumento récord del uso
      https://github.blog/news-insights/company-news/an-update-on-github-availability/
    • Ya venía en descenso desde antes de que explotara el agentic coding
      Parece el resultado de mezclar la cultura y la infraestructura de Microsoft, y ahora se siente con una calidad parecida a la de otros servicios de Microsoft
      Y agrego esto: los binarios del dotnet CLI están alojados de forma tan inestable que mi CI se rompe seguido y tuve que volver a alojarlos yo mismo
    • Empezó a ponerse peor después de la adquisición por MS, y se puso muy mal cuando MS empezó a empujar fuerte la AI
    • Yo creo que al final lo central es el uptime y la UX/UI
      Siguen ocurriendo incidentes donde en la página de Pull Request los resultados aparecen incompletos, o donde los datos no se perdieron pero mientras Elasticsearch reconstruye el índice, las listas no se muestran bien hasta que termina la reindexación
  • Dijo que en los próximos meses va a compartir con más detalle adónde moverá el proyecto Ghostty, pero eso también puede verse como responder al problema de que GitHub Issues o PR a veces quedan inaccesibles durante el día creando un estado inaccesible por varios meses
    Parece una decisión algo apresurada y emocional, y no me termina de parecer que necesariamente beneficie ni a él, ni a Ghostty, ni a la comunidad
    Como mínimo, me gustaría que tuviera una ruta de respaldo preparada antes de moverse