Liberar una nueva versión de Ubuntu cada mes. Eso es lo que propone Scott Remnant, miembro del consejo directivo de Ubuntu, en su blog personal: adaptar los ciclos de publicación de Ubuntu para que cada mes haya una nueva versión. De momento no es más que eso, una propuesta, pero ¿parece buena o mala idea?
Afirma que ahora mismo Ubuntu tiene un problema: la obsesión con añadir una determinada función en una determinada nueva versión. Así, cuando llegue la fecha (pongamos, 12.04) se eliminará el software que funciona y se sustituirá por la nueva versión con la nueva función, aunque ésta no funcione completamente. Es verdad que en ocasiones Canonical ha pecado de forzar este tipo de cosas. Pero adaptar los ciclos mensuales, si no se cambia lo demás, no sólo no sirve de nada, sino que puede originar nuevos problemas.
Y ello porque nada hace pensar que mover el sistema a ciclos mensuales vaya a solucionar algo, más bien promete no solucionar nada en absoluto; la solución no es tan obvia. Eso sí, habrá una nueva versión cada mes. ¿Ubuntu quiere ser Firefox? Creo que es un error aplicar al software de escritorio, bajo control del usuario, la lógica del software web privativo, que no está bajo control del usuario. Lo es con un navegador, y lo es tanto más con un sistema operativo que puede ser usado, potencialmente, en servidores y puestos de trabajo que requieren, ante todo, estabilidad y fiabilidad.
Obligarse a tener un sistema nuevo cada mes, con la necesidad de incluir novedades (hasta ahora era fácil, porque los ciclos de Ubuntu se sincronizan con los de Gnome), es la receta para las urgencias, las prisas y el software a medio terminar. Demasiados sustos para una gran parte de tus usuarios, que buscan exactamente lo contrario.
Las releases están obsoletas. La mayoría de la gente ya no instala cada nueva Ubuntu desde cero, sino que va actualizando los paquetes de manera paulatina. De hecho, «aguantar» cambios en paquetes para que formen parte de la próxima release, y luego hacer una actualización «avalancha» (actualizar a la nueva Ubuntu) suele ser un camino arriesgado. Es por eso por lo que ocurren los sustos, no porque haya nuevas versiones del software.
En ese escenario, es mejor un sistema de rolling release (http://en.wikipedia.org/wiki/Rolling_release), que hace que los paquetes estén disponibles con nuevas versiones de manera continua, sacando CDs cada poco tiempo para aquellos que quieran instalar el sistema desde cero, o incluso con CDs «minimal» y que se bajen los paquetes correspondientes al instalar.
Pasar de seis meses a un mes siguiendo con las estrategias de actualizaciones abruptas y discontinuas no servirá de mucho. Pasar de seis meses a rolling release, con actualizaciones continuas y suaves, quizás sí sea una buena idea (aderezado con un mecanismo fácil de rollback). Ya hay distribuciones que funcionan así (http://en.wikipedia.org/wiki/Arch_Linux).
Sip, pasar a métodos más ágiles parece buena idea, se llevará el problema de las actualizaciones discontinuas, que es lo que yo creo que no conduce a ningún lado. Por otra parte, con el software que instalamos nosotros estamos más cómodo si conocemos y «controlamos» bien la versión en la que estamos… Es lo que nos permite quedarnos en la versión que nos funciona bien. Si me despliegan sin avisar el x.org más reciente porque la actualización es en continuo, me dejan sin entorno gráfico porque el más reciente es incompatible con mi tarjeta gráfica, por ejemplo.
Creo que son metodologías con las que estamos más cómodos en entornos web, pero igual soy yo (de hecho, es muy posible que sea yo). :D
Saludos!
Esto es ir a contrapié. Hoy en día todas las organizaciones están evitando costes que no aporten valor, y me vas a decir qué valor tiene una versión nueva del sistema operativo cada mes, solo porque incorporará funcionalidad de la que muy probablemente el usuario no sabe su existencia ni para qué la iba a utilizar. Actualizar es coste (aunque sea mediante un procedimiento automático… a veces actualizando las cosas se rompen y si tienes que ponerte a arreglar algo pues es costoso y fastidia). El desarrollo ágil es muy bonito y es ideal para plataformas centralizadas (hoy en día esto significa el lado servidor del SaaS) pero para algo que requiera un esfuerzo descentralizado de deployment… uffff.
Plas, plas, plas. Me gustó tu perspectiva. Llevo unos días espesito y no traduje el inmovilismo corporativo habitual a costes… eso lo habría hecho todo más sencillo ;)
No es que nos tengamos que adaptar a un software cambiante. Es que el software se adapta a un mundo cambiante. No sé si aporta valor o no, pero aferrarse a una versión de software obsoleta sí que hará perder valor antes o después.
El ejemplo más típico de pérdida de valor por usar software sin actualizar es en seguridad. Un fallo existente y conocido es un problema potencial de seguridad en el software (y no solo en el servidor, todos hemos sufrido Internet Explorer). Aún así, es cierto que una versión nueva puede introducir problemas nuevos. Por eso es necesario poder volver atrás fácilmente, al igual que necesitamos mecanismos de actualización sencillos (tipo rolling release, y no actualizaciones «abruptas» à-la Ubuntu).
«Software que no cambia y no hay que/queremos actualizar» es un oxímoron.