'Versionitis' en Linux: los números de versión nunca importaron, y siguen sin hacerlo

El kernel Linux 5.0 ha llegado. Parece un hito importante para el componente fundamental de las distribuciones Linux (o GNU/Linux, como queráis) utilizadas por millones de personas. ¿Lo es?

No. Como el propio Linus Torvalds destacaba en el anuncio de la nueva versión, ese "5.0" no significa nada distinto de los números 4.x que le precedieron. El único problema, reconoce Linus, es que esos números estaban siendo "lo suficientemente grandes para que me quedara sin pies y manos" para contar. La versionitis no es un problema de Linux y el Open Source, y lo demuestran desarrollos que tardaron años en llegar a esa primera versión "estable" 1.0.

Cinco grandes versiones en 25 años

El kernel Linux se publicó en su versión 1.0.0 en marzo de 1994. Dos años después, en junio de 1996, llegaría Linux 2.0. Esa fue la rama más longeva porque en realidad sus propias ramas tuvieron ciclos realmente largos: la 2.2 apareció en 1999, la 2.4 en 2001, y la larguísima 2.6 que se lanzó en 2003 por primera vez y no daría el salto a la versión 3.0 hasta julio de 2011.

Esa rama 2.x del kernel Linux ha sido la más longeva con diferencia hasta ahora, porque Linux 4.0 apareció en abril de 2015, y desde entonces han ido apareciendo sucesivas versiones hasta la última de esa familia, la 4.20, que apreció el pasado mes de diciembre.

Lo que no ha cambiado demasiado en ese interminable esquema de numeración ha sido el ciclo de aparición de nuevas versiones del kernel: se anuncia una nueva versión cada 75 días aproximadamente, y aunque unas veces esos anuncios se producen con cierta antelación o cierto retraso, una cosa está clara para los desarrolladores del kernel: el número de versión importa más bien poco.

De hecho esos números de versión son simplemente una forma de poder tener un poco más organizado un sistema que funciona como un reloj y que simplemente se dedica a corregir errores y añadir nuevas características de forma inexorable. Unas veces hay características más reseñables para el gran público que otras, pero si hay algo característico del núcleo de Linux es su constante evolución.

Las versiones, insistimos, no importan, y de hecho esa es una constante en el mundo Open Source en el que algunos desarrollos han tardado años en ser declarados lo suficientemente estables o completos para llegar a esa versión 1.0 que es más bien simbólica en este ámbito del software.

Curiosidades del mundo de las versiones

Fuera del mundo Linux usamos las versiones de una forma distinta, como una declaración de estar a la última. Es más un elemento de marketing (informativo, eso sí) que otra cosa. Tener Android 9.0 o iOS 12 en el móvil teléfono y Windows 10 o macOS 10.14 Mojave en el PC o portátil es "buena" señal, porque esas versiones cuentan con las últimas mejoras y parches de seguridad.

Lo mismo ocurre con desarrollos abiertos o comerciales para todas esas plataformas. Hay algunos en las que la numeración es más evidente y ni siquiera es un número de versión sino un año (FIFA 19, Office 2019) y otras en las que aunque la numeración está ahí, no solemos verla o prestar atención (WhatsApp, Facebook, Chrome, Firefox).

De hecho hay toda una ciencia alrededor del diseño de versiones de software -el versionado semántico trata de resolver el problema-, algo casi determina la forma en la que conocemos al software con el que trabajamos.

En general usamos numeración incremental: cuanto mayor es el número, más moderna es la versión, pero a partir de ahí hay distintos criterios o esquemas para numerar ([mayor.menor.compilación.revisión] es uno de los más extendidos) y para identificar distintas etapas del desarrollo (alpha, beta, RC, final).

En (el kernel) Linux, por ejemplo, los números de versión han tenido su propia historia, y entre las versiones 1.0 y las 2.6.x se usaron números impares para identificar ramas de desarrollo (Linux 2.3 era la rama de desarrollo que desembocaba en Linux 2.4) y los pares para las ramas estables.

Pero es que además las versiones tienen su propia subcultura y sus supersticiones con números "prohibidos". Mientras que Office 2007 tiene como número de versión interno la 12, la siguiente versión, Office 2010, tiene como número de versión interno el 14: el 13 da mala suerte, dicen. Y lo mismo ha ocurrido a menudo entre fabricantes chinos que evitan el número 4, como OnePlus, a la que vimos saltar del modelo 3T de su smartphone al OnePlus 5.

Microsoft también saltó números con Windows y pasó de Windows 8 (y 8.1) a Windows 10 directamente, y Apple ha hecho lo propio con sus iPhone, que fueron del iPhone 8/Plus a los iPhone X. Aquí hubo más un tema de marketing que el temor a la mala suerte que pudiera dar el número nueve. Un número que, por cierto, en Japón tratan de evitar.

En el Open Source las versiones 0.x son estupendas

Lo que es raro ver en el mundo "no-Linux" es el uso de versiones 0.x, que en otros ámbitos parecen reservadas a versiones preliminares de programas y aplicaciones inacabados.

En Linux eso no es ningún problema, y de hecho hay desarrollos famosos por haber pasado años en esa rama de numeración sin dar el salto a esa gran versión 1.0 (o 1.0.0, o 1.0.0.0) estable y final que parece plantear que al fin aquello es "usable".

Lo gracioso de todo esto es que en el mundo Open Source y del software libre ese número no tiene (necesariamente) relación con lo estable que es un desarrollo, y hay muchos ejemplos en los que esas versiones 0.x eran (y son) perfectamente válidas. Entre ellos:

• Wine: el conocido sistema de ejecución de aplicaciones Windows en sistemas Linux llevaba en desarrollo quince años cuando llegó a su versión 1.0. Las versiones 0.x fueron por tanto ampliamente utilizadas en este desarrollo que llegó a esa versión tan redonda en julio de 2008.
• MenuetOS: este sistema operativo desarrollado en lenguaje ensamblador llevaba también 15 años en desarrollo y usando esas versiones 0.x cuando sus creadores decidieron en 2015 que por fin habían considerado su plataforma digna de llegar a la versión 1.0.
• Htop: la conocida utilidad de monitorización de recursos (la versión "gráfica" en modo terminal de la archiconocida 'top') también tardó en llegar a la versión 1.0: lo hizo después de ocho años de desarrollo.
• Ffmpeg: otro de los desarrollos ilustres del mundo Open Source, y que estuvo 12 años usando versiones 0.x antes de dar el salto a su primera versión redonda. HandBrake: este conversor de formatos de vídeo también se tomó su tiempo para llegar a la versión 1.0: lo hizo tras 13 años de versiones "beta".
• Calibre: otra aplicación veterana y disponible en diversas plataformas a la hora de gestionar y convertir formatos de e-book. Calibre tardó siete años en ofrecer su versión 1.0.

Pero para casos especiales, el del emulador MAME, cuyos programadores ya dejaron hace tiempo que nunca anunciarán la versión 1.0 de esta plataforma porque siempre habrá nuevos juegos que emular y por tanto el servicio nunca podrá estar completo del todo. A la versión 0.99, por ejemplo, le siguió la 0.100, y la última versión disponible es MAME 0.207.

Hay otros desarrollos Open Source que se eternizan en ramas de versiones "intermedias" que podrían crecer si quisieran, claro. Es el ejemplo de GIMP, ese rival eterno de Photoshop que tardó 3 años en alcanzar la versión 1.0 (1998), y otros 6 años en llegar a la versión 2.0 (2004). Desde entonces le ha pasado un poco lo que a Linux con su rama 2.0, que se "subdividió" en la 2.2 (2004), la 2.4 (2007), la 2.6 (2008), la 2.8 (2012) y la 2.10 actual (2018).

¿Por qué no usar números más redondes y grandes? Pues por la sencilla razón de que en Linux, el Open Source y el Software Libre tienen de todo menos versionitis.