OpenGL y reescribir cosas

El anterior post sobre el declive de OpenGL ha recibido una sorprendente atencion, aunque lo que no ha sido en absoluto sorprendente es la reaccion de aqui: Mientras muchos americanos se han tirado de los pelos y ha clamado lo vergonzoso que es que OpenGL se deje pisar el terreno por DirectX en vez de aspirar a lo inverso, a pisarles ellos, aunque solo sea por el simple placer de ser mejor, la reaccion española es mucho mas proclive a enmascarar los problemas enumerando las ventajas que le quedan, como si esas ventajas fueran una garantia indiscutible de futuro, o una razon para cruzarse de brazos. No pretendo con esto ridiculizar a quienes enmascaran los problemas -yo tambien soy español-, pero si que es algo que siempre me llama la atencion cuando uno compara los foros españoles con los de otros paises.

Volviendo a OpenGL, esta historia no es nueva. La gente encargada de mantener OpenGL ha tenido que enfrentarse a una pregunta que muchos otros proyectos de software (bueno, o de especificaciones de APIs) se han hecho: "Tenemos que añadir X funcionalidad al proyecto, y X no encaja muy bien en el diseño actual de nuestro software. ¿Que hacemos? ¿Implementamos X encima del diseño actual, workaroundeando con delicadeza o pura fuerza bruta los escollos que el diseño actual nos impone? ¿O reescribimos sustancialmente parte del software para mejorarlo de manera que X y otras posibles funcionalidades puedan implementarse de manera mas sencilla?"

Practicamente todos los programas del mundo se han enfrentado o se enfrentaran alguna vez a esta pregunta: Se trata simplemente de decidir si se debe romper la compatibilidad para mejorar el programa, o no romperla para no fastidiar a los usuarios y seguir evolucionando el codigo sobre el diseño actual. Cuando se trata de pequeños programas no se trata de un gran problema, pero cuando se trata de grandes proyectos se trata de decisiones importantisimas no existe una regla fija para responder la pregunta: cualquiera de las opciones lo mismo puede catapultar el programa al exito absoluto como hundir un buen programa en los abismos del olvido.

Microsoft, por ejemplo, ha basado gran parte de su exitoso monopolio en la compatibilidad. En Vista han recurrido a romperla en algunos puntos para conseguir evolucionar el sistema, y no les ha ido tan mal. Mac OS X necesito ser creado de cero para poder ser lo que es hoy. Unix debe gran parte de su exito en la estabilidad del estandar POSIX, a pesar de que el diseño de Unix es mejorable, como sus propios creadores han admitido. Netscape cometio un error imperdonable cuando dejo de evolucionar sus versiones 4.x para centrarse en una base de codigo reescrita de cero que no estuvo preparada hasta que Netscape estaba ya muerto. Y, sin embargo, tuvo que recurrirse a reescribir la interfaz del navegador para que surgiera el exitoso Firefox. IE decidio conservar la compatibilidad y detener las mejoras, y eso les ayudo a alcanzar mas del 90% del mercado, y ahora la ausencia de mejoras durante años es lo que esta contribuyendo al descenso de su uso. KDE 4.0 ha sido un fracaso rotundo, y sin embargo parece haber sido un paso necesario para que KDE 4.1 y posteriores versiones se perfilen como un escritorio muy competitivo. Del mismo modo, Linux 2.6.0 era un kernel altamente competitivo pero necesito un año para convertirse en algo que las distribuciones pudieran usar con confianza. Gnome anda en estos momentos discutiendo, esencialmente, si continuan su evolucion conservando la compatibilidad o no. Eclipse decidio recientemente que van a reescribir el proyecto por completo y aun no se sabe si sera un exito o una mala idea. Office debe gran parte de su exito a la compatibilidad. Netware idem, y aunque Novell se ha subido al carro de Linux, Netware sigue siendo la principal fuente de sus ingresos. Cobol es un lenguaje pateticamente anticuado, y sin embargo sigue siendo el pilar de software bancario muy exitoso.

Y OpenGL3...¿que?

Es evidente, aun para quienes no tenemos mucha idea de graficos, que OpenGL 3 se enfrentaba al tipico caso de renovarse para estar al dia, o conservar la compatibilidad para agradar a los usuarios existentes y extender el diseño actual como recurso contra la obsolescencia. La ruta tomada por quienes mantienen OpenGL ha sido claramente esta ultima. ¿Va a morir OpenGL? Bien, desde luego no va a desaparecer de la faz de la tierra, por ser la unica opcion de Linux y Apple y por complacer con compatibilidad a los programas basados en OpenGL que, obviamente, no van a dejar de usarlo. Pero si persiste en su empeño de no quitarse el polvo, podria correr a muy largo plazo el mismo riesgo que Netware: Un SO que no esta, ni muchisimo menos, muerto, y sin embargo no importa a nadie. OpenGL corre el riesgo de acabar siendo utilizado unicamente porque quien lo usa tiene la necesidad inexcusable de hacerlo, no porque nadie se sienta atraido por sus capacidades: Un lastre que algunos se ven forzados a utilizar a la hora de, por ejemplo, portar un juego a Mac, pero desde luego no algo que utilizarian si pueden evitar hacerlo.

(Alguien comentaba en mi anterior post que a un buen programador le da igual la API por mala que sea siempre que funcione y que por tanto un buen programador no tiene dificultades a la hora de usar OpenGL. Oh, si, un buen programador puede hacer eso. Y un buen programador puede escribir cualquier cosa en C. El problema es que la gran mayoria de programadores no son buenos, ni lo van a ser nunca, ni las empresas van a dejar de contratarlos)

En general, yo creo conservar la compatibilidad tiene sentido cuando el software de turno tiene virtudes. Cuando el software empieza a desfasarse, conservar la compatibilidad solo significa conservar la compatibilidad con algo obsoleto, y es a largo plazo una sentencia de muerte lenta, pero segura. Hay ocasiones en las que mediante emulacion uno puede diseñar programas nuevos que conserven la compatibilidad con los viejos programas, y entonces uno puede combinar las dos cosas. Ejemplo notable es el de Windows, que conservo la compatibilidad con DOS en Windows 9x, y conservo la de ambos en el paso a NT que supuso XP. Si se hubiera quedado en DOS o en W9x, Microsoft hubiera muerto, pero supo hacer converger evolucion y compatibilidad de manera totalmente brillante. No parece que OpenGL haya escogido ese camino: La opcion escogida de marcar ciertas APIs como "deprecated", por ejemplo, obliga a los fabricantes de hardware a hacer implementaciones de OpenGL que soporten esas APIs como "deprecated" Y ademas tienen que implementar las nuevas, todo en el mismo driver. Genial. Por lo visto, la calidad de los drivers de OpenGL es uno de sus grandes problemas debido a la dificultad que suponen, y el prometido 3.0 iba a ser una gran mejora en ese punto, pero con lo que han sacado solo ha logrado empeorar la situacion: Para implementar OpenGL 3.0, las compañias utilizaran su antigua implementacion OpenGL 2.x y la extenderan, creando fallos en partes que en 2.x no los habia.

La mencion de antes de Netware no es casual. Netware acabo en el olvido en gran medida porque Microsoft quiso acabar con Netware, y lo consiguio. Mucha gente habla de que si OpenGL tiene sus nichos, que si etc....¿saben lo que quiere Microsoft? Acabar con OpenGL. Ya lo ha conseguido en buena medida: Su plataforma windows esta, para millones y millones de sus usuarios, libre de programas que utilizen OpenGL. Gracias a que OpenGL no parece querer cambiar la situacion y atraer, por ejemplo, a los desarrolladores de juegos, no tienen por que preocuparse porque nadie desafia sus puestos de defensa. Sin embargo, Microsoft si que va a atacar a las defensas de OpenGL. Sean cuales sean los nichos en los que aun fuerte, Microsoft va a tratar de acabar con ellos, y si bien no va a erradicar OpenGL de la faz de la tierra, si que puede hacerlo completamente irrelevante en el mundo de la programacion grafica.

Denles tiempo, y veran lo que pasa con el mundo CAD u otros. La de OpenGL al dia de hoy es una estrategia de mucha defensa y cero ataque, mientras que la de Microsoft es tanto de defensa como de ataque, y cuenta con muchas mas tropas. Si no se les planta batalla, el desenlace ya esta escrito.