Esta semana me tocó arreglar una herramienta que no pago. Estamos probando Postiz, un programador de publicaciones para redes sociales de código abierto, instalado en nuestros propios servidores. La plantilla con la que lo había desplegado se había quedado anticuada, el servicio no arrancaba bien y acabé enviando yo mismo la corrección.
No es un drama, pero sí un buen recordatorio. Cuando decimos que una herramienta autoalojada es gratis, nos olvidamos de una parte de la factura: la que se paga en tiempo, en mantenimiento y en sustos.
Y no es algo nuevo para mí. Cuando empecé en internet, el SaaS no era lo habitual: nos alojábamos todo. Foros con phpBB, portales con PHP-Nuke, directorios con Hyperseek, un script en Perl con el que hicimos recursosgratis.com… Si algo fallaba, lo arreglabas tú. Veinticinco años después, primero con el hosting y ahora con Stackscale, quería contar cómo decido hoy cuándo me lo monto yo y cuándo prefiero pagar.
Claves en 20 segundos
Autoalojado no es gratis. No pagas licencia, pero pagas en horas, en actualizaciones y en copias de seguridad.
El problema no es instalarlo, es mantenerlo. Lo difícil llega con la segunda actualización, no con la primera instalación.
Los datos tienen que sobrevivir a todo. Si una actualización puede borrarlos, no tienes un servicio: tienes una demo.
Mi regla: me lo monto yo si toca datos que no quiero fuera o si el SaaS es caro para lo que hace. Pago si es crítico y no tengo tiempo de cuidarlo.
Lo que me pasó esta semana con Postiz
Postiz es una alternativa de código abierto a herramientas de pago como IFTTT, Buffer, Metricool o Hootsuite: conectas tus cuentas de redes sociales, preparas las publicaciones y las dejas programadas. Con un matiz: en el caso de X, la herramienta es gratis, pero para publicar hay que conectar su API, y esa sí se paga.
Hasta ahora usábamos IFTTT, Make y Metricool. Las tres son buenas, pero con la cantidad de redes y medios que manejamos era el momento de optimizar ese gasto y apostar por una solución sólida que controlemos nosotros. El precio pesaba, pero también la privacidad y el control: las credenciales de nuestras redes sociales pasan a estar en nuestra infraestructura y no repartidas entre varios proveedores.
Lo tenemos desplegado con EasyPanel, un panel para gestionar aplicaciones en contenedores Docker, que a su vez corre sobre Proxmox VE, la plataforma de virtualización de código abierto.
EasyPanel tiene plantillas para instalar aplicaciones con un clic, y Postiz es una de ellas. El problema es que la plantilla se había quedado anticuada: Postiz había cambiado su arquitectura y necesitaba piezas nuevas que la plantilla no incluía, así que el servicio fallaba. En lugar de esperar, preparé la corrección y la envié al repositorio de plantillas de EasyPanel: está en esta petición en GitHub, pendiente de aprobación mientras escribo esto. Puede que cuando lo leas ya esté aprobada.
Con esa versión, Postiz ya funciona bien desde EasyPanel. Y no perdí nada, porque lo teníamos en pruebas, que es exactamente donde tienen que salir estas cosas.
Aquí apareció la pregunta importante. Postiz se actualiza a menudo, y cada actualización es una imagen Docker nueva. Si la configuración no está bien hecha, una actualización puede llevarse por delante la base de datos, las cuentas conectadas y las publicaciones programadas. Por eso la corrección también deja los datos en volúmenes persistentes, fuera del contenedor, para que sobrevivan a cada actualización.
Esa es otra parte del código abierto que no sale en las comparativas de precios: cuando algo falla, el soporte eres tú. Y a veces, si lo arreglas bien, lo arreglas también para todos los demás.
Lo que no cuenta el «es gratis»
Cuando comparas un SaaS con su alternativa autoalojada, la cuenta parece fácil: varias cuotas al mes contra cero. En nuestro caso, entre IFTTT, Make y Metricool, y con muchas redes y medios, esa cuota crecía cada vez que añadíamos algo. Pero esa cuenta deja fuera casi todo lo que importa:
El servidor. Aunque sea tuyo y ya lo tengas, consume recursos, electricidad y espacio.
Las actualizaciones. Hay que aplicarlas, comprobar que no rompen nada y, si rompen, volver atrás.
Las copias de seguridad. Si no las tienes y no las has probado, no las tienes.
La seguridad. Una herramienta expuesta a internet con acceso a tus redes sociales es un objetivo. Tienes que vigilarla.
El tiempo de diagnóstico. Cuando algo falla, no hay un equipo de soporte al otro lado. Estás tú, la documentación y los foros.
Nada de esto es un argumento contra el autoalojamiento. Es un argumento para hacer bien la cuenta. Si una herramienta te ahorra 20 euros al mes y te cuesta tres horas cada vez que se actualiza, quizá no estás ahorrando.
Cuándo me compensa montarlo yo y cuándo pagar
Con los años me he hecho unas preguntas sencillas antes de decidir:
Pregunta
Si la respuesta es sí…
¿Toca datos que no quiero que salgan de mi infraestructura?
Me lo monto yo
¿El SaaS cobra por usuario, por cuenta o por volumen y crece más rápido que mi uso?
Me lo monto yo
¿Hay una versión de código abierto madura, con comunidad y actualizaciones frecuentes?
Me lo monto yo
¿Si se cae, se para el negocio?
Pago, o lo monto con alguien que lo vigile
¿No tengo tiempo ni ganas de mantenerlo?
Pago
¿Necesito soporte con garantías y un responsable al otro lado?
Pago
Postiz cae en el primer grupo. Programar publicaciones no es crítico: si un día falla, publico a mano y no pasa nada. Las herramientas de pago de este tipo suelen cobrar por cuenta, por usuario o por volumen, y con tantas redes eso sube rápido. Y con EasyPanel actualizarlo es cuestión de minutos, siempre que la plantilla esté bien hecha.
Tenemos más cosas autoalojadas, aunque menos de las que me gustaría: n8n para automatizaciones y Matomo para la analítica de algunas webs. En mi lista de pruebas está Vaultwarden, un gestor de contraseñas compatible con Bitwarden. Y hay muchos casos típicos en los que se puede prescindir de un SaaS con poco esfuerzo:
Almacenamiento y documentos compartidos (Dropbox, Google Drive)
Nextcloud
Repositorios de código (GitHub privado)
Forgejo o Gitea
No todas cuestan lo mismo de mantener. Un monitor de caídas es casi instalar y olvidar. Un gestor de contraseñas, en cambio, guarda las llaves de todo lo demás: ahí la seguridad, las copias y las actualizaciones no son opcionales. Por eso sigue en pruebas.
Seguridad, privacidad y soberanía, con los pies en el suelo
Llevo tiempo escribiendo sobre soberanía digital europea, y el autoalojamiento es su versión a pequeña escala: decidir dónde viven tus datos y quién tiene la llave. Una herramienta de redes sociales guarda los accesos a todas tus cuentas. Un gestor de contraseñas, todas tus claves. Una analítica web, el comportamiento de tus lectores. Saber en qué servidor está todo eso, en qué país y bajo qué leyes no es un capricho: es privacidad y es cumplir con el RGPD.
Pero autoalojar también te hace responsable de la seguridad. Una herramienta expuesta a internet con acceso a tus redes es un objetivo, y si no la actualizas, el problema es tuyo. Por eso la soberanía no quiere decir hacerlo todo tú en un servidor debajo de la mesa.
En Stackscale (Aire) lo vemos cada día con empresas que quieren salir de las grandes nubes estadounidenses o reducir su dependencia de ellas. Lo que buscan no es montarse todo a mano, sino tener el control: saber dónde están sus datos, poder llevárselos y no depender de un proveedor que cambia precios o condiciones cuando quiere. Para eso hace falta infraestructura sólida en Europa y, muchas veces, alguien que la opere.
Con Postiz aplicamos lo mismo a nuestra escala: Proxmox para virtualizar, EasyPanel para desplegar y actualizar sin complicarnos, y todo en infraestructura propia. Lo importante no es la herramienta concreta. Es que los datos son nuestros, que podemos moverlos y que, si mañana un proveedor cambia sus condiciones, no perdemos nada.
Cierre
El código abierto y el autoalojamiento me parecen una de las mejores cosas que tiene internet. Pero conviene quitarles la etiqueta de «gratis». Son una decisión: cambias dinero por tiempo, y dependencia por responsabilidad.
A veces el cambio compensa, como con Postiz. Otras veces no, y entonces pagar es la decisión más inteligente. Lo que no conviene es elegir sin hacer la cuenta completa.
¿Y tú? ¿Qué tienes autoalojado y qué has acabado pagando después de intentarlo?
Preguntas frecuentes
¿Qué es Postiz? Una herramienta de código abierto para programar publicaciones en redes sociales, alternativa a Buffer, Hootsuite o Metricool. Se puede usar como servicio o instalar en tus propios servidores. Para publicar en X hay que conectar su API, que es de pago.
¿Qué significa autoalojar una aplicación? Instalarla y ejecutarla en tu propia infraestructura en lugar de usarla como servicio de un tercero. Controlas los datos, pero también te encargas del mantenimiento.
¿Es más barato autoalojar que pagar un SaaS? Depende. Te ahorras la cuota, pero pagas en tiempo, servidores, actualizaciones y copias de seguridad. Compensa sobre todo cuando el SaaS cobra por volumen o cuando los datos son sensibles.
¿Cómo evito perder datos al actualizar una app en Docker? Guardando la base de datos y los archivos en volúmenes persistentes, fuera del contenedor, y haciendo copia de seguridad antes de cada actualización.
¿Qué tiene que ver esto con la soberanía digital? Es la misma idea a pequeña escala: decidir dónde están tus datos, poder llevártelos y no depender de las condiciones que imponga un proveedor.
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.
