6 puntos por GN⁺ 2025-12-04 | 1 comentarios | Compartir por WhatsApp
  • La Fundación del lenguaje de programación Zig decidió trasladarse a Codeberg por el deterioro de la calidad de GitHub y la gestión de Microsoft centrada en la IA
  • Ocurrió un caso en que el error de ‘safe_sleep.sh’ de GitHub Actions fue dejado sin resolver durante años y provocó una caída del sistema de CI
  • La parte de Zig criticó que GitHub está sacrificando calidad de ingeniería por una estrategia centrada en la IA
  • Jeremy Howard, cofundador de Fast.AI, también señaló la mala gestión de bugs de GitHub y el descenso en la calidad del código
  • La tendencia de proyectos de código abierto a abandonar GitHub se está expandiendo, y aumenta la oposición a una gestión de plataformas centrada en la comercialización de la IA

Antecedentes de la salida de la Fundación Zig de GitHub

  • La Zig Software Foundation, que mantiene el lenguaje de programación Zig, decidió trasladarse al servicio de hosting git sin fines de lucro Codeberg
    • Lo hizo porque considera que GitHub ya no se enfoca en la excelencia en ingeniería
  • Andrew Kelly señaló como ejemplo representativo un bug de bucle infinito ‘safe_sleep.sh’ en GitHub Actions
    • El script podía consumir el 100 % de la CPU y ejecutarse de forma infinita
    • Esto provocó que los runners de CI de Zig se quedaran fuera de servicio durante varias semanas

Problemas técnicos de GitHub Actions

  • El origen del problema fue un cambio de código en febrero de 2022 que reemplazó el comando sleep de POSIX por el script ‘safe_sleep’
    • Si el script perdía cierto timing en segundos, entraba en una estructura de bucle infinito
  • El bug solo se corrigió el 20 de agosto de 2025, y el issue permaneció sin resolver hasta el 1 de diciembre
  • Otro error de uso excesivo de CPU sigue sin resolver

Reacción de la comunidad y expertos

  • Jeremy Howard (cofundador de Fast.AI) evaluó que el estado de GitHub Actions era “claramente deficiente”
    • Señaló que un código que ocupaba el 100 % de la CPU quedó sin revisión durante un año
    • Dijo: “Una organización que funciona normalmente no puede repetir una serie de errores así”
  • Kelly luego pidió disculpas por el tono agresivo de su declaración, pero siguió insistiendo en que el decaimiento de la calidad de GitHub sigue siendo un problema

Movimiento de salida de otros proyectos

  • El fundador del proyecto Dillo Browser, Rodrigo Arias Mallo, también anunció su plan de abandonar GitHub
    • Señaló problemas como la dependencia de JavaScript, la posibilidad de denegación de servicio y una gestión centrada en LLM e IA generativa
    • Mencionó que “la IA generativa está destruyendo la web abierta”
  • Desde enero de 2025, Codeberg duplicó su base de patrocinadores, pasando de 600 a más de 1.200 miembros

Estructura de ingresos centrada en IA de GitHub

  • En el informe de resultados del segundo trimestre de 2024, el CEO de Microsoft Satya Nadella anunció que
    • había más de 1,3 millones de suscriptores de pago de GitHub Copilot, con un aumento del 30 % frente al trimestre anterior
  • En 2024, de los 2.000 millones de dólares de ingresos anuales de GitHub, alrededor del 40 % provenía de las suscripciones de Copilot
  • En el tercer trimestre de 2025 se reportaron más de 15 millones de usuarios de Copilot, un aumento de cuatro veces interanual
  • GitHub actualmente no revela cuántos usuarios de pago tiene, y solo pone énfasis en una estructura de ingresos centrada en Copilot

Significado general

  • Los casos de Zig y Dillo muestran cómo la operación de plataformas orientada a la comercialización de la IA está debilitando la confianza de los desarrolladores
  • La estrategia de GitHub centrada en la IA y la falta de control de calidad está provocando la fuga de la comunidad de código abierto
  • La tendencia de crecimiento de plataformas alternativas sin fines de lucro como Codeberg se está acelerando

1 comentarios

 
GN⁺ 2025-12-04
Opinión de Hacker News
  • El historial de ediciones del anuncio del equipo de Zig es bastante interesante.
    Al principio criticaban al equipo de GitHub como un “framework de JS lleno de bugs hecho por empleados mediocres que se quedaron”, pero después suavizaron el tono.
    En la versión final, quedó más bien como que la “excelencia de ingeniería” de GitHub desapareció.
    Versión inicial (11/27 02:10)edición intermedia (11/27 14:04)edición final (11/28 09:21)

    • En el hilo anterior de HN hubo mucho feedback de “quiten la carga política/emocional”, y parece que el equipo de Zig sí lo tomó en cuenta.
      Impresiona que hayan hecho una edición dejando de lado el orgullo por el bien de la comunidad.
    • La obsesión y enojo que mostró Kelly por la “excelencia de ingeniería” más bien parece señalar un futuro prometedor para Zig.
      Me parece una buena señal que un líder técnico se indigne ante la mediocridad.
    • Una acusación como la de la redacción inicial, de que “el software pésimo es intencional”, sí me parece excesiva.
      En realidad, suele ser solo el resultado de limitaciones de entorno y capacidad.
    • El enojo nubla el juicio.
      Creo que el software hecho con amor, es decir, con aprecio por la tecnología y por la gente, produce mejores resultados.
    • Sí conecté con la frase “bloated, buggy JS framework”.
      Grandes empresas le avientan dinero a mantener frameworks así, y millones de personas los usan sin siquiera poder desactivarlos.
      Yo al usar GitHub no ejecuto nada de JS; solo descargo archivos raw con reglas de proxy.
      http-request set-path %[path,regsub(/blob/,/raw/,g)] if { hdr(host) github.com }
      http-request set-path %[path,regsub(/releases/tag/,/releases/expanded_assets/,g)] if { hdr(host) github.com }
      
      Así funciona bien.
  • La fortaleza de GitHub es su ecosistema.
    El sistema de PR, gestión de issues, acciones de CI, patrocinio: todo está en un solo lugar.
    La obsesión con la IA me inquieta, pero aun así me sigue pareciendo la herramienta más cómoda para desarrolladores.

    • No estoy de acuerdo. La verdadera fuerza de GitHub es el efecto de red social.
      Métricas como stars, forks y número de seguidores funcionan como señales de calidad.
      Al final, los desarrolladores confían en “los ojos de la comunidad”.
    • Usé Gerrit hace tiempo y nunca sentí que los PR de GitHub fueran especialmente mejores.
      Actions es tan complejo y tan propenso a fallas que le dicen infierno de YAML.
      Aun así, la razón principal es que “todo mundo lo usa”.
    • No puedo estar de acuerdo con que el sistema de CI esté bien hecho.
      Actions es conveniente, pero es un producto terrible.
    • Preferiría resolver Advent of Code en brainfuck.
      Depurar GitHub Actions es sufrimiento puro.
    • Me molesta que GitHub no haya negado haber usado repos privados para entrenar IA.
      GitLab sí lo negó explícitamente, y esa diferencia reduce la confianza.
  • Me dio curiosidad la infraestructura de Codeberg y la revisé.
    Según una entrada del blog oficial,
    operan con 3 servidores (1 Gigabyte y 2 Dell R730/R740), y enfatizan la reutilización de hardware usado.
    Incluso están intentando reutilizar una MacBook descompuesta como runner de CI.
    Dicen que a veces hay degradación de rendimiento, pero que se puede resolver con reinicios.
    Tiene una vibra DIY tipo hackerspace.

    • Si ves la página de estado, la disponibilidad es baja.
      En las últimas 24 horas tuvo 89% de uptime; el promedio de 14 días es 98%, pero el sitio principal se pone lento seguido.
    • Codeberg es una plataforma para FLOSS, no para empresas.
      Su objetivo no es ofrecer un servicio comercial.
    • Yo también operaba un clúster más grande cuando tenía 20 años.
      Solo la luz salía en más de 600 dólares al mes; con eso, hasta yo podría abrir un servicio gratis.
      Si alguien tiene ideas, que me escriba por correo.
  • Viendo cómo Zig manejó el tema de los issues en GitHub, parece una decisión algo emocional.
    Hay bugs en todas partes, y considerando la escala de GitHub es algo normal.
    La migración a Codeberg da la impresión de haber tenido poca discusión.
    Zig es técnicamente excelente, pero parece que todavía no termina de consolidar una estructura de liderazgo madura.

    • El problema no son los bugs sino la indiferencia de las megacorporaciones.
      A empresas como Microsoft no les importa aunque los clientes se quejen una y otra vez.
      Por eso esperaría que al moverse a una plataforma más pequeña reciban soporte más motivado por el éxito del cliente.
      Los scripts de CI deberían hacerse, en la medida de lo posible, como scripts puros para que sean más portables.
    • Que alguien diga “no conocía Codeberg” es problema suyo.
      Tampoco hay evidencia de que no haya habido discusión interna.
  • Entiendo las críticas a GitHub, pero Codeberg se cae seguido.
    Según su página de estado, en las últimas dos semanas el uptime ronda el 95%.

    • GitHub Actions también falla a menudo, así que en realidad no siento que haya tanta diferencia.
    • Si el nivel de servicio importa, es mejor hospedar Forgejo por tu cuenta.
      Así no dependes de un único punto de falla como con GitHub.
    • En Reddit también había quejas de que el proceso de verificación contra bots de Codeberg es incómodo.
      Aun así, Forgejo autohospedable sigue siendo atractivo.
    • Codeberg recibe ataques DDoS con frecuencia.
      En su cuenta de Mastodon comparten la situación con transparencia.
      Que lo ataquen también puede verse como prueba de que sí importa.
    • Codeberg es una plataforma solo para open source.
      No es adecuada para proyectos comerciales ni para usarla como respaldo personal.
  • Últimamente siento que la palabra IA se volvió un término de marketing.
    En unos dos años, la mayoría de las apps seguirán teniendo funciones de IA, pero probablemente desaparecerá la frase promocional de “AI-first”.

    • Lleva 15 años siendo así.
      Igual coincido con la predicción: ahora anunciar IA ya se ve medio naco.
    • Solo han ido cambiando las palabras de moda, como “big data” o “machine learning”.
      La publicidad personalizada sigue ahí, aunque el concepto en sí resulte desagradable.
  • La reforma del feed del dashboard de GitHub fue un desastre.
    En la discusión relacionada también hubo muchas quejas.

    • Con la actualización reciente cambió a un enfoque más centrado en PR e issues recientes, y eso sí me parece una mejora.
      De hecho lo uso bastante.
    • La verdad es que ni uso el dashboard.
      Casi siempre trabajo directamente desde la página del proyecto.
    • Yo también uso la página de notificaciones como inicio.
      Con el autocompletado del navegador hasta me basta escribir “not” para llegar.
  • La razón de Zig para irse no es solo la desconfianza hacia Microsoft.
    Zig siempre ha sido una comunidad de opiniones fuertes.
    GitLab tampoco convence, y no hay muchas alternativas.
    El fondo del problema es la estructura monopólica de las grandes corporaciones, y la IA solo la empeora.

    • Me pregunto cómo estará Bitbucket hoy en día.
      Ya casi parece que dejó de existir.
  • La ventaja de Codeberg es la velocidad de carga de páginas.
    GitHub a veces se siente lento y pesado.

    • Sobre todo en entornos 4G inestables, GitHub es terrible.
      Comparado con servicios como Linear, la diferencia es grande.
    • En cambio, en mis pruebas Codeberg fue más lento.
      $ time curl -L 'https://codeberg.org/'  → 3.06s  
      $ time curl -L 'https://github.com/'    → 1.35s
      
      Supongo que depende del entorno.
  • Quiero recomendar Fossil SCM.
    Es una herramienta hecha por el creador de SQLite, con funciones de nivel GitHub integradas en un solo ejecutable de 6 MB.
    Se puede revisar en fossil-scm.org.

    • Eso sí, no tiene sistema de code review.
      Se debe a que su creador casi no acepta contribuciones externas.
      Es excelente para proyectos de una sola persona, pero no sirve para colaboración.
    • Aun así, es excelente para proyectos personales.
      De verdad recomendaría probarlo en tu próximo side project.