Este mes se ha corregido un fallo crítico en la forma en que el kernel de Linux abre conexiones TCP. Permite, en ciertas configuraciones, tomar el control de un servidor a distancia sin contraseña. Llevaba ahí once años. Lo reportó un investigador de Anthropic, y la compañía asegura que su modelo, Claude, escribió el exploit que demuestra que se puede atacar.
Once años de código abierto, a la vista de cualquiera. La lectura fácil es que el código abierto es inseguro. Yo creo que es justo la contraria.
Pero hay otra pregunta que me preocupa mucho más, y que ya dejé caer hace unos días en LinkedIn a raíz de PHP2Shell: si las máquinas van a encontrar fallos a un ritmo que nunca hemos visto, ¿quién va a pagar por arreglarlos?
Las claves en 20 segundos
El fallo CVE-2026-98432 estaba en el TCP del kernel de Linux desde la versión 4.4, unos once años, y se corrigió el 5 de octubre de 2026.
Ya pasó con Heartbleed, WannaCry, Log4Shell o xz; la diferencia ahora es la velocidad. En abril, un investigador usó Claude Code para encontrar en Linux otro fallo explotable en remoto que llevaba 23 años escondido.
Que el código abierto saque estos fallos no lo hace más inseguro: se encuentran precisamente porque el código se puede leer.
La NVD registró 49.972 vulnerabilidades en todo 2025; en 2026, a 24 de octubre, ya iban 88.602. El problema está en el otro lado: semanas después del parche, varias versiones de Ubuntu y de Red Hat seguían sin él.
La IA ha abaratado encontrar fallos. Arreglarlos sigue dependiendo de personas, muchas veces voluntarias.
Qué ha pasado con el fallo de TCP
Cada vez que un servidor acepta una conexión, el sistema hace un pequeño saludo con el otro lado antes de empezar a hablar. En ese saludo, en conexiones IPv4, había una condición de carrera: si dos cosas ocurrían en el momento justo, el kernel acababa leyendo memoria que ya había liberado. Es lo que los técnicos llaman un use-after-free, y es una de las puertas de entrada clásicas para un atacante.
El fallo entró en Linux 4.4 y se corrigió el 5 de octubre de 2026. El commit atribuye el aviso a Xinyang Ge, investigador de Anthropic. La compañía afirma que Claude escribió un exploit en dos fases que, en servidores que usan una variante de TCP llamada MPTCP, permite ejecutar comandos como administrador sin credenciales. En su prueba, filtrar una dirección de memoria del kernel llevó 48 minutos y tomar el control, cinco más. El exploit no se ha publicado y, hasta finales de octubre, no se conocían ataques reales.
Commit que corrige el CVE-2026-98432 en el kernel de Linux. Fuente: git.kernel.org.
Hay un matiz importante: por lo publicado, no está claro si fue Claude quien encontró el fallo o si encontró la forma de explotarlo una vez localizado. Para lo que quiero contar da igual, porque las dos cosas, encontrar y explotar, eran hasta hace poco trabajo de semanas para especialistas muy escasos.
La lectura fácil, y por qué es la contraria
Cuando aparece un fallo así, siempre hay quien concluye que el código abierto es un coladero. Once años con la puerta abierta y nadie se dio cuenta.
Yo lo veo al revés. Ese fallo se ha encontrado porque el código se puede leer. Cualquiera puede descargar el kernel de Linux, dárselo a un modelo y pedirle que busque problemas, que es exactamente lo que están haciendo investigadores de todo el mundo. En el software cerrado la deuda es la misma, o mayor, pero la revisan muchos menos ojos y, ahora, también muchas menos máquinas.
Lo escribí hace unas semanas a propósito de Stockfish, el mejor motor de ajedrez del mundo: lo abierto funciona porque cualquiera puede mirar dentro y mejorarlo. La seguridad es la otra cara de esa misma moneda. Mirar dentro también sirve para encontrar lo que está mal.
La historia se repite, pero más deprisa
Nada de esto es nuevo. Lo que ha cambiado es la velocidad.
2014, Heartbleed. En abril apareció un fallo en OpenSSL, la librería que cifraba buena parte de las conexiones seguras de internet. Lo revelador fue descubrir quién la mantenía: en 2013 el proyecto había recibido apenas 2.000 dólares en donaciones y tenía un solo desarrollador a tiempo completo. A raíz del susto, la Linux Foundation creó la Core Infrastructure Initiative, con más de 3 millones de dólares comprometidos por Google, Amazon, Facebook, IBM, Intel, Cisco o Dell.
2017, WannaCry. El 12 de mayo, un ransomware paralizó en horas ordenadores de hospitales, empresas y administraciones de medio mundo. Explotaba un fallo en el protocolo SMB de Windows para el que Microsoft había publicado el parche el 14 de marzo, casi dos meses antes. El problema no fue descubrir el fallo, sino que miles de sistemas seguían sin actualizar.
2021, Log4Shell. En diciembre apareció un fallo crítico en Log4j, una librería de registros de Java presente en miles de millones de aplicaciones. Muchas empresas ni siquiera sabían que la usaban. Y la mantenía un pequeño grupo de voluntarios en su tiempo libre. Su primer apoyo económico serio, casi 600.000 euros de la agencia alemana Sovereign Tech Agency, no llegó hasta 2023, dos años después del susto.
2024, la puerta trasera de xz. Alguien que firmaba como «Jia Tan» se pasó unos dos años ganándose la confianza de los mantenedores de xz, una librería de compresión presente en casi todos los Linux, presionándolos incluso con cuentas falsas, hasta convertirse en mantenedor y colar una puerta trasera. El 29 de marzo la descubrió por casualidad Andres Freund, un ingeniero que notó que SSH iba algo más lento de lo normal en una versión de pruebas de Debian. No llegó a las versiones estables por muy poco. Fue la prueba de que un mantenedor sobrecargado no es solo un problema de velocidad, también de seguridad.
2026, PHP2Shell. El 20 de octubre se dio el aviso y el 21 salieron los parches. Pero Amazon ya había detectado un intento de explotación el día 17, antes de que existiera la corrección.
2026, Node2Shell o HTTP2Shell. El mismo 21 de octubre, Node.js y Google publicaron parches para un desbordamiento de memoria en Brotli, la librería de compresión de Google que usan millones de servidores web. Se le dieron tres nombres porque primero apareció en Node.js y después se vio que alcanzaba también a librerías de Python, a .NET y a todo lo que llevara su propia copia de Brotli. Seis días después, la agencia de ciberseguridad estadounidense CISA ya lo incluía en su catálogo de vulnerabilidades explotadas. Y actualizar la librería del sistema no bastaba: había que reconstruir cada aplicación y cada contenedor que la llevaba dentro.
Doce años, la misma lección: el eslabón débil nunca es solo el fallo, es el tiempo que pasa hasta que se corrige donde de verdad importa. La diferencia ahora es que la IA está acortando ese margen por los dos lados: ayuda a encontrar fallos antes, pero también a convertirlos en ataques antes. En el caso del TCP de Linux, el exploit tardó menos de una hora en tomar el control del servidor de prueba.
No es un caso aislado
Y lo que hace distinto este año, además de la velocidad, es la frecuencia.
Abril de 2026, 23 años. Nicholas Carlini, también investigador de Anthropic, montó un script que recorría uno a uno los archivos del kernel de Linux y le pedía a Claude Code que buscara vulnerabilidades en cada uno. Así apareció un desbordamiento de memoria en el código de NFS, el sistema para compartir archivos en red, que llevaba ahí desde 2003. Y Carlini contaba que tenía cientos de posibles fallos más sin validar, porque no quería inundar a los mantenedores con avisos poco fiables.
Octubre de 2026, once años. El fallo de TCP del que hablo aquí.
Octubre de 2026, PHP2Shell. Dos vulnerabilidades en el propio lenguaje PHP, presentes desde la versión 5.4, que permitían ejecutar código en un servidor web sin iniciar sesión. Afectan a cualquier web en PHP, desde WordPress a Magento. Varios equipos las encontraron de forma independiente, y alguno de ellos reconoce que los modelos de IA fueron clave en el proceso.
Hay décadas de fallos acumulados en el software del que depende internet, y por primera vez tenemos una herramienta capaz de sacarlos a la luz de forma sistemática. Viene una ola, y no es una metáfora.
Y no lo digo por intuición. Hace unos días, cuando empezó a circular por LinkedIn la expresión «octubre negro», hice lo que suelo hacer con estos titulares: me descargué los datos. La base de datos de vulnerabilidades del NIST (NVD) registró 49.972 CVE en todo 2025. En 2026, a 24 de octubre, ya iban 88.602. Septiembre marcó un récord de 15.074 en un solo mes, frente a los 4.415 de enero de 2025. El volumen es tal que el NIST ya tiene que priorizar qué vulnerabilidades analiza.
CVE publicadas cada mes en la NVD, 2016-2026. Datos a 24 de octubre de 2026. Elaboración propia con datos de NIST, Anthropic, Wiz y PHP.
Un matiz para no vender humo: «octubre negro» no es un nombre oficial ni una campaña concreta, y en los días en que se hizo viral no había un pico especial. El salto viene de meses atrás. Y parte de la explicación es que la IA ya encuentra fallos a escala: Google Big Sleep en SQLite, OSS-Fuzz en OpenSSL, XBOW en lo más alto de la clasificación de HackerOne, la final del AIxCC de DARPA o Anthropic, que dice haber comunicado 6.157 vulnerabilidades en 591 proyectos de código abierto.
El cuello de botella es parchear
Encontrar el fallo es solo el primer paso de una cadena larga. Alguien tiene que entenderlo, escribir la corrección, revisarla, integrarla en el kernel, y después cada distribución tiene que llevarla a sus propias versiones. Y por último, cada administrador tiene que instalarla y reiniciar sus servidores. Quizá aquí la IA también acabe ayudando, y no solo a encontrar fallos: a acelerar la actualización de servidores donde las herramientas de automatización de siempre se quedan cortas.
El fallo de TCP es un buen ejemplo de lo que pasa en esa cadena. El parche llegó al kernel el 5 de octubre. A finales de octubre, Debian, Oracle Linux, Amazon Linux 2023 y algunas versiones de SUSE ya lo tenían. Pero a 2 de noviembre, casi un mes después del parche, Ubuntu seguía marcando como vulnerables todas sus versiones con soporte: de la 22.04 a la 26.10 con el arreglo «en curso», y la 16.04, 18.04 y 20.04 sin fecha. Red Hat 8, 9 y 10 también figuraban como afectados y sin fecha. Ni siquiera había acuerdo sobre la gravedad: el kernel le dio un 9,8 sobre 10; Red Hat, entre 5,9 y 8,1; Amazon, un 7,0.
Estado del CVE-2026-98432 en Ubuntu a 2 de noviembre de 2026: todas las versiones con soporte siguen vulnerables. Fuente: Ubuntu Security.
Estado del CVE-2026-98432 en Debian: ya corregido en los repositorios de seguridad de bookworm y trixie. Fuente: Debian Security Tracker
Con PHP2Shell pasó algo todavía más revelador. La PHP Foundation reconoció que un aviso relacionado, detectado por un desarrollador en 2024, se quedó estancado durante meses, y lo calificó de fallo estructural. Además, PHP ya no corrige las versiones 8.1 y anteriores, y una parte enorme de la web sigue funcionando en PHP 7.
No es que nadie quiera arreglar las cosas. Es que hay muy poca gente para hacerlo. Mucho código crítico de internet lo mantienen voluntarios o equipos muy pequeños, en su tiempo libre o con financiación precaria. Hasta ahora el ritmo de fallos encontrados les permitía ir tirando. Si ese ritmo se multiplica, no lo hará.
Lo que veo desde dentro
Esto lo vivo por los dos lados. En Stackscale (Aire) operamos infraestructura cloud privada en centros de datos europeos, y cada fallo crítico en el kernel o en el hipervisor significa planificar parches, ventanas de mantenimiento y reinicios sin afectar a los clientes. Y en Color Vivo mantenemos una red de más de cien webs, casi todas en WordPress y, por tanto, en PHP. Cuando salió PHP2Shell, la pregunta no fue si había que actualizar, sino en qué orden y en cuánto tiempo. Por suerte en este caso no son muchas máquinas virtuales el proceso se pudo completar en menos de 60 minutos de tiempo efectivo desde la publicación de las actualizaciones de Ubuntu, Debian y AlmaLinux.
Y, como desarrollador independiente, también estoy al otro lado. mboxshell, mi proyecto de código abierto más vivo, ya recibe contribuciones de personas que no conozco. Si mañana alguien me manda diez avisos de seguridad generados con IA, tendré que revisarlos uno a uno, en mi tiempo libre, sin cobrar por ello. Multiplica eso por miles de proyectos y tienes el problema.
Encontrar fallos se ha vuelto barato. Arreglarlos sigue siendo caro, y el coste recae en quien menos recursos tiene.
Quién debería pagar
No tengo la solución, pero sí tengo claro por dónde empezar.
Quien usa el código. Las grandes empresas, los proveedores cloud y los hiperescaladores construyen negocios enormes sobre Linux, PHP y miles de librerías abiertas. Financiar a sus mantenedores no es caridad, es mantenimiento de su propia infraestructura.
Las administraciones. Igual que pagamos carreteras y puentes, el software abierto del que dependen los servicios públicos es infraestructura crítica. Hace un mes escribí sobre un buzón que se ha pagado diecisiete veces; una fracción de ese dinero bien dirigida mantendría proyectos de los que depende media Europa.
Quien encuentra los fallos con IA. Los laboratorios que están sacando a la luz estas vulnerabilidades tienen una responsabilidad especial. No basta con avisar: hay que ayudar a arreglar, con parches propuestos, avisos bien validados y recursos para los equipos que reciben el aluvión. Que los mismos modelos que encuentran fallos ayuden también a corregirlos sería el mejor uso posible de esta capacidad.
Y cada uno de nosotros. Actualizar no es opcional: un parche que existe pero no se instala no protege a nadie, como demostró WannaCry. Pero con este ritmo no basta con contar parches pendientes. Hay que saber responder a tres preguntas: qué fallos son un riesgo real para mi negocio, qué equipos tengo de verdad expuestos y cuánto tiempo necesito para cerrar la puerta. Y cuando no se puede actualizar de inmediato, existen medidas de contención, como bloquear el ataque en un cortafuegos de aplicaciones o desactivar el servicio afectado, que dan margen mientras llega la corrección definitiva.
La deuda ya estaba ahí
La Inteligencia Artificial no ha creado estos fallos. Llevaban once, veinte, veintitrés años escritos en el código. Lo que ha cambiado es que ahora podemos verlos, y eso es una buena noticia. Es mucho mejor que los encuentre un investigador que los reporta que alguien que los vende.
Pero ver la deuda no es pagarla. Si seguimos tratando el mantenimiento del código abierto como un trabajo invisible que alguien hará gratis, la ola de vulnerabilidades que viene acabará encima de unas pocas personas que no dan abasto.
Encontrar fallos ya es barato. Arreglarlos, no. La pregunta es quién va a pagar la diferencia.
Preguntas frecuentes
¿Qué es CVE-2026-98432? Un fallo crítico en el TCP del kernel de Linux, presente desde la versión 4.4, que provoca un use-after-free al establecer conexiones IPv4. En servidores con MPTCP puede permitir ejecutar comandos como administrador de forma remota. Se corrigió el 5 de octubre de 2026.
¿Lo encontró una inteligencia artificial? Lo reportó un investigador de Anthropic, y la compañía afirma que su modelo Claude escribió el exploit. No está claro si Claude también localizó el fallo.
¿El código abierto es menos seguro que el cerrado? No necesariamente. Estos fallos se encuentran porque el código se puede revisar. El software cerrado también acumula fallos, pero los revisan menos personas y menos herramientas.
¿Qué tengo que hacer si tengo servidores Linux? Actualizar el kernel en cuanto tu distribución publique el parche y reiniciar. Revisa el estado en la página de seguridad de tu distribución, porque los plazos varían mucho.
¿Qué versiones de PHP corrigen PHP2Shell? Las 8.5.12, 8.4.27, 8.3.36 y 8.2.35, publicadas el 21 de octubre de 2026. Tras actualizar hay que reiniciar los procesos de PHP (por ejemplo, PHP-FPM). Las versiones 8.1 y anteriores ya no reciben parches.
En septiembre cerré GenPic. Estuvo abierto seis meses, de marzo a septiembre de 2026. Ingresos: 0,00 euros. Conversión: 0 %. Ni una sola venta.
Lo conté en LinkedIn sin adornos, y aquel post superó las 40.000 impresiones. Más atención de la que el producto recibió en toda su vida. Parece que a la gente le interesa mucho más un fracaso contado con números que un éxito contado con adjetivos.
Hace unas semanas escribí sobre cómo he vuelto a programar treinta años después gracias a Claude Code, y dejé caer una idea que hoy quiero desarrollar: construir nunca ha sido tan fácil, pero saber qué merece la pena mantener sigue siendo igual de difícil. Así que he hecho algo que casi nadie hace en público: repasar todo lo que tengo en marcha y decir qué sigue, qué está en el aire y qué cierro.
Las claves en 20 segundos
GenPic cerró sin una sola venta en seis meses, y su código está liberado en GitHub con licencia MIT.
No falló la tecnología: falló el encaje con el mercado. La vista previa gratis agotaba el valor del producto.
No todos los proyectos tienen que ganar dinero para seguir vivos, pero cada uno tiene que saber por qué existe.
Mis apps de Mac y Windows han facturado unos 4.000 euros en menos de seis meses: poco, pero real. Otras tienen descargas y siguen buscando su hueco.
Cuando un proyecto no sigue, liberar el código es una forma digna de cerrarlo.
GenPic: un producto bien hecho que nadie compró
GenPic convertía fotos en retratos pintados con inteligencia artificial. Tenía 73 estilos, cinco idiomas y un modelo de pago por descarga. La gente entraba, generaba su retrato gratis… y se marchaba.
Lo que más me costó aceptar es que el producto estaba bien hecho. Laravel 11, Livewire y Filament; pagos con Stripe y el IVA europeo resuelto con la ventanilla única (OSS); moderación de contenido, RGPD, accesibilidad, 178 tests y una infraestructura lista para cobrar en toda la Unión Europea. Nada de eso falló.
GenPic, cerrado y con su código liberado en GitHub.
Falló el encaje con el mercado. Regalábamos la vista previa y el valor percibido se agotaba ahí: quien ya había visto su retrato no sentía la necesidad de pagar por él. Y con ese modelo, cada prueba gratuita tenía un coste real en IA aunque nadie pagara. Llegamos tarde a un mercado donde generar imágenes ya empezaba a ser algo que la gente esperaba gratis.
En vez de guardarlo en un cajón, lo abrimos. El repositorio trae el embudo completo: subida de la foto, detección facial en el navegador, cola de generación, marca de agua, cobro con Stripe Checkout, entrega por URL firmada y borrado automático. También varios proveedores de IA con conmutación por error, Stripe Tax para el IVA europeo e internacionalización con hreflang. Piezas que cuestan semanas montar bien, ahora disponibles para cualquiera que construya algo con generación de imágenes, descargas de pago o un SaaS en Laravel multidioma. Está todo en GitHub, y la historia completa la contamos en el blog de Color Vivo.
Está cerrado y sin plan de mantenimiento, pero es de quien quiera usarlo, modificarlo o venderlo. A veces el mejor destino de un proyecto que no vende no es la papelera, sino un commit público.
Los cierres que nunca anuncié
GenPic es el cierre más reciente, pero no el único. Hay proyectos que cerré hace tiempo sin decirlo en voz alta, simplemente dejándolos estar.
bitadir.com, un directorio de blogs que fue popular en la primera época de los blogs, allá por los 2000, sigue ahí, latente, pero a efectos prácticos está cerrado, aunque refactorizado a PHP 8.4 hace unos meses desde PHP 5.4. Y los foros de programacion.net, que fueron un punto de referencia para muchos programadores de habla hispana en esa misma década, llevan tiempo muertos. Las webs siguen respondiendo, pero ya no hay vida dentro.
Es la forma más común de cerrar un proyecto, y probablemente la peor: no lo apagas, pero tampoco lo cuidas. Ni libera el sitio para otra cosa ni le da un final digno a lo que fue.
El problema nuevo: demasiados proyectos vivos
Durante años mi problema era el contrario. Tenía muchas más ideas de las que podía construir, y la mayoría se quedaban en una libreta. Con herramientas como Claude Code eso ha cambiado por completo: una idea de domingo puede ser una web funcionando el martes.
El cuello de botella se ha movido. Ya no es construir, es mantener. Cada proyecto vivo cuesta servidores, dominios, actualizaciones de seguridad, alguna consulta de usuarios y, sobre todo, atención. Y la atención es lo único que no escala.
Así que, para no engañarme, me he obligado a hacerme las mismas preguntas con cada proyecto:
¿Lo usa alguien además de mí?
¿Paga alguien, o podría pagar?
¿Lo uso yo cada semana?
¿Cuánto me cuesta mantenerlo, en dinero y en horas?
¿Llegué a tiempo al mercado?
¿Tendría más valor abierto que cerrado?
No hace falta responder bien a todas. Un proyecto que nadie paga puede seguir si sirve a mucha gente y cuesta poco. Pero un proyecto que no responde bien a ninguna tiene que irse, por mucho cariño que le tengas.
Lo que sigue porque es útil
Hay proyectos que no necesitan justificarse con ingresos. polenmadrid.com ofrece información de polen como servicio público y con una API gratuita que cualquiera puede usar. password.es, ipcalc y dnsgratis.com son utilidades sencillas que resuelven un problema concreto y aportan valor a quien las usa.
Cuestan poco y ayudan a mucha gente. Pasan la prueba sin cobrar un céntimo, y siguen.
Experimentos baratos, en observación
Luego están los experimentos que me apetecía hacer y que cuestan muy poco mantener. meteo.es era una web que llevaba años queriendo montar y ahora funciona prácticamente sola. spyonweb.net nació porque la herramienta original que usaba dejó de funcionar. AgentReady.md pensando en como ayudar a que las webs sean más visibles en los chat de las inteligencias artificiales y agentes que las visitan cada día.
No tienen un horizonte claro, y lo digo sin problema. Siguen mientras no cuesten casi nada y alguien los use. Pero con un compromiso: si algún día los cierro, el código no se tira, se libera.
Las apps: los primeros euros
Esta es la parte que más me ilusiona, porque aquí ya hay algo que GenPic nunca tuvo: clientes que pagan.
iSkitch, que nació cuando Evernote abandonó Skitch y me quedé sin mi herramienta de capturas, Mbox Viewer Pro y Arca Mail Backup están generando ingresos. En menos de seis meses, mis apps de Mac y Windows han facturado unos 4.000 euros. No es para tirar cohetes, pero da para pagar la fiesta de Claude Code y Codex. Y eso cambia por completo la conversación: la pregunta ya no es si a alguien le interesa, sino cómo hago que crezca.
Apps con descargas que buscan su hueco
Otras están en un punto intermedio. FitBono (para mi entrenador personal y gratis), ImageForge, KillEXIF o PDFSigna tienen descargas, así que hay gente que las encuentra y las prueba. Lo que todavía no está claro es el modelo: cuánto vale cada una, a quién se la vendo y por qué canal.
Estas semanas he estado subiendo mis apps a directorios como Softonic, Uptodown, Download.com o MacNative, y he confirmado algo que ya sospechaba. Hacer una app es hoy más fácil que nunca; conseguir que alguien la encuentre y pague por ella, no. La distribución sigue siendo el cuello de botella que la IA no ha resuelto. Estas apps siguen, pero con fecha de revisión.
mboxshell es mi pequeño caso de éxito en código abierto. Ya tiene contribuciones de personas que no conozco y está empaquetado en distribuciones como NixOS. Es la mejor sensación que puede dar un proyecto: que deje de ser solo tuyo. Y tiene una vuelta curiosa: Mbox Viewer Pro, una de las apps que ya facturan, está construida sobre mboxshell. El código abierto y el de pago no compiten; se alimentan.
El repositorio de mboxshell en GitHub.
FlarePurge siguió otro camino: empezó como app propia y acabé liberando su código fuente. Y CrawlForge, un rastreador SEO escrito en Rust, sigue buscando su hueco como open source.
GenPic se suma ahora a esta lista. Ninguno de estos proyectos me hace rico, pero ninguno se ha perdido. Liberar el código es la forma más digna de cerrar algo, porque lo que aprendiste haciéndolo puede servirle a otro.
Lo que viene: OwnLicense
Y aquí está lo que más me ha sorprendido de hacer este repaso. Los proyectos que no terminan de arrancar me han enseñado cuál es el siguiente que sí merece la pena.
Si mis apps tienen descargas pero cuesta convertirlas en ventas, y si vender fuera de la App Store o de la Microsoft Store es un lío de licencias, pagos e impuestos, el problema no es solo mío. Lo tiene cualquier desarrollador independiente que quiera vender por su cuenta. De ahí naceOwnLicense.com: una herramienta para vender apps fuera de las tiendas oficiales. Tiene web, pero todavía no está lanzada.
Y tiene una ventaja que GenPic nunca tuvo: el primer cliente soy yo. Si no me sirve para vender mis propias apps, no le servirá a nadie. Si me sirve, ya sé que hay al menos un problema real detrás.
Hay más ideas en el cajón, unas lanzadas y otras solo en la cabeza, pero esas se quedan para otro día.
Cerrar no es fracasar
Llevo en internet desde 1995 y he cerrado más proyectos de los que recuerdo. Durante mucho tiempo los cerraba en silencio, como quien apaga la luz de una habitación que ya no usa. Ahora creo que eso es un error, por dos razones.
La primera, porque contar un cierre con números ayuda a otros más que cualquier caso de éxito. Las 40.000 impresiones de aquel post sobre GenPic no fueron por el producto, fueron por la honestidad.
La segunda, porque cerrar es lo que deja sitio a lo siguiente. Cada proyecto que mantienes por inercia le quita horas al que de verdad podría funcionar. Y en una época en la que construir cuesta tan poco, saber soltar es probablemente la habilidad más infravalorada que tenemos.
Así que este es mi inventario a finales de octubre de 2026: un cierre reciente, un par de cierres que nunca había anunciado, varios que siguen y bastantes «ya veremos». Dentro de un año volveré a hacerlo, y te contaré qué ha cambiado. Seguro que algo de lo que hoy sigue se habrá ido, y quizá algo que hoy busca su hueco lo haya encontrado.
Y tú, ¿cuántos proyectos tienes vivos por pura inercia?
Preguntas frecuentes
¿Por qué cerró GenPic? Porque en seis meses no hizo ni una venta. La vista previa gratuita agotaba el valor percibido del producto y cada generación tenía un coste en IA que nadie pagaba.
¿Se puede usar el código de GenPic? Sí. Está publicado en GitHub con licencia MIT, así que se puede usar, modificar y vender. No tiene plan de mantenimiento.
¿Cómo decidir si cerrar un proyecto personal? Preguntándose si alguien lo usa, si alguien paga o podría pagar, si lo usas tú, cuánto cuesta mantenerlo y si tendría más valor como código abierto. No hace falta cumplir todo, pero sí tener una razón clara para que siga.
¿Qué es OwnLicense? Un proyecto todavía no lanzado para ayudar a vender apps fuera de la App Store y de la Microsoft Store.
A mi hijo Bruno le faltan once días para cumplir ocho años. Hace dos no sabía mover un caballo y hoy me gana seis de cada diez partidas. No recuerdo la primera partida que me ganó, pero no tardó mucho en llegar, y para él fue algo maravilloso. Desde entonces me gana cada vez más. Y no lo digo con resignación. Lo digo con un orgullo que no me cabe en el pecho.
Porque cuando lo veo pensar delante del tablero, callado, con la mano quieta encima de una pieza antes de moverla, pienso en todo lo que se habla estos días sobre inteligencia artificial, sobre niños que crecen con respuestas a un clic y sobre si sabrán pensar por sí mismos. Y creo que el ajedrez tiene algo que decir sobre eso.
Las claves en 20 segundos
Los grandes modelos de lenguaje juegan al ajedrez memorizando: en el banco de pruebas de Kaggle todos elegían la Defensa Siciliana, hasta que les obligaron a empezar desde otras aperturas.
Magnus Carlsen ganó en febrero de 2026 el primer Mundial FIDE de ajedrez Freestyle, donde las piezas se sortean y no sirve memorizar.
La ciencia es prudente: el ajedrez en la escuela tiene efectos positivos pero moderados, y no convierte a nadie en un genio de las matemáticas.
Lo que sí enseña, y he visto en casa, es a concentrarse, a perder sin excusas, a analizar el error y a pensar antes de pedir la respuesta.
Del tablero de la playa a las clases
No hubo ningún plan. En casa jugamos a todo tipo de juegos de mesa, y un día le hablé del ajedrez. Lo probamos y le encantó. A partir de ahí, todo fue rodado.
Empezamos a llevar un ajedrez a cualquier sitio, y todavía lo hacemos. Bruno descubrió enseguida que la mejor forma de jugar más era preguntar a quien tuviera delante si sabía. Aquel primer verano, en la playa, no se libró de una partida ni un amigo ni un conocido. Ver a un niño de seis años plantarle un tablero a un adulto y decirle «¿echamos una?» tiene algo que no se aprende en ningún sitio.
Luego llegaron las clases, y con ellas el salto. Pasó de mover piezas con intuición a hablar de desarrollo, de controlar el centro, de no sacar la dama demasiado pronto. Jugamos casi siempre con tablero físico; en pantalla, como mucho, alguna partida en Duolingo o en Chess.com.
También entraron los libros. Método Enigma, del misterioso Rey Enigma, es un manual pensado para niños, con una lección cada día y ejercicios. Y Atrapados en una partida de ajedrez, de Arthur Perrier, es una novela de aventuras en la que dos niños acaban dentro de un tablero gigante. Está recomendada a partir de nueve años y se la compramos un poco antes de tiempo, lo que dice bastante de lo picado que está.
Las máquinas que memorizan
Mientras Bruno aprendía, pasaba algo curioso con las inteligencias artificiales de moda. En agosto de 2025, Kaggle y Google DeepMind lanzaron Game Arena, una plataforma para medir a los grandes modelos de lenguaje enfrentándolos en juegos. La primera prueba fue el ajedrez. La idea era sencilla: en una partida no puedes copiar la respuesta de un examen que ya has visto.
Y ahí apareció el detalle que me parece más revelador de toda esta historia. Cuando les dejaban elegir, los modelos abrían todos con la misma defensa: la Siciliana. No porque la entendieran mejor, sino, con toda probabilidad, porque es una de las aperturas más jugadas y comentadas en todo lo que han leído. Los organizadores tuvieron que crear una variante que arranca desde veinte aperturas populares sacadas de Lichess para separar el cálculo real de lo memorizado.
Los modelos han mejorado mucho desde entonces, pero conviene poner las cifras en su sitio. En septiembre de 2026, el mejor de la tabla tenía una puntuación de 1.502 en la escala interna del torneo, que mide a los modelos entre sí y no es comparable con el Elo de un jugador. El motor del que hablé la semana pasada ronda los 3.650. Siguen siendo, para el ajedrez, unos generalistas que han leído mucho.
Y aquí está la diferencia con un niño que aprende. En el especial de aperturas de National Geographic, el gran maestro Miguel Illescas (sí, el mismo que trabajó en Deep Blue) no te pide memorizar líneas. Te explica por qué se juegan: desplegar las piezas, dominar el centro, enrocar pronto. Memorizar te da la jugada. Entender te dice qué hacer cuando la partida se sale del guion.
Carlsen y el ajedrez sin guion
Lo más llamativo es que los humanos llevan años con el problema contrario. Con motores como Stockfish en cualquier portátil, la preparación de aperturas en la élite se ha vuelto tan profunda que muchas partidas se deciden en casa, memorizando decenas de jugadas analizadas por la máquina.
Magnus Carlsen, el mejor jugador de su generación, decidió que eso le aburría. Junto al empresario Jan Henric Buettner impulsó el ajedrez Freestyle: antes de cada partida se sortea la posición de las piezas de la última fila, así que la teoría de aperturas deja de servir y cada partida empieza en territorio desconocido. En febrero de 2026, en Weissenhaus (Alemania), se jugó el primer Campeonato del Mundo FIDE de Freestyle. Lo ganó Carlsen.
Me parece una lección enorme para la época que vivimos. Cuando todos usan la misma herramienta y memorizan lo mismo, lo que marca la diferencia es lo que sabes hacer cuando el guion se acaba. Eso vale para el ajedrez, para programar con IA y para casi cualquier trabajo que conozco.
Lo que dice la ciencia, y lo que no
Aquí tengo que ser honesto, porque es fácil dejarse llevar. Se repite mucho que el ajedrez hace a los niños más listos o mejores en matemáticas. La realidad es más modesta.
Los investigadores Giovanni Sala y Fernand Gobet revisaron en 2016 los estudios disponibles, 24 en total. Encontraron que el ajedrez en la escuela mejora algo las matemáticas y la capacidad cognitiva, pero con efectos moderados, y que hacen falta como mínimo unas 25 o 30 horas de clase para notar algo a corto plazo. En trabajos posteriores fueron más allá: lo que se aprende en el tablero rara vez se traslada a otros terrenos, y algunos de los efectos podrían deberse a cómo estaban diseñados los estudios.
En España ya tuvimos nuestro momento de entusiasmo. En febrero de 2015, la Comisión de Educación del Congreso aprobó por unanimidad una proposición no de ley para implantar el programa «Ajedrez en la escuela». No era vinculante y nunca llegó a convertirse en ley nacional; han sido las comunidades autónomas y los propios colegios los que han ido moviendo ficha.
No cuento esto para quitarle valor al ajedrez, sino para ponérselo donde de verdad lo tiene. No vendo que Bruno vaya a sacar mejores notas por jugar. Lo que sí puedo contar es lo que veo cada semana en casa.
Lo que sí veo en casa
En Método Enigma hay una página que resume mejor que yo lo que el ajedrez le está dando a Bruno. La llaman los diez mandamientos de los jaquetones, y entre ellos están estos: nunca rendirse, jugar limpio, no poner excusas, no confiarse en posiciones ganadas, analizar cada derrota y felicitar al rival tras una buena partida.
Ninguno habla de matemáticas. Todos hablan de cómo comportarse cuando las cosas van bien y, sobre todo, cuando van mal.
Lo primero que aprende un niño en el ajedrez es a perder. No hay árbitro al que culpar, ni compañero de equipo, ni mala suerte con los dados. Si pierdes, es porque el otro jugó mejor o porque tú te equivocaste. Y la única salida es mirar la partida otra vez y entender dónde se torció.
Lo segundo es a pensar antes de actuar. En una época en la que cualquier pregunta tiene respuesta inmediata en una pantalla, el tablero obliga a quedarse quieto, calcular, dudar y decidir solo. Nadie te va a dar la jugada.
Y aquí vuelvo a León, a 1998 y a la idea del centauro de la primera entrega: el mejor resultado no lo daba la máquina sola, sino la persona que sabía pensar y usar la máquina a la vez. Bruno va a crecer rodeado de inteligencia artificial, igual que yo crecí rodeado de ordenadores. No me preocupa que la use. Me preocuparía que no supiera pensar sin ella. Y cada partida que me gana me tranquiliza un poco más.
Perder contra tu hijo
Empecé esta serie contando cómo, en 1990, mejoraba al ajedrez sin nadie al otro lado del tablero, perdiendo tarde tras tarde contra un programa en un Tandon 286. Treinta y tantos años después, al otro lado del tablero está mi hijo. Y sigo perdiendo, pero ahora es la mejor noticia posible.
El ajedrez lleva más de un siglo siendo el lugar donde medimos a las máquinas: desde el autómata de Torres Quevedo hasta Deep Blue, Stockfish o los modelos de lenguaje que hoy abren todos con la Siciliana. Las máquinas ya ganaron esa carrera hace tiempo. Lo que el ajedrez sigue midiendo, y mejor que nunca, es otra cosa: cómo pensamos nosotros cuando no hay nadie que nos dé la respuesta.
No sé si Bruno será un gran jugador, y me da igual. Sé que está aprendiendo a perder, a concentrarse y a buscar la mejor jugada por sí mismo. Con eso podrá enfrentarse a la vida, y a la inteligencia artificial, de tú a tú.
Con esta entrega cierro la serie. Gracias por acompañarme en el viaje, de Torres Quevedo a la mesa de mi casa. Ahora, si me disculpáis, me debe la revancha.
Para seguir jugando
Todos los libros que han ido saliendo en la serie, por si te apetece seguir:
Cuentos, jaques y leyendas, de Manuel Azuaga. Historias del ajedrez dentro y fuera del tablero, con prólogo de Miguel Illescas. Lo he leído y lo recomiendo juegues o no.
Edición especial de National Geographic: Aperturas, del gran maestro Miguel Illescas. Para aprender a empezar una partida entendiendo el porqué de cada jugada. Hay más especiales de la serie: estrategias, tácticas y finales.
Preguntas frecuentes
¿Las inteligencias artificiales como ChatGPT o Gemini juegan bien al ajedrez? Mucho mejor que hace un año, pero lejos de un motor especializado. En el banco de pruebas Game Arena de Kaggle tendían a repetir aperturas memorizadas, y su puntuación se mide en una escala propia entre modelos, no comparable con el Elo de los jugadores.
¿Qué es el ajedrez Freestyle? Una variante en la que se sortea la posición inicial de las piezas de la última fila, de modo que no sirve la teoría de aperturas. Magnus Carlsen ganó el primer Campeonato del Mundo FIDE de Freestyle en febrero de 2026.
¿El ajedrez mejora las notas de los niños? Los estudios muestran efectos positivos pero moderados en matemáticas y capacidad cognitiva, y poca transferencia a otras materias. Su valor más claro está en hábitos como la concentración o saber gestionar la derrota.
¿A qué edad puede empezar un niño a jugar al ajedrez? No hay una edad fija. Muchos niños empiezan entre los cinco y los siete años, cuando ya pueden seguir reglas y mantener la atención en una partida corta.
