Transcript
00:00:00GitHub se encuentra en una situación muy grave, muy mala.
00:00:04Hay muchos, muchos problemas, gran parte de ellos relacionados con la IA,
00:00:08pero quizás no por las razones que crees,
00:00:10aunque volveré sobre eso más adelante.
00:00:11Y, por supuesto, esto es importante.
00:00:13Es importante porque GitHub es la columna vertebral
00:00:16del desarrollo de software moderno.
00:00:17No importa si te dedicas al código abierto,
00:00:20si mantienes algunos proyectos de open source,
00:00:22si trabajas solo en tus propios proyectos,
00:00:24tus proyectos personales o secundarios,
00:00:26si diriges un negocio pequeño, una empresa pequeña,
00:00:29o tal vez si estás en una empresa más grande,
00:00:32se utiliza para todo tipo de cosas como archivo de código,
00:00:35flujos de CI/CD, para colaboración,
00:00:38para trabajar juntos en proyectos mediante issues,
00:00:42pull requests y muchas otras cosas y casos de uso.
00:00:47Así que esto importa, pero como mencioné,
00:00:49existen muchísimos problemas.
00:00:51Y empecemos con lo que está fallando
00:00:53antes de analizar el porqué
00:00:54y qué significa esto para el futuro.
00:00:57Empecemos con uno de los grandes.
00:00:59Hubo una vulnerabilidad de seguridad grande, enorme,
00:01:02increíble, reportada ayer
00:01:07mientras grabo este vídeo.
00:01:09Una ejecución remota de código en github.com.
00:01:12Digo, leer eso es simplemente una locura.
00:01:16Fue descubierta por Viz, una empresa de seguridad,
00:01:19y no llegó a ser explotada.
00:01:21Así que se descubrió, se reportó y se solucionó.
00:01:25No hubo daños.
00:01:28Según GitHub,
00:01:31quienes también publicaron una respuesta a este informe.
00:01:33Ahora, no entraré en los detalles
00:01:36de cómo funcionaba esa vulnerabilidad.
00:01:39Aunque dejaré el enlace al artículo abajo.
00:01:42Pero al final, todo funcionaba a través de git push.
00:01:44Así que no hubo phishing involucrado,
00:01:46ni robo de cuenta de algún empleado,
00:01:49ni ataque a la cadena de suministro.
00:01:51Hemos visto mucho de eso en las últimas semanas,
00:01:54pero no, nada de eso estuvo involucrado.
00:01:56En su lugar, fue solo git push,
00:01:58y específicamente la función estándar de opciones de push
00:02:03que puedes añadir al comando git push
00:02:05para adjuntar opciones extra a dicho comando.
00:02:10Y a través de esa función de opciones y la vulnerabilidad
00:02:13y la forma en que GitHub gestionaba los pushes,
00:02:17los investigadores de seguridad pudieron adjuntar código
00:02:22que se ejecutaría sin más en los servidores de GitHub.
00:02:27Nuevamente, los detalles exactos están en el informe,
00:02:31pero en resumen, abusaron del hecho
00:02:34de que se podía añadir metadatos extra a una cabecera xstat
00:02:39que se rellenaba con la ayuda de ese flag de opciones de push.
00:02:44Y esos metadatos, esa información que podías enviar
00:02:49con la solicitud de push a través de esa cabecera,
00:02:52no fue saneada por GitHub.
00:02:54Ellos simplemente autenticaban la solicitud,
00:02:58el comando de push.
00:02:59Comprobaban si tenías permiso para subir código
00:03:01al repositorio al que intentabas enviarlo,
00:03:03pero luego tomaban esos datos de las opciones
00:03:07y construían la cabecera xstat sin sanear los datos.
00:03:12Y eso permitió a los investigadores de seguridad
00:03:15ejecutar un comando que no estaba restringido
00:03:18al repositorio al que estaban subiendo el código,
00:03:21sino que se ejecutaba libremente en los servidores de GitHub
00:03:24y podía acceder también a otros repositorios,
00:03:27incluyendo repositorios privados.
00:03:29Repito, esta vulnerabilidad fue reportada y corregida
00:03:33y ya no existe,
00:03:35pero obviamente es algo enorme.
00:03:39Es decir, es un asunto muy serio tener una vulnerabilidad
00:03:43que permita la ejecución remota de código en github.com.
00:03:45Es realmente inmenso.
00:03:47Así que sí, ese es un gran problema,
00:03:48pero por supuesto no es el único.
00:03:51El 23 de abril, hace solo unos días,
00:03:56hubo un incidente masivo relacionado con las colas de fusión de GitHub.
00:04:01Las colas de fusión, por si no lo sabes,
00:04:04son una función de GitHub diseñada para repositorios
00:04:07donde hay mucha actividad, mucho trabajo activo,
00:04:11muchas pull requests entrando constantemente.
00:04:13Y para asegurar que no tengas que fusionar
00:04:16cada pull request antes de enviar una nueva,
00:04:19porque lógicamente quieres que tu pull request sea
00:04:21contra el estado más reciente del repositorio,
00:04:24de la rama principal, por ejemplo,
00:04:26y para asegurar que no tengas que fusionar
00:04:28cada una antes de que se pueda abrir la siguiente.
00:04:30Al final, existe esta función de cola de fusión,
00:04:34cuyo objetivo simple es crear de manera efectiva
00:04:38una especie de fusión intermedia
00:04:42para generar un nuevo estado del repositorio o de la rama
00:04:46contra la que intentas fusionar para cada pull request.
00:04:49Y si se añade una nueva pull request
00:04:51a la cadena de pull requests,
00:04:53esta ya se considera fusionada y combinada con las anteriores
00:04:57en la rama principal
00:04:58para que las nuevas pull requests se abran
00:05:01como si las anteriores ya hubieran sido integradas.
00:05:05Esto simplemente permite a los equipos trabajar más rápido
00:05:08porque puedes abrir más y más pull requests
00:05:10sin esperar a que se completen las que van delante.
00:05:13En algún momento, claro, se fusionarán,
00:05:15pero te permite seguir trabajando,
00:05:17lo cual es vital para equipos grandes, por ejemplo.
00:05:19Ahora, lo que también es crucial respecto a esa función
00:05:22es, por supuesto, que funcione correctamente.
00:05:24Y lo que ocurrió el 23 de abril fue
00:05:28que hubo un error, un error de lógica interna
00:05:32en cómo GitHub resolvía estas diferentes pull requests,
00:05:37de modo que, en última instancia, creaba una fusión
00:05:41que descartaba cierta información, lo que llevaba
00:05:45a un commit inválido y eliminaba partes
00:05:49del historial de Git.
00:05:50En realidad no se perdieron los datos,
00:05:53pero esta función operó incorrectamente
00:05:55y produjo ese commit erróneo.
00:05:57Esa es la versión corta, la esencia del asunto.
00:06:00Y, por supuesto, esto es totalmente inaceptable
00:06:03si eres una empresa grande o cualquier empresa que dependa
00:06:06de esa función y de pronto tu proyecto termina
00:06:09en un estado roto sin que tengas una explicación clara
00:06:13al respecto; es inaceptable, lógicamente.
00:06:16Y tu primer pensamiento probablemente no sea
00:06:19que hay algún bug interno en la función de cola de fusión.
00:06:23Probablemente pienses que tú hiciste algo mal.
00:06:26Así que pasas mucho tiempo buscando el error
00:06:28hasta que descubres: "Ah, no, es GitHub".
00:06:30Y todo esto, por supuesto, se suma
00:06:33a los problemas continuos de disponibilidad que tiene GitHub.
00:06:38La página de estado oficial se ve mal,
00:06:42bueno, quizás aceptable, pero no tenemos "tres nueves"
00:06:46de tiempo de actividad aquí tampoco, al menos en la mayoría de sistemas.
00:06:49Ellos informan del tiempo de actividad por separado para cada sistema.
00:06:53Pero las cosas cambian si miramos
00:06:55la página de estado "Missing GitHub",
00:06:57que rastrea la disponibilidad de una forma distinta
00:07:00y cuenta cada pequeño incidente como un problema,
00:07:04como un tiempo de inactividad al final.
00:07:05Aquí vemos una disponibilidad horrible para un sistema tan crucial
00:07:10como GitHub; totalmente inaceptable, por supuesto.
00:07:14Hemos tenido problemas de disponibilidad en los últimos meses
00:07:18e incluso desde el año pasado.
00:07:20Y también ha habido pequeños bugs aquí y allá,” solo que no tan grandes como este o tan importantes
00:07:23solo que no tan grandes como este o tan importantes
00:07:26como esta vulnerabilidad de seguridad.
00:07:28Pero sí, hay muchos problemas
00:07:31y GitHub se ha convertido definitivamente en una plataforma poco fiable
00:07:36en este momento, por desgracia,
00:07:38lo cual es un desastre dado su papel y su importancia
00:07:43en, como dije al principio, el desarrollo moderno,
00:07:47sin importar qué tipo de trabajo de desarrollo realices.
00:07:50Otro problema es que la comunicación por parte de GitHub
00:07:54ha sido, digamos, escasa.
00:07:59No ha habido mucha comunicación,
00:08:01pero compartieron una entrada de blog el 28 de abril,
00:08:06antes de esa vulnerabilidad de seguridad,
00:08:10donde intentan explicar qué está pasando,
00:08:14de dónde vienen los problemas,
00:08:16que entienden que su estrategia de comunicación
00:08:19no ha sido ideal y que las cosas mejorarán.
00:08:23Esa es la siguiente parte.
00:08:25¿De dónde vienen los problemas?
00:08:28El comunicado oficial señala a la IA como motivo,
00:08:32pero no en el sentido de que los ingenieros de GitHub
00:08:36en Microsoft usen IA y publiquen software defectuoso,
00:08:40o actualizaciones rotas en GitHub.
00:08:43Puede que esté pasando, pero no tenemos pruebas de ello.
00:08:47En cambio, la razón principal citada aquí es, obviamente,
00:08:51que debido a la IA, hay muchísimos más proyectos
00:08:57creándose, muchísimo más código generándose,
00:09:00y finalmente todos esos proyectos y todo ese código
00:09:03se suben a GitHub.
00:09:04Y comparten algunos gráficos que, bueno,
00:09:09no son de gran ayuda, pero ahí están.
00:09:12No ayudan mucho porque no hay un eje Y.
00:09:14No vemos las cifras absolutas,
00:09:17pero sí podemos ver las relaciones.
00:09:20Y podemos ver claramente que a lo largo de 2025,
00:09:23hubo un aumento pronunciado en pull requests fusionadas,
00:09:28commits enviados y, por supuesto, nuevos repositorios abiertos.
00:09:32Esos son todos nuestros proyectos secundarios que creamos
00:09:34y no terminamos con la ayuda de la IA.
00:09:36Y luego, en 2026, obviamente para todas estas métricas,
00:09:41el gráfico se dispara, bueno, hasta el cielo, supongo.
00:09:46Así que sí, es una tendencia bastante clara.
00:09:49Y este tráfico, este tipo de aumento en el tráfico,
00:09:54pondría bajo presión a cualquier sistema.
00:09:58Es particularmente problemático para GitHub
00:10:01porque están en medio de una migración
00:10:05desde una estructura monolítica y sus propios centros de datos
00:10:09o sistemas dedicados hacia la nube de Azure
00:10:13y hacia un sistema más fragmentado, de microservicios,
00:10:17se podría decir, en lugar de esa estructura monolítica.
00:10:21Ese era un proceso ya en curso antes de entrar en 2026.
00:10:26Pero, por supuesto, significa que ahora este proceso de migración
00:10:31se ve golpeado por ese pico en la demanda,
00:10:34lo que significa que, aunque estés migrando,
00:10:36tienes que estabilizar el sistema actual
00:10:39mientras continúas con la migración,
00:10:40que luego, con suerte, ayudará con ese aumento
00:10:44de tráfico en el futuro.
00:10:46Esa es la esperanza, por supuesto, no hay garantía.
00:10:50Pero, desde luego, es algo con lo que GitHub tiene que lidiar.
00:10:52Ahora, aquí afirman que empezaron a ejecutar un plan
00:10:56para aumentar la capacidad de GitHub 10 veces en octubre de 2025.
00:11:01Así que se podría decir que por aquí vieron que,
00:11:04bueno, todo esto estaba subiendo.
00:11:06Es decir, ya podían verlo desde antes,
00:11:09pero fue aquí donde decidieron que debían decuplicar su capacidad.
00:11:13Y luego, en febrero de 2026, vieron que,
00:11:16vale, necesitamos multiplicar por 30, no por 10 porque, bueno,
00:11:20debido a esa evolución aquí, ¿verdad?
00:11:22Eso, por supuesto, debe hacerse además de esa migración.
00:11:28Y esa es una tarea enorme, obviamente.
00:11:33Ahora bien, forma parte de Microsoft, así que no es una pequeña startup,
00:11:37pero, aun así, es una tarea de enormes proporciones.
00:11:39Y este es un aspecto de todo este problema de GitHub
00:11:44con el que simpatizo un poco porque creo que es fácil
00:11:47odiar a GitHub, burlarse de GitHub.
00:11:51Y definitivamente puedes hacerlo.
00:11:52Y volveré sobre más problemas que son realmente graves.
00:11:56Pero este tipo de aumento de tráfico sería un gran problema
00:11:59para cualquier sistema, para cualquier empresa.
00:12:03Y es difícil creer que cualquier competidor de GitHub
00:12:07lo haría mejor en esta situación.
00:12:09Aun así, por supuesto, eso no es excusa.
00:12:10Es parte de Microsoft.
00:12:12Y, por lo tanto, definitivamente tienen los recursos
00:12:16para llevar a cabo esa transición y ajustar sus sistemas
00:12:20a este nuevo mundo y a este nuevo volumen de tráfico.
00:12:24Pero hay otro problema importante aquí con GitHub.
00:12:28Y es que ya no tiene un CEO.
00:12:32El anterior CEO, Thomas, Thomas Domke,
00:12:37se jubiló o dimitió o anunció que dejaría el cargo
00:12:41en agosto de 2025.
00:12:43Y Microsoft no asignó un nuevo CEO.
00:12:48En su lugar, GitHub pasó a formar parte de Core AI,
00:12:51una división interna de Microsoft que, como su nombre indica,
00:12:56se centra en la IA y en la creación de herramientas y plataformas de IA.
00:13:01Y GitHub es parte de eso.
00:13:03Así que claramente la misión de GitHub desde la perspectiva de Microsoft
00:13:07es convertirse en parte de esa cadena de herramientas de IA,
00:13:11de esa revolución de la IA.
00:13:13Y obviamente Microsoft está integrando Co-Pilot
00:13:15en todos sus productos.
00:13:16Y de hecho, en GitHub Universe 2023,
00:13:20ya dijeron que transformarían GitHub
00:13:24en la plataforma de desarrollo impulsada por IA
00:13:28con "GitHub en todas partes".
00:13:30Eso incluye cosas como nuevas funciones
00:13:32que ayudan a crear "issues" con GitHub Co-Pilot,
00:13:36lo cual es un gran problema para los mantenedores de código abierto,
00:13:39pero también simplemente la presencia pura de GitHub Co-Pilot
00:13:43por todo GitHub.
00:13:44Existe esta sección de "Agent HQ" aquí en GitHub,
00:13:48[github.com/copilot](https://github.com/copilot),
00:13:49donde puedes interactuar con GitHub Co-Pilot
00:13:52y trabajar en tu código directamente desde GitHub Co-Pilot
00:13:55sin tener que abrir nunca un IDE local o una herramienta de agente
00:14:00y muchas, muchas partes más.
00:14:02GitHub Co-Pilot está en todas partes en GitHub,
00:14:05al igual que Co-Pilot está en todas partes
00:14:07en todos los productos de Microsoft, supongo.
00:14:10Y esa, por supuesto, es una decisión estratégica clara
00:14:14que en cierto modo va en contra de la misión real de GitHub,
00:14:19al menos la misión que GitHub tenía en el pasado.
00:14:23Porque, como mencioné al principio,
00:14:25GitHub es importante para diferentes tipos de desarrolladores
00:14:29para todo tipo de casos de uso.
00:14:31Los mantenedores de código abierto lo usan para tener su código
00:14:36allí y colaborar con otros mantenedores
00:14:39y otros colaboradores de la comunidad.
00:14:41Los "issues" son vitales para detectar, bueno, problemas
00:14:45y trabajar en ellos.
00:14:46Los "pull requests" son importantes para que otras personas
00:14:50contribuyan a la base de código.
00:14:52Las discusiones pueden ser geniales para debatir nuevas funciones
00:14:55o el rumbo de un repositorio o de una librería, etc.
00:15:01Hay muchas funciones relacionadas aquí
00:15:03que ayudan a los mantenedores de código abierto,
00:15:04o al menos ayudaban en el pasado.
00:15:07Otras personas usan GitHub simplemente como recurso
00:15:11para alojar enlaces o documentos,
00:15:13como todos esos repositorios "awesome": awesome Go, awesome Rust,
00:15:17etcétera, que puedes usar para encontrar recursos fácilmente
00:15:20si quieres trabajar con Go o Rust.
00:15:22Yo también uso GitHub para alojar los recursos de mis cursos,
00:15:26como aquí para mi curso de Codex, por ejemplo,
00:15:29y para muchos otros cursos también.
00:15:31Así que incluso se puede usar GitHub
00:15:33simplemente como una especie de almacenamiento de documentos.
00:15:36Y luego, por supuesto, también se puede usar GitHub para tareas de CI/CD.
00:15:40En una empresa, es posible que uses GitHub
00:15:43para tener allí tu código fuente, obviamente,
00:15:46y para que los miembros de tu equipo colaboren en ese código
00:15:50con "pull requests" y demás.
00:15:52Y luego, por supuesto, muy a menudo GitHub
00:15:54también forma parte del flujo de CI/CD,
00:15:57donde un nuevo "push" a la rama principal, por ejemplo,
00:15:59activa un proceso de CI/CD.
00:16:02Eso podría ser con la ayuda de GitHub Actions,
00:16:05aunque ese producto tiene sus propios problemas.
00:16:08Pero, por supuesto, también podría ser para activar un flujo de CI/CD
00:16:12en cualquier otro proveedor, no solo en GitHub Actions.
00:16:16Así que GitHub, por supuesto, tiene un papel muy importante
00:16:20para el trabajo de desarrollo clásico y tradicional.
00:16:24Pero, claro, Microsoft decidió que no,
00:16:27que debería convertirse en una plataforma de desarrollo con IA,
00:16:31no solo en una plataforma de desarrollo.
00:16:33Y eso, por supuesto, es una especie de desajuste aquí.
00:16:37Los desarrolladores no quieren necesariamente Co-Pilot
00:16:41en todos los aspectos de GitHub.
00:16:43Supongo que los usuarios de productos de Microsoft en general
00:16:46no quieren GitHub en todos sus productos,
00:16:48pero esa es otra historia.
00:16:49Y GitHub ha estado descuidando las funciones principales
00:16:53que son importantes para los desarrolladores.
00:16:56Y me refiero, por ejemplo, al trabajo de desarrollo de código abierto.
00:17:00Los mantenedores de proyectos de código abierto se están ahogando
00:17:03en "issues" y "pull requests" generados por IA.
00:17:07Ahora, el problema aquí, por supuesto, es la asimetría.
00:17:10Es fácil usar la IA para generar código o "issues".
00:17:14Es mucho más difícil revisar todo ese material.
00:17:19Es decir, revisar ese código y esos "issues" generados.
00:17:24Y esto es algo que todo desarrollador sabe,
00:17:26cualquiera que haya trabajado alguna vez con IA.
00:17:27Puedes activar fácilmente tres agentes de IA o más
00:17:30y hacer que trabajen en tus proyectos,
00:17:32totalmente fuera de GitHub.
00:17:33Puedes hacerlo en tu máquina con Codecs,
00:17:35Claude Code y demás.
00:17:36Pero luego, si no vas por la ruta del "vibe coding",
00:17:39que en mi opinión no deberías hacerlo,
00:17:41tienes que revisar ese código en algún momento.
00:17:44Y eso lleva tiempo.
00:17:45Y no es muy divertido, al menos para mí.
00:17:48Ahora, si activas tres agentes,
00:17:51tienes que revisar el resultado de tres agentes.
00:17:54Puedes reducir la cantidad de agentes si eso es demasiado
00:17:57para ti y ves que no eres realmente productivo
00:17:59de esa manera.
00:18:00Ahora bien, cuando eres mantenedor de código abierto en GitHub,
00:18:03te ahogas en "issues" y "pull requests" generados por IA
00:18:07y básicamente tienes dos opciones principales.
00:18:09Puedes ignorarlos, y eso anula su propósito,
00:18:13por supuesto, pero es una estrategia válida, obviamente.
00:18:16O intentas procesarlos todos
00:18:18y acabas quemado porque es simplemente demasiado,
00:18:21porque a diferencia de tu propio trabajo de desarrollo personal,
00:18:25no puedes simplemente reducir la cantidad de "issues"
00:18:29y "pull requests" entrantes.
00:18:30Tú puedes usar menos agentes por tu cuenta
00:18:33si ves que no eres eficaz o productivo
00:18:36con todos los agentes que intentas ejecutar.
00:18:38No puedes hacer eso con los repositorios públicos.
00:18:41No puedes controlar cuánta gente publicará "issues"
00:18:45generados por IA o compartirá "pull requests" contigo.
00:18:49Así que ese es un problema enorme para los mantenedores
00:18:53y la razón por la que toda la escena del código abierto
00:18:56y la filosofía que hay detrás del mismo
00:18:59tienen graves problemas ahora mismo por la IA.
00:19:04Y GitHub no está ayudando con eso.
00:19:06Al contrario, están haciendo lo opuesto.
00:19:08Están facilitando activamente que se compartan
00:19:13"issues" basura generados por IA y demás.
00:19:15Lo que los mantenedores y desarrolladores necesitarían
00:19:18serían herramientas más eficaces para lidiar
00:19:22con todos estos "issues" y "pull requests" generados por IA.
00:19:25Pero GitHub no está trabajando en eso.
00:19:27No es parte de su estrategia, supongo.
00:19:29Ahora bien, quizá eso cambie.
00:19:30Esa publicación oficial de GitHub que mencioné antes
00:19:35habla principalmente de los problemas de fiabilidad y tiempo de actividad
00:19:39y de que quieren ser más transparentes y demás.
00:19:41Pero también mencionaron que tienen el compromiso
00:19:44de apoyar a los desarrolladores.
00:19:46Ya veremos, no soy muy optimista
00:19:49porque, en última instancia, forma parte de Microsoft
00:19:52y ellos tienen su propia estrategia aquí.
00:19:55Pero ¿qué significa esto para GitHub entonces?
00:19:59¿Es hora de migrar a otra parte?
00:20:02He oído algunas voces aquí y allá en X
00:20:05diciendo que ya es hora de buscar una alternativa a GitHub.
00:20:08Sé que algunos proyectos han migrado.
00:20:12Zig es quizá el más destacado.
00:20:15Migraron de GitHub a Codeberg en noviembre de 2025.
00:20:20Pero seamos realistas.
00:20:22Por un lado, como mencioné antes,
00:20:24el volumen de tráfico que está recibiendo GitHub
00:20:28abrumaría también a cualquier competidor.
00:20:31Probablemente incluso más que a GitHub,
00:20:32porque no forman parte de Microsoft.
00:20:35Así que definitivamente no veremos cómo reemplazan a GitHub.
00:20:40Y aunque algunos proyectos individuales,
00:20:42especialmente de código abierto, puedan abandonar GitHub
00:20:45por razones que comprendo perfectamente,
00:20:48todas esas empresas y todos esos desarrolladores
00:20:52probablemente no migrarán.
00:20:54GitHub tiene, a pesar de todos sus problemas,
00:20:57una plataforma muy completa con funciones que son esenciales
00:21:02para los flujos de trabajo y el día a día de muchos desarrolladores.
00:21:06Especialmente para las empresas, por supuesto,
00:21:08no es fácil simplemente sustituir GitHub
00:21:11por algún otro proveedor.
00:21:13Aunque todos los problemas de fiabilidad
00:21:15son obviamente problemas graves también para las empresas,
00:21:18serán capaces y estarán dispuestas a soportar mucho más dolor
00:21:23antes de plantearse siquiera marcharse.
00:21:25Estoy seguro de ello.
00:21:26GitHub es una plataforma demasiado importante.
00:21:30Es la plataforma para poner tu código gestionado con Git
00:21:35en la nube y trabajar en él y colaborar.
00:21:39Así que estoy seguro de que no va a desaparecer,
00:21:43aunque la situación empeorara.
00:21:45Por supuesto, con el tiempo la gente se iría
00:21:47si GitHub no hiciera nada,
00:21:49pero está claro que lo están haciendo,
00:21:50al menos respecto al tiempo de actividad y la fiabilidad.
00:21:55En cuanto al código abierto y sus problemas
00:21:58y la basura generada por IA, ya veremos.
00:22:01Incluso ahí, creo que GitHub es demasiado importante
00:22:07y tiene demasiadas ventajas para los mantenedores
00:22:10como para irse sin más, al menos no todos ellos.
00:22:14Pero entiendo perfectamente si proyectos individuales
00:22:17se mudan fuera de GitHub, eso puede ocurrir.
00:22:20Pero sí, para las empresas y GitHub en general,
00:22:23seguirá estando ahí.
00:22:24No obstante, solo queda esperar que esta situación
00:22:28sea quizás una llamada de atención para Microsoft.
00:22:33Quizá vuelvan a poner a un CEO al frente de GitHub.
00:22:38Tal vez comprendan su importancia.
00:22:41Tal vez entiendan que es una plataforma para
00:22:45desarrolladores y desarrollo, no principalmente de IA.
00:22:49Pero bueno, se puede tener esperanza.
00:22:52No sé si ocurrirá eso ni cuándo.
00:22:55Pero sí, esa es la situación actual de GitHub.
00:23:00Está mal, realmente mal.
00:23:03Y seguirá estando mal en el futuro cercano,
00:23:06pero al menos la fiabilidad, con suerte, mejorará
00:23:11a finales de este año.
00:23:13Supongo que ya lo veremos.