Windows XP y el problema de durar demasiado bien

Hoy, 25 de octubre, Windows XP cumple 25 años. Salió el 25 de octubre de 2001 y su soporte extendido no terminó hasta el 8 de abril de 2014: casi doce años y medio. Y una variante construida sobre él, Windows Embedded POSReady 2009, la de los terminales de venta, siguió recibiendo parches hasta abril de 2019.

Para poner esas cifras en contexto:

• Cuando acabó su soporte principal, en abril de 2009, seguía siendo, con diferencia, el Windows más usado.
• Según StatCounter, Windows 7 no le arrebató el primer puesto hasta octubre de 2011. Diez años después de su lanzamiento.
• En abril de 2014, el mes del corte, NetMarketShare aún lo contaba en más de una cuarta parte de los ordenadores de escritorio: un 26 %.

Hace unas semanas hablábamos de la versión que no debería haber existido. Hoy toca la contraria: la que no había manera de jubilar.

El tema Luna de Windows XP. Captura de Windows XP (Microsoft, 2001), reproducida con fines informativos. Derechos de sus titulares.

Por qué duró tanto

Hay cuatro razones y ninguna es «porque era muy bueno», aunque lo fuera.

1. Era suficiente. XP fue la versión que por fin llevó la arquitectura estable de la rama profesional al ordenador de casa. Estable y compatible a la vez, que era exactamente lo que llevaba años sin conseguirse. Y en cuanto un producto es suficiente, deja de haber motivo para cambiarlo.

2. El sucesor tardó y decepcionó. Windows Vista se retrasó hasta enero de 2007 y su recepción fue mala. Microsoft llegó a prolongar la venta de XP hasta mediados de 2008 porque los fabricantes seguían teniendo clientes que lo pedían. Ese hueco de seis años es una eternidad.

3. El hardware dejó de obligar. Durante los noventa, un ordenador se quedaba corto en pocos años: cada versión pedía el doble de todo. A partir de mediados de los 2000 esa presión se relajó mucho. Un equipo de 2003 seguía haciendo el trabajo de oficina en 2010 sin quejarse.

4. Y la razón de verdad: se incrustó. XP acabó dentro de cajeros automáticos, terminales de punto de venta, equipos médicos, maquinaria industrial, sistemas de señalización, tornos de acceso. Y ahí el sistema operativo no es un producto: es un componente de una máquina cuyo ciclo de vida son quince o veinte años.

Esa cuarta razón es la importante, porque es la que convierte el éxito en un problema.

Cuando tu software se convierte en la pieza de otra cosa

El fabricante de una resonancia magnética o de una máquina de producción no vende software. Vende un equipo carísimo, homologado, con certificaciones que costaron años y con un contrato de mantenimiento a década y media vista.

Actualizar el sistema operativo de dentro no es «actualizar»: puede exigir nuevas validaciones y repetir parte de la certificación. Y muchas veces el software de control ni siquiera es suyo, sino de un proveedor que desapareció en 2011.

Así que no se actualiza. Se aísla, se documenta como excepción y se sigue.

Cuando en mayo de 2017 llegó WannaCry, el gusano de cifrado que se propagaba por redes internas, la ironía es que XP no fue el principal protagonista: en pruebas, el intento de propagación podía provocarle un pantallazo azul en lugar de infectarlo. De las detecciones que registró Kaspersky, el 98 % fueron Windows 7, equipos sin parchear que tenían la corrección disponible desde marzo. La lección no era de XP, sino de lo que XP representa: redes con sistemas que nadie actualiza. A veces por dejadez, y a veces porque la decisión de no tocarlos se tomó años antes por motivos perfectamente razonables, y para entonces deshacerla era mucho más difícil y caro.

Es la misma cadena de dependencias que veíamos hace unos días con los proveedores: el riesgo no vive en tu decisión, vive en la decisión que tomó otro y que tú heredaste.

El éxito como condena

Aquí está la parte que sirve para tu trabajo, y no requiere tener cajeros automáticos.

Cuanto mejor sea una versión, más difícil será retirarla. Suena a paradoja y es pura aritmética: la retirada depende de que exista un motivo para moverse, y un producto que hace bien su trabajo elimina ese motivo.

Piensa en tus propios sistemas:

• La versión de la API que todo el mundo sigue usando porque funciona, mientras la v2 lleva tres años esperando.
• El script de una persona que ya no está y del que dependen dos procesos del cierre mensual.
• El servidor que nadie toca, que nadie sabe reinstalar y que lleva ocho años sin fallar. Precisamente por eso da miedo.
• La hoja de cálculo con macros que sustituyó a un proyecto de 60.000 euros y que funciona mejor.

Ninguno de esos casos es un fracaso. Todos son éxitos que se han convertido en deuda por el mero paso del tiempo, y ninguno tiene fecha de caducidad escrita en ninguna parte.

Lo que sí se puede hacer

Tres cosas, y la primera es la que casi nadie hace:

1. Escribir la fecha de fin de vida el día del lanzamiento. No cuando empieza a estorbar: el primer día, cuando aún no molesta a nadie y por tanto no hay que negociarla. «Esta versión de la API se mantiene hasta junio de 2029.» Es gratis escribirlo entonces y carísimo pactarlo después.

2. Saber qué hay ahí fuera. Un inventario de versiones en producción, en clientes, en máquinas de terceros. La pregunta no es qué versión mantenemos, es quién sigue usando cuál. Casi nunca hay respuesta, y esa ausencia es la que hace imposible planificar cualquier retirada.

3. Presupuestar la migración antes de necesitarla. Una migración planificada con dos años de margen se puede repartir, probar por partes y hacer sin urgencias. La misma migración con tres meses porque se acaba el soporte, no. Lo que cambia es quién elige la fecha.

Feliz aniversario

Tres cosas para hoy:

1. Elige tu Windows XP particular: el sistema que funciona demasiado bien como para tocarlo. Escribe en un documento por qué sigue ahí y qué haría falta para sustituirlo.
2. Busca la fecha de fin de vida de tu componente más crítico. Si no la encuentras, pregúntala al proveedor y deja la respuesta por escrito. Si él tampoco la tiene, es una decisión que alguien tomó por omisión.
3. Pregunta a tus clientes qué versión están usando. Y cruza lo que te digan con tus registros: puede haber instalaciones que hace tiempo que no te mandan nada. Los datos que faltan suelen estar en los sitios donde nadie mira.

(Y ese fondo de escritorio de la colina verde: es una fotografía real, hecha por Charles O'Rear en Sonoma. La cosa más honesta de toda una década de informática.)