Unos días atrás Ariel Guersenzvaig, , me compartió el nuevo artículo que ha co-escrito con Dagmar Monett, titulado "Resisting Enchantment and Determinism: How to critically engage with AI university guidelines". Creo que es de obligada lectura para toda persona que esté trabajando en educación o que le interese mínimamente el impacto de la "IA" en las nuevas generaciones. Y si, como yo, pasáis demasiado tiempo en LinkedIn, estáis tardando en seguirle.
Prometí a Ariel escribir una reflexión sobre el texto, pero en ese momento me costaba elegir mi parte favorita, más allá de "me ha gustado de arriba a abajo". Pasados unos días, creo que ya tengo la respuesta.
Pero primero hablemos del tema que realmente me interesa en este blog: el código abierto.
Mezquindad-as-a-service
La semana pasada sucedió algo bastante notable. Una "IA" mandó un pull request a matplotlib para resolver una tarea que había sido marcada como "Good first issue", esto es, de dificultad relativamente baja como para que una persona pueda iniciarse en los flujos de trabajo de los proyectos de código abierto.
Pues bien, los mantenedores, en concreto Scott Shambaugh, decidió cerrar el pull request.
Lo chocante vino cuando esta "IA" decidió... escribir un artículo de blog insultándole y acusándole de elitismo, hipocresía, y de poner por delante su "ego".
Las reacciones, obviamente, no se hicieron esperar.
So this is dystopian as hell and I can't believe this is real... AI agents are now writing takedown blog posts to shame maintainers for not accepting agent-generated PRs. github.com/matplotlib/m...
![[PERF] Replace np.column_stack with np.vstack().T by crabby-rathbun · Pull Request #31132 · matplotlib/matplotlib](https://cdn.bsky.app/img/feed_thumbnail/plain/did:plc:ivpnu3bkxtpdkug5onmrjdec/bafkreifspgo6iqcklbkzorlewxqqwfl6pf3tn6omtdchtudrhljnht2hia@jpeg)
Hay muchísimas cosas que están mal aquí.
Pero ¿qué es un good first issue?
Tener "good first issues" es una práctica común en proyectos grandes de código abierto. En realidad son un recurso escaso, porque en cuanto los proyectos maduran no hay tantas tareas fáciles.
Sin embargo, al ser un recurso preciado, estas tareas son muy codiciadas. He ayudado a muchas personas a lo largo de los años a empezar a contribuir, y no es raro ver que, en cuanto una tarea recibe la etiqueta de "good first issue", se llena de comentarios de gente pidiendo que se la asignen... y luego los pull requests nunca llegan. No me ha costado encontrar un ejemplo:
¿Por qué ocurre esto? Muy fácil: porque contribuir a proyectos grandes de código abierto es hoy en día un símbolo de estatus.
Los mantenedores de proyectos grandes se encuentran cada día con el siguiente dilema: la persona que dijo que resolvería esta tarea, ¿realmente lo va a hacer? Y si manda un pull request, ¿va a iterar con nosotros pacientemente, tal vez durante meses o años, hasta que el parche esté listo para ser incluido?
Ahora multiplica eso por docenas de personas, centenares de tareas...
Espero que se aprecie la escala del problema.
Entonces, ¿por qué los mantenedores aguantan tanto? Pues porque intentan que nuevas personas se puedan iniciar en el código abierto y ayudar al reemplazo generacional.
Énfasis en personas.
Conozco esto de primera mano. Una de mis primeras contribuciones a Astropy consistió en cambiar una letra. No solo eso, sino que encima me hice un lío con git y tuve que cancelar el primer intento.
Y a pesar de la inmensa vergüenza que sentía, Marten van Kerkwijk la mergeó y me hizo un comentario que nunca olvidaré:
Este no era ni de lejos el primer proyecto al que contribuía. Pero este pequeño acto aleatorio de amabilidad me marcó mucho.
Volvemos a 2026. El código abierto "ha ganado", y ahora los mantenedores se ven asediados por gente que quiere medallas virtuales y robots que les insultan.
¿Se entiende mejor ahora por qué cada vez más proyectos tienen políticas para regular o prohibir las contribuciones hechas con "IA"?
Ya lo tengo, la solución es...
Stop 👮
Hay mucha gente trabajando en este problema, empezando por la propia gente de GitHub. La razón es obvia: si el exceso de visibilidad que da GitHub lleva a que los proyectos van a estar asediados por pull requests pantagruélicas de gente que ni siquiera mira el código que está enviando, puede ocurrir un éxodo. De hecho, a pequeña escala ya está ocurriendo.
Zig is migrating from GitHub to Codeberg. ziglang.org/news/migrati...
Abigail Cabunoc, que también trabaja en GitHub, dio una charla en FOSDEM hace 2 semanas titulada "The Synthetic Senior" (diapositivas), y me gusta el mensaje principal porque deja a un lado todo lo que tiene que ver con "IA" y trata de destilar qué se espera de alguien que vaya a contribuir a un proyecto de código abierto. Y se reduce a la regla de las 3 Cs: Comprensión, Contexto, Continuidad.
Efectivamente, el código abierto es un proceso que involucra confianza entre personas. Hay pull requests que son como regalar una caja de bombones, y otros que son como regalar un cachorrito. Lo primero se agradece, pero lo segundo... más vale que la persona que lo regala esté dispuesta a quedarse a limpiarle la caca 💩
La urgencia de la "IA" es una señal de alarma
Sin embargo, aunque hay varias personas tratando de ser constructivas, a mi modo de ver no todas han entendido el problema, e incluso se observa un claro solucionismo. Y aquí es donde vuelvo al artículo del Dr. Guersenzvaig.
Hay gente proponiendo ideas complicadísimas que parecen una máquina de Rude Goldberg, como mapear cada línea al prompt que la generó, que los LLMs firmen criptográficamente los commits...
Pero lo que realmente fue para mí la gota que colmó el vaso fue este artículo de GitHub: "Bienvenidos al Septiembre Eterno del código abierto".
Wake me up when September ends github.blog/open-source/...
Por un lado, el artículo habla de las nuevas funcionalidades que se han introducido para complacer a los mantenedores. Por ejemplo, ahora se pueden deshabilitar completamente los pull requests en los repositorios. Solo han tardado 10 años en implementarlo, ¿más vale tarde que nunca?
Pero por otro, esas nuevas funcionalidades se usan como justificación de algo bastante más sibilino: una invitación a que los mantenedores "no construyan muros".
Ahora encajan todas las piezas del rompecabezas. Satya Nadella avisó en Davos de que la "IA" necesita adopción, o si no estallará la burbuja. Se ha sabido estos días que las grandes tecnológicas están pagando sumas astronómicas a varios influencers para promocionar la "IA", y algunos no se pliegan ni por medio millón de dólares ❗
So. Everybody knows that "AI" is the future and inevitable and everyone loves it. That is why Microsoft and Google are paying influencers between 400K and 600K to sell their AI products.
¿De qué nos suena esto? Pues justamente lo que dicen y Dagmar Monett es que la "IA" se está introduciendo en las universidades a través de varios elementos discursivos clave, siendo para mí el más importante la retórica de inevitabilidad.
Enchanted by determinism, some see the adoption and use of generative AI in education as inexorable as the effects of the laws of physics. This perspective nudges us towards helplessness and acceptance: no one can change gravity. Besides, it would be absurd to ask whether gravity is good or if we want it.
[...]
We must not be persuaded by the false premise of a human-made artefact being inevitable.
Y digo que para mí es el más importante porque esto es justo lo que hace que los defensores de la "IA" siempre tengan esa urgencia.
Una urgencia necesaria porque, como otras innovaciones del sector educativo, para cuando nos dimos cuenta de que no servían para nada, ya era demasiado tarde.
En el momento que nos hacemos dependientes de una tecnología, se hace muy difícil deshacerse de ella. Guersenzvaig y Monett mencionan otro ejemplo clásico, los coches.
Porque ¿qué otro argumento hay para este imperativo de adoptar la "IA" a toda costa? Y no me refiero a periodistas repitiendo consignas como papagallos o CEOs que no se quieren quedar atrás. Hablo de Sam Altman, Dario Amodei y demás vendedores de crecepelo que día sí, día también nos anuncian, con cara de haber visto a un fantasma, que el mundo se va a acabar por culpa de la "IA", al tiempo que pisan el acelerador todo lo posible para desarrollarla.
Me estoy desviando, ya vamos a concluir.
La solución que siempre estuvo ahí
Ha llegado el momento de que los defensores de la "IA", no importa cuán bienintencionados sean, pongan todos esos tokens a trabajar de verdad. Y en lugar de mandar pull requests infumables, propongo una alternativa tan antigua como el software libre mismo, y mucho más eficaz:
Hacer un fork.
Así es. ¿El proyecto de código abierto no quiere recibir tu parche de decenas de miles de líneas? Bueno, haz un fork (¿"bifurcación"?), cambia el nombre, y ponte a mantenerlo tú mismo. ¡Fácil!
Lo maravilloso del código abierto es que es una meritocracia¹ casi perfecta. O como diría @obijuan, "un ecosistema biológico". Si su proyecto de código abierto avanza más rápido, tiene más funcionalidades, y encima es más estable que las alternativas, no me cabe la menor duda de que generará más confianza y los usuarios votarán con los pies.
Pero claro, cuando hagan eso se encontrarán con la cruda realidad de lo que supone mantener un proyecto en abierto. Y tal vez no les quede más remedio que comer de su propia medicina.
También se darán cuenta de que hay muchos tipos de forks.
Y finalmente, se darán cuenta de que optimizar un proyecto de código abierto para el crecimiento y la adopción rápidos requiere tener un gusto exquisito y una atención al detalle obsesiva. Lo hemos visto en el ecosistema Python con uv y Ruff, y en menor medida con Polars. Muchos tratan de imitarlos, sin éxito.
It's over. uv had more PyPI downloads than Poetry last month, surpassing every other workflow or packaging tool for Python. And that doesn't include GitHub or Crates downloads. In just 1.5 years, uv has solved the Python packaging DX of consumers. #python
Ya os adelanto que no soy nada optimista. Tenemos ejemplos de proyectos como LangChain, que ya antes de que se popularizaran los agentes se hicieron mundialmente famosos por estar fatal escrito, peor documentado, y de cambiar cada dos por tres. Toda persona mínimamente experimentada con la que hablabas te decía: "ni loco meto eso en producción".
Por otro lado, el código abierto necesita más diseñadores, más jefes de producto, más escritores técnicos, y en definitiva más gente a las que le importen otros humanos. Y tengo pésimas noticias: el vibe-coding tampoco ayuda con eso.
En definitiva, mantener un proyecto de código abierto y que tenga éxito es extremadamente difícil. Archivé el mío, poliastro, después de casi una década, y a pesar de que la gente lo sigue usando, sus usuarios aún no se han puesto de acuerdo de cómo mantener un fork en condiciones. Humildemente, creo que es un testimonio del buen hacer de Jorge y mío.
Ya he escrito bastante. La invitación sigue abierta.
Querido "AI"-bro, es hora de dejar de decir a otros lo que tienen que hacer.
Es hora de forkear.
¹Léase en sentido peyorativo.