CK Geek

21 de mayo de 2026

El creador de OpenClaw gastó 1,3 millones de dólares en tokens de OpenAI en un mes: así es como se construye software en 2026 sin pensar en el coste

Peter Steinberger, el creador de OpenClaw y empleado de OpenAI desde febrero de 2026, publicó hace unos días una captura de pantalla que generó conversación en toda la industria: su factura de la API de OpenAI durante los últimos 30 días. La cifra exacta: $1.305.088,81. El gasto cubrió 603.000 millones de tokens en 7,6 millones de solicitudes, usando GPT-5.5 como modelo principal. No lo pagó de su bolsillo —OpenAI cubre el coste como inversión en investigación—, pero el número en sí mismo es el dato más honesto que ha circulado en meses sobre lo que cuesta realmente desarrollar software con agentes de IA autónomos operando a plena capacidad, sin presupuesto límite. Lo cuenta Alina Maria Stan en The Next Web el 18 de mayo de 2026. Steinberger describe el experimento con una pregunta directa: «¿Cómo construiríamos software en el futuro si los tokens no importaran?»

Cien agentes Codex trabajando en paralelo

El equipo detrás del gasto es minúsculo: tres personas. Lo que hacen esas tres personas es orquestar permanentemente unos 100 instancias de Codex corriendo en paralelo en la nube. Cada agente tiene una función específica:

Revisión automática de pull requests
Escaneo de commits en busca de vulnerabilidades de seguridad
Deduplicación de issues en GitHub
Escritura de soluciones y apertura de PRs automáticos basados en la hoja de ruta del proyecto
Monitorización de benchmarks y alertas de regresiones en Discord
Algunos agentes incluso asisten a reuniones y abren PRs para funciones que surgen en conversación

El resultado: un proyecto de código abierto que funciona con la cadencia de un equipo mucho mayor, sin contratar más personas. «Toda esa automatización nos permite operar este proyecto de forma extremadamente austera», escribió Steinberger. Las críticas en X fueron inmediatas: «No puedes gastar 1,3 millones al mes en tokens y llamarlo lean».

OpenClaw es el proyecto de código abierto que el propio Steinberger describió en abril como la señal de que 2026 es el año del agente de IA general: un framework que conecta modelos como ChatGPT o Claude con apps de mensajería y ejecuta tareas reales del mundo. Antes de que Steinberger se uniera a OpenAI, OpenClaw se convirtió en el proyecto open source con el crecimiento más rápido de la historia de GitHub, superando las 302.000 estrellas en abril de 2026, por delante de React, Vue.js y TensorFlow en velocidad de adopción.

El matiz que cambia los números: Fast Mode vs Standard

Steinberger fue transparente sobre la aritmética. El titular de 1,3 millones de dólares refleja el uso en Fast Mode, el modo de ejecución premium de Codex que consume créditos a una tasa significativamente mayor. Si se desactiva Fast Mode, el coste mensual cae a aproximadamente 300.000 dólares, una reducción del 77%. O en otros términos: en modo estándar, la operación equivaldría a unos 60 suscripciones de Codex Pro a 200 dólares/mes (que incluyen el equivalente de 5.000-6.000 dólares en valor de API cada una).

Siguen siendo números enormes. A 300.000 dólares al mes en modo estándar, el coste anualizado es 3,6 millones de dólares para un equipo de tres personas. Para comparar: en San Francisco, ese gasto equivale aproximadamente al salario anual de seis ingenieros senior. La pregunta que nadie de la industria quiere responder en público es si el output —código, revisiones, auditorías de seguridad— vale esa cifra o más.

Codex de OpenAI compite directamente con Claude Code de Anthropic y con Cursor en la carrera por quién controla cómo se escribe software profesional en 2026: OpenAI trasladó Codex a facturación por tokens en abril, lo que hace estos costes más visibles, y más variables, para usuarios avanzados.

Lo que revela la factura sobre la economía de la IA

El gasto de Steinberger es útil precisamente porque los vendedores de herramientas de IA para desarrollo rara vez publican consumo real de tokens a esta escala. OpenAI estima que Codex cuesta entre 100 y 200 dólares al mes por desarrollador de media, pero advierte de alta varianza. Steinberger pone un número a esa varianza: en el extremo máximo, un equipo técnico puede gastar más de 400.000 dólares al mes por agente activo en Fast Mode. Eso equivale a unos 13.000 dólares por instancia mensual en el modo más caro.

Para equipos de empresa que evalúan si desplegar flotas de agentes de codificación a escala, esta cifra es el único benchmark transparente que existe. La conclusión no es que la tecnología no valga —OpenClaw funciona, el código se produce, las revisiones de seguridad se ejecutan—, sino que la economía de los agentes de código a escala real es completamente diferente a lo que los precios de suscripción sugieren.

Cursor 3, con su modelo propio Composer 2 y agentes autónomos, es otro de los actores que está redefiniendo la misma ecuación en 2026: menor dependencia de los modelos de los rivales, mayor control sobre los costes de inferencia. La guerra del código en IA es también, fundamentalmente, una guerra sobre quién controla los costes de los tokens que mueven esos agentes.

Mi valoración

Tras revisar los datos publicados y los cálculos que circularon en X y The Decoder, lo que me convence de la postura de Steinberger es la honestidad del número. La industria lleva meses hablando de agentes de código que «trabajan solos»: esta cifra pone un precio concreto a lo que eso significa en producción real. Lo que me genera más dudas es la extrapolación. OpenClaw es un proyecto donde OpenAI tiene interés directo en que Steinberger demuestre lo que se puede hacer con tokens ilimitados. Es un entorno de investigación, no una empresa con constraint de rentabilidad. Para el 99% de los equipos que no tienen acceso gratuito a GPT-5.5 a este volumen, las conclusiones operativas son limitadas.

Lo más estructuralmente relevante: el gasto de 1,3 millones deja visible que los laboratorios de IA están subvencionando masivamente el coste real de los tokens para crecer en adopción. Cuando esas subvenciones se ajusten, la economía de los agentes de código va a parecer muy diferente.

Preguntas frecuentes

¿Quién pagó los 1,3 millones de dólares?

OpenAI, el empleador de Steinberger. Al unirse a la compañía en febrero de 2026, parte del acuerdo incluye acceso gratuito a la API para el desarrollo de OpenClaw, que sigue siendo código abierto. Steinberger describió el gasto como «los beneficios del apoyo de OpenAI a OpenClaw».

¿Qué hace OpenClaw?

OpenClaw es un framework open source de agentes de IA que conecta modelos de lenguaje como GPT-5.5 o Claude con apps de mensajería (WhatsApp, Telegram, Discord) y permite al usuario delegar tareas reales: enviar emails, gestionar archivos, automatizar flujos de trabajo. Pasó de ser un proyecto personal a la mayor velocidad de crecimiento de la historia de GitHub.

¿Cuánto costaría replicar esto para una empresa normal?

En modo estándar (sin Fast Mode), la operación equivaldría a unos 3,6 millones de dólares anuales para 100 agentes Codex activos. Una empresa que quisiera desplegar, por ejemplo, 10 agentes de código autónomos en producción debería esperar costes en el rango de 300.000-400.000 dólares anuales usando GPT-5.5 a las tasas actuales. Sin subvención del proveedor.

La noticia El creador de OpenClaw gastó 1,3 millones de dólares en tokens de OpenAI en un mes: así es como se construye software en 2026 sin pensar en el coste fue publicada originalmente en Wwwhatsnew.com por Natalia Polo.

☞ El artículo completo original de Natalia Polo lo puedes ver aquí

20 de mayo de 2026

GitHub confirma la exfiltración de 3.800 repositorios internos tras una extensión maliciosa de VS Code

GitHub confirmó una intrusión iniciada en el equipo de un empleado tras instalar una extensión maliciosa de Visual Studio Code, que derivó en la exfiltración de unos 3.800 repositorios internos. La compañía retiró la versión maliciosa, aisló el dispositivo y rotó credenciales críticas, mientras continúa la investigación.

Entry image

El incidente vuelve a poner el foco en un punto débil recurrente en la seguridad del desarrollo: el endpoint del desarrollador. Aunque muchas organizaciones concentran controles en el perímetro, en CI/CD o en el propio repositorio, una simple instalación en el editor puede abrir la puerta a robo de credenciales, acceso a código y movimiento lateral. En este caso, el vector inicial fue una extensión de Visual Studio Code manipulada con fines maliciosos instalada en el equipo de un empleado.

Tras el compromiso del dispositivo, se produjo la exfiltración de aproximadamente 3.800 repositorios internos de GitHub. GitHub aseguró que no hay evidencias de impacto en datos de clientes fuera del conjunto de repositorios afectados, un matiz importante porque este tipo de fuga suele mezclar código, documentación, scripts de despliegue y, en el peor de los casos, secretos incrustados por error. Como parte de la respuesta, la empresa retiró del VS Code Marketplace la versión maliciosa de la extensión, aisló el endpoint comprometido y rotó credenciales críticas el mismo día, priorizando los secretos más sensibles.

La atribución pública está en evolución. El actor TeamPCP reivindicó el acceso y llegó a ofrecer los datos presuntamente robados por un mínimo de 50.000 dólares, acompañando la presión con amenazas de filtración gratuita si no aparecía comprador. A falta de verificación independiente completa, el episodio encaja con una serie de campañas atribuidas a TeamPCP desde marzo de 2026, orientadas a ecosistemas de desarrollo y a compromisos de cadena de suministro, donde la rapidez es parte de la ventaja del atacante. En incidentes recientes, la ventana de exposición puede ser de minutos: un ejemplo citado en el sector es la retirada de una versión con backdoor de una extensión popular, Nx Console, en cuestión de decenas de minutos, lo que ilustra que confiar solo en reacciones del marketplace no basta para entornos corporativos.

Los análisis técnicos publicados en torno a esta oleada describen técnicas de persistencia especialmente preocupantes para equipos que clonan repositorios con frecuencia. Se ha observado un patrón denominado Mini Shai Hulud, descrito como un gusano de cadena de suministro capaz de persistir mediante modificaciones en ficheros de configuración del propio entorno de desarrollo. Entre las señales a vigilar destacan inyecciones en .vscode/tasks.json con disparadores como folderOpen, y cambios en el directorio .claude, por ejemplo .claude/settings.json o ficheros inesperados como .claude/setup.mjs, con disparadores tipo SessionStart. El riesgo práctico es la reinfección: basta con volver a clonar un repositorio contaminado y abrirlo para reactivar tareas o flujos que descarguen y ejecuten carga maliciosa.

En la misma cadena técnica se han descrito abusos de scripts de instalación en npm, como preinstall o postinstall, junto con la descarga y ejecución del runtime Bun como bootstrap del payload. Para investigación y hunting, se ha propuesto buscar en historiales de commits el indicador IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner, que se ha usado como marca de infección en casos relacionados. También conviene añadir detecciones en EDR y SIEM para ejecuciones de bun iniciadas tras npm install o por procesos de VS Code, además de patrones de conexiones a objects.githubusercontent.com asociadas a instalaciones, cuando se utilicen como mecanismo de descarga.

El impacto potencial no se limita a la fuga de código. En campañas atribuidas a TeamPCP se han documentado técnicas contra GitHub Actions, incluyendo el envenenamiento de versiones mediante force push que repunta múltiples tags hacia commits maliciosos. Este enfoque puede permitir el robo de secretos en runners y, en escenarios avanzados, intentos de lectura de memoria del proceso Runner.Worker. Además, se han observado canales de exfiltración y mando y control mediante dominios typosquat y, de forma oportunista, el uso de GitHub como canal alternativo, por ejemplo creando repositorios públicos para volcado cifrado o utilizando patrones de búsqueda de commits como dead drop.

En términos defensivos, la lección principal es tratar las extensiones del IDE como software con capacidad equivalente a un agente privilegiado. Es recomendable restringir la instalación de extensiones en VS Code mediante políticas corporativas, allowlists y bloqueo de orígenes no autorizados, y mantener un inventario auditado de extensiones instaladas en los equipos de desarrollo. También se recomienda no basarse en ficheros de recomendación del repositorio como mecanismo de control y aplicar controles a nivel de máquina mediante MDM o políticas gestionadas.

En paralelo, debe asumirse que cualquier repositorio interno puede contener credenciales expuestas por error o accesos útiles para pivotar. Por eso, conviene rotar tokens y secretos que pudieran existir en repositorios, automatizaciones y sistemas de build, incluyendo PATs, credenciales de CI, secretos de GitHub Actions y tokens de GitHub Apps. Tras la rotación, es clave revisar registros y telemetría para detectar abuso posterior, accesos anómalos, clonados masivos y operaciones fuera de patrón. Para minimizar el radio de explosión, aplicar mínimo privilegio a cuentas de desarrollador y permisos a repositorios reduce lo que un atacante puede extraer desde un único endpoint comprometido.

Como medida preventiva adicional, es útil imponer un periodo de enfriamiento para nuevas versiones de extensiones y dependencias, por ejemplo 24 a 72 horas, antes de permitir su instalación o actualización en equipos y en CI, y endurecer la cadena de dependencias en npm con lockfiles, npm ci y, cuando sea viable, desactivar scripts de ciclo de vida con ignore-scripts en CI. En entornos maduros, limitar el acceso directo de equipos y runners a registros públicos y enrutar descargas a través de un proxy o registro privado con control de egress reduce la superficie. Finalmente, conviene monitorizar señales de exfiltración encubierta, como creación inesperada de repositorios públicos o commits con patrones anómalos, porque la salida de datos no siempre ocurre por canales tradicionales.

GitHub ha indicado que publicará un informe más completo cuando termine la investigación. Mientras tanto, el caso sirve como recordatorio de que la cadena de suministro no empieza en el repositorio, empieza en el editor, en el gestor de paquetes y en cada actualización que un desarrollador instala para trabajar más rápido.

Más información

BleepingComputer – GitHub confirms breach of 3,800 repos via malicious VSCode extension : https://www.bleepingcomputer.com/news/security/github-confirms-breach-of-3-800-repos-via-malicious-vscode-extension/amp/
The Record (Recorded Future News) – GitHub confirms being hacked by TeamPCP, says customer data unaffected : https://therecord.media/github-confirms-teampcp-hack-customers-unaffected
Aikido Security (blog) – GitHub breached via a malicious VS Code extension: why developer devices are the real target : https://www.aikido.dev/blog/github-breached-vs-code-extension
Hive Security (blog) – One Extension, 3,800 Repos: Inside TeamPCP’s GitHub Breach : https://hivesecurity.gitlab.io/blog/github-breach-vscode-extension-teampcp-2026/
Phoenix Security (blog) – TeamPCP’s Five-Day Siege: How One Stolen Token Cascaded Across GitHub Actions, Checkmarx, VS Code Extensions, and npm : https://phoenix.security/teampcp-supply-chain-attack-trivy-checkmarx-github-actions-npm-canisterworm/
Unit 42, Palo Alto Networks (research) – The npm Threat Landscape: Attack Surface and Mitigations (Updated May 1) : https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/?_wpnonce=e85efdbd7a&lg=en&pdf=print

La entrada GitHub confirma la exfiltración de 3.800 repositorios internos tras una extensión maliciosa de VS Code se publicó primero en Una Al Día.

☞ El artículo completo original de Hispasec lo puedes ver aquí

La Tierra tiene un compañero de viaje desde hace millones de años y no sabemos de dónde salió, pero hay una nave preparada para darnos respuestas

La Tierra no viaja sola alrededor del Sol. Y no solo por la Luna, que lógicamente la acompaña siempre, orbitando a su alrededor. También tiene varios compañeros de viaje: unos objetos, llamados coorbitales, que tardan exactamente lo mismo que nuestro planeta en dar una vuelta completa alrededor del astro rey. Estos objetos son bien conocidos, pero su origen es bastante misterioso.

Hay astrónomos que apuestan por que escaparon del cinturón de asteroides. Sin embargo, su contenido en silicatos apunta a que podrían ser fragmentos de la Luna que saltaron de su superficie tras el impacto de un meteorito. Ahora, un equipo de científicos ha asignado probabilidades a cada opción, aunque para la prueba definitiva de su origen tendremos que esperar aún un poco.

(469219) Kamo'oalewa. Así se llama uno de los coorbitales más conocidos de la Tierra. Mide entre 24 y 107 metros de diámetro y los análisis espectrales que se han podido realizar con telescopios como el el Large Binocular Telescope (LBT) y el Lowell Discovery Telescope (LDT) indican que es muy rico en silicatos, de modo que es probable que proceda de la Luna. De hecho, la hipótesis más aceptada hasta el momento señala que pudo formarse durante el impacto que dio lugar al cráter Giordano Bruno de nuestro satélite. Sin embargo, este nuevo estudio, publicado en la revista Icarus, apunta a que es más probable que se trate de un asteroide fugado del cinturón que hay entre Marte y Júpiter.

En Xataka

Una filtración ha dejado al descubierto el plan de China para pisar la Luna: su distancia con la NASA se está estrechando

Muy improbable. Para que un asteroide o un trozo de la Luna se puedan convertir en coorbitales no solo deben escapar de su lugar. También deben tener suficiente energía para ubicarse en lo que se conoce como órbita cuasi-satelital. Esto, para un cuerpo del tamaño de Kamo’oalewa, es altamente poco probable.

¿Cuasi-qué? Un cuasi-satélite tiene ciertos parecidos con un satélite, pero no es lo mismo. Cuando miramos uno de ellos desde el planeta al que acompaña, en dirección hacia el Sol, parece que está en órbita alrededor del planeta, pero en realidad gira al propio Sol. Esto, entre otros motivos, se debe a que está fuera de la esfera de Hill del planeta. Es decir, el entorno dominado por la gravedad del mismo. Al estar fuera de dicha órbita, le influye la gravedad del planeta, pero sobre todo, en este caso, le influye la del Sol. Sea como sea, caer y mantenerse en esa órbita es complicado, como ya hemos visto y, sobre todo, como han demostrado estos científicos.

Gana la opción del asteroide. Estos científicos han realizado modelos en los que se simula la trayectoria de 12.000 partículas sintéticas lanzadas desde la superficie lunar a diferentes velocidades y ángulos, siguiendo sus órbitas durante millones de años. El objetivo era ver cuántas se estabilizaban en puntos coorbitales con la Tierra. En total encontraron 70 objetos de diámetro superior a 10 metros capaces de hacerlo. ¡70 de 12.000! Ahora bien, cuando repitieron el procedimiento cambiando partículas lunares por objetos del cinturón de asteroides, dieron con más candidatos. 1.600 en total.

Tianwen-2 devolverá las muestras para dar respuesta al misterio en 2027

La clave la tendrá Tianwen-2. El origen de los coorbitales es tan intrigante que China ya ha mandado una nave a analizar la superficie de uno de ellos. Concretamente del propio Kamo’oalewa. La misión Tianwen-2 partió en mayo de 2025 hacia este objeto, con el objetivo de recoger al menos 100 gramos de muestras y devolverlas a la Tierra para su análisis.

Ya se sabe que hay silicatos, o al menos se sospecha, pero se necesita tener una idea más profunda de la composición para comprender cuál es el origen de este objeto. Se espera que la inserción en la órbita se produzca el próximo mes de junio si todo va bien. Después pasará unos meses recolectando muestras para introducirlas en una cápsula, que aterrizará de vuelta en la Tierra ya en 2027.

Dos opciones. Si los análisis de Tianwen-2 concluyen que Kamo’oalewa procede de la Luna, habría que replantearse la mecánica de impacto lunar, ya que sería muy raro que uno de esos fragmentos hubiese podido llegar a su ubicación final con lo que sabemos hasta ahora. En cambio, si se demuestra que procede de un asteroide, habría que estudiar de dónde proceden esos silicatos, pues son muy poco convencionales en un objeto de estas características. Se concluya lo que se concluya, va a haber mucha tela que cortar, eso está claro. ç

Imagen | NASA |Servicio de Noticias de China

En Xataka | La Tierra tiene lunas que no conocemos: explorarlas es clave para revelar los secretos de nuestro sistema solar

-
La noticia La Tierra tiene un compañero de viaje desde hace millones de años y no sabemos de dónde salió, pero hay una nave preparada para darnos respuestas fue publicada originalmente en Xataka por Azucena Martín .

☞ El artículo completo original de Azucena Martín lo puedes ver aquí

Si la pregunta es si los centros de datos de IA acaban incrementando las temperaturas en una región, la respuesta es: 2,2 ºC

Un grupo de investigadores de la Universidad de Arizona State han publicado un estudio llamativo. Han querido estimar cuál es el impacto de los centros de datos de IA en las temperaturas medias de la región en la que se instalan. Su conclusión es inquietante, porque ese aumento puede ser de hasta 2,2 ºC.

El uso masivo de la IA plantea otro problema. Hay un debate ya claro sobre el consumo de agua y energía de los centros de datos de IA, pero este estudio ha puesto el foco en un problema igualmente importante: la contaminación térmica.

Hace calor. Los investigadores se centraron en el área metropolitana de Phoenix, la más calurosa de todo EEUU. Allí sus análisis indicaron que los centros de datos expulsan aire de sus sistemas de refrigeracion a temperaturas que son entre 14 y 25 grados Farenheit por encima de la temperatura ambiente, creando térmicas que pueden afectar a los vecindarios cercanos.

En Xataka

España tiene un plan para captar más centros de datos que nadie: "blindarles" ante los costes de la energía

El aire lo dice todo. Esta es la primera investigación conocida que utiliza sensores de alta precisión montados en vehículos con los que se comparó la temperatura del aire antes y después de pasar por las instalaciones. Los datos fueron claros: las zonas a favor del viento de un centro de datos registraban temperaturas medias 1,6 ºF más altas, con picos de 4 ºF (2,2 ºC) respecto a las zonas de referencia.

Efecto "isla de calor". El impacto de ese aumento de temperatura es además notable en cuanto a distancia afectada: se detectaron dichos incrementos incluso a 500 metros de distancia de la fuente, lo que equivale a unas cinco "manzanas" de viviendas en la ciudad de Phoenix.

Círculo vicioso. El propio diseño de los centros de datos hace que este problema se retroalimente. Un solo centro de datos puede generar tanto calor residual como una pequeña ciudad de 40.000 hogares, y el ciclo vicioso es claro:

El centro de datos expulsa aire muy caliente para enfriar sus servidores
El aire calienta el vecindario circundante
Los vecinos usan más sus aparatos de aire acondicionado
Los aparatos de aire acondicionado expulsan aún más calor residual

La ubicación es la clave. David Sailor, que lideró el estudio, indicó que lo que buscan con sus conclusiones no es prohibir los centros de datos, sino replantear su integración con los núcleos urbanos. Para evitar o mitigar los problemas se proponen soluciones como la reorientación de las salidas de aire o la creación de parques que amortiguen esos aumentos de temperatura. La clave, aseguran estos investigadores, es la planificación urbana: deben tratarse estas instalaciones como fuentes de emisiones térmicas industriales, porque es lo que son.

Prevenir antes que curar. La capacidad de cómputo proyectada para los centros de datos que se construirán en EEUU se duplicará en 2030, lo que hace que según este estudio sea necesario tomar medidas. El reto, dicen, es lograr aplicar estas soluciones antes de que ese calor residual generado por los centros de datos se convierta en un problema de salud pública.

España también puede tener ese problema. Los proyectos que afectan a nuestro país también deberían tener en cuenta esta circunstancia. En los últimos meses hemos visto como la Comunidad Autónoma de Aragón ha centrado parte del protagonismo de los acuerdos con grandes tecnológicas, y tanto Amazon como Microsoft tienen centros de datos proyectados en el área metropolitana de la ciudad de Zaragoza. Las localidades de Villamayor de Gállego y Villanueva de Gállego, están a menos de 20 km de Zaragoza, y ambas ya tienen proyectados centros de datos. Dichas iniciativas prometen impulsar la economía de la región, pero también traen dudas consigo. No todo el mundo está a favor de dichos centros, desde luego, y hay incluso procesos judiciales intentando detener su construcción.

Imagen | David Vives y AWS

En Xataka | La gran paradoja de Madrid: la región con el mayor déficit energético de España se está quedando los centros de datos

-
La noticia Si la pregunta es si los centros de datos de IA acaban incrementando las temperaturas en una región, la respuesta es: 2,2 ºC fue publicada originalmente en Xataka por Javier Pastor .

☞ El artículo completo original de Javier Pastor lo puedes ver aquí

La Web versión 0.0: cuando aquí no había ni gatos ni «influencers»

Hubo un tiempo, antes de Google, las redes sociales y ChatGPT… en que la web era un experimento extraño lleno de ideas que pudieron ser y no fueron. Relatar cómo surgió y cómo se construyó es un proyecto al que Jay Hoffmann le ha dedicado tiempo a modo de proyecto personal. El resultado es The History of the Web, una cronología que de momento abarca entre 1988 y 2017, y que permite apreciar su evolución y curiosidades.

La cronología se puede ir recorriendo en una sola página siguiendo los enlaces, o suscribiéndose al boletín quincenal, que va acumulándose en forma de archivo de artículos sobre tecnologías, personajes y momentos clave de la web. Hay ya 102 artículos en total. Además de esto también hay una sección llamada Vague, But Exciting (la famosa frase del jefe de Tim Berners-Lee), una especie de libro en desarrollo dividido en capítulos temáticos: navegadores, buscadores, diseño web, estándares, CSS o las guerras de los navegadores.

La historia temprana de la web fue toda una sucesión de inventos y caminos alternativos que casi cambian Internet por completo. Comenzó en 1989 con la propuesta de Tim Berners-Lee en el CERN y siguió con el HTML, el protocolo HTTP y los primeros navegadores web. Poco después llegarían Mosaic y Netscape, y pronto surgieron sitios como Yahoo, Amazon, eBay… Con el cambio de siglo surgieron empresas y proyectos gigantescos como Google (1998) o Wikipedia (2001).

Por el camino surgieron algunas cosas que hoy en día son cotidianas, como el primer banner publicitario, el favicon, los webblogs o los primeros cibercafés. Viendo toda la cronología queda claro que la web no nació siguiendo un «plan maestro» fue más bien una colección de experimentos, ocurrencias y decisiones improvisadas que acabaron funcionando. Pero está bien así, aunque ande un poco amenazada hoy en día.

Relacionados:

# Enlace Permanente

☞ El artículo completo original de alvy@microsiervos.com (Alvy) lo puedes ver aquí