Burocracia Interna
Armonth en SigT:
Ya he comentado en alguna ocasión que para mí uno de sus principales problemas es el desarrollo burocratizado ([en Microsoft] tardaron un año en desarrollar el menú de apagado [de Microsoft Vista] por culpa de la burocracía interna) junto a tener que mantener la compatibilidad hacía atrás, en GNU/Linux a menudo se ha roto compatibilidad en las “libc” y si bien se ha montado la de dios, los programadores han adaptado sus programas y al final el cambio ha redundado en mayor eficiencia.
Me parece que este es un punto bien importante. La capacidad de romper compatibilidad le ha permitido a Linux progresar a pasos agigantados desde su incepción, y la decisión de Apple de hacer borrón y cuenta nueva al abandonar OS 9 en beneficio de OS X es una de las razones más importantes por las que Apple ha logrado convertirse en una opción popular nuevamente. El riesgo que corrió Apple fue el enfurecer a sus fieles usuarios, que fueron forzados a aprender un nuevo sistema. Los resultados están a la vista.
Y la resistencia de Microsoft a romper esa compatibilidad con sistemas antiguos no se limita a sus sistemas operativos. Muchos de los problemas con OOXML, el nuevo formato de documentos creado en Redmond, son el resultado directo de obviar la mejor solución técnica en favor de poder mantener compatibilidad con documentos antiguos.
Como consecuencia de esta decisión de privilegiar la historia en vez de la innovación, Microsoft esta forzando un formato deficiente, y la cuenta, como siempre, se le traspasa a los clientes, y peor aún, a todos los demás.
~
Sólo un apunte: es Armonth, no me cambiéis el nick a diario ;)
Jojo. Te estaba confundiendo con un elfo. Corregido..
Me parece un poco injusto o incompleta la sentencia «La capacidad de romper compatibilidad le ha permitido a Linux progresar». Si bien es cierto lo que dices, la gracias está en que eso no implica dejar de soportar y/o seguir lineas de desarrollo anteriores. Por ejemplo, el desarrollo del kernel 2.4 no se ha detenido, e incluye, por ejemplo, soporte libata para discos sata, que permite a quienes no quieren arriegarse con la «inestabilidad» del desarrollo del 2.6 seguir usando lo que conocen y mejorar un «producto» ampliamente valorado como bueno hasta niveles indiscutiblemente superiores, sin fecha de caducidad.
Esto no pasa con los productos Microsoft, y menos con el formato OOXML, que si bien tiene problemas debido a soluciones viejas, no es porque sea compatible con ellas, sino porque las reusa; OOXML NO es compatible hacia atrás, como tampoco los es el NTFS de XP con el de win2K, y varios otros ejemplos.
Creo que lo que planteas es un poco más complicado, y tiene que ver con que las decisiones de lanzamiento las toma el departamento de marketing, y no el de desarrollo o el de calidad.
Saludos a tod@s
Hola Felipe,
Estoy en desacuerdo. Aunque uno puede tener un sistema con un kernel 2.4, ningún sistema moderno (SuSE, Ubuntu, etc) «funcionaria» con uno de esos kernels a menos que uno estuviera dispuesto a sacrificar varias ventajas de los kernel 2.6. En ese sentido, Linux si ha roto la compatibilidad, y no solo con el kernel, que en este momento ni siquiera tiene una API estable, sino que otros sistemas como X11, Gnome, etc. que no le dan mucha importancia a la compatibilidad historica (lo que esta bien, en mi opinión).
Sobre lo de OOXML, no quise dar a entender que es compatible con documentos antiguos. Solo estoy diciendo que esa es parte de la motivación expresada por Microsoft, y peor aún, la raíz de mucho de los problemas que tiene como formato.
No es, por supuesto, la única razón de la existencia de OOXML, ni la principal, diría yo, pero si creo que valía la pena mencionarla.
Saludos.
Uff, sip, es un formato deficiente que nos trata de obligar a usar su sistema. Es una pena, por suerte, ahora existe un poco más de cultura (y ni siquiera a los que usan Office 2007, soportan el OOXML…
Buen blog, está en mis RSS =) (si acaso sirve para motivarte para actualizar más seguido)
Pues yo tengo Vista, y la verdad, no tiene nada de extraordinario.