{"id":613,"date":"2010-07-31T12:30:02","date_gmt":"2010-07-31T10:30:02","guid":{"rendered":"http:\/\/blog.rastersoft.com\/?p=613"},"modified":"2010-07-31T12:30:02","modified_gmt":"2010-07-31T10:30:02","slug":"el-verdadero-peligro-de-mono","status":"publish","type":"post","link":"https:\/\/blog.rastersoft.com\/?p=613","title":{"rendered":"El verdadero peligro de Mono"},"content":{"rendered":"

Hace unos meses, en plena discusi\u00f3n mundial sobre si el uso de Mono<\/a> en Linux supon\u00eda un riesgo<\/a> para el software libre o no<\/a>, publiqu\u00e9 una entrada ofreciendo mi punto de vista<\/a>. Sin embargo, lo que cont\u00e9 era s\u00f3lo la mitad, porque en ese momento me pareci\u00f3 que no era adecuado echar m\u00e1s le\u00f1a al fuego, as\u00ed que decid\u00ed limitarme a la parte puramente t\u00e9cnica. Ahora que ya ha pasado un tiempo y las cosas est\u00e1n m\u00e1s calmadas he decidido escribir la segunda parte. Preparaos para un articulo de opini\u00f3n, y encima largo.<\/p>\n

Lo primero, decir que Mono, estrictamente hablando (esto es, la implementaci\u00f3n libre de los est\u00e1ndares ECMA-334 y ECMA-335), no tiene por qu\u00e9 ser un problema para el software libre, gracias, principalmente, a la promesa de Microsoft de no ejercer esas patentes (vamos a pecar de confiados y, a pesar de no ser abogados, supondremos que realmente es universal, definitiva e irrevocable).<\/p>\n

Sin embargo, el primer gran problema que encontramos es que esos dos est\u00e1ndares s\u00f3lo cubren una parte de .NET, en concreto la m\u00e1quina virtual, el lenguaje C# y la biblioteca est\u00e1ndar de dicho lenguaje. Pero .NET es mucho m\u00e1s que eso, porque est\u00e1 ASP.NET<\/a>, ADO.NET<\/a> y las WinForms<\/a>, entre otros muchos componentes. Un argumento que esgrimen los defensores de Mono es que \u00e9ste no pretende ser compatible con .NET hasta el punto de poder ejecutar todas sus aplicaciones (eso es s\u00f3lo un efecto colateral), sino simplemente ser un entorno de desarrollo moderno para GNU\/Linux, que aumente la productividad. Esto se puede ver perfectamente cuando leemos el Mono Rationale<\/a> y algunas entrevistas a Miguel de Icaza<\/a>: todo el \u00e9nfasis lo ponen en el soporte de m\u00faltiples lenguajes y en la mejora del rendimiento en el desarrollo, pero no lamenta que no vaya a haber compatibilidad completa porque no hay nadie que se anime a escribir determinadas bibliotecas, sino que incluso recalca que hay muchos m\u00f3dulos espec\u00edficos de Mono<\/a> que permiten escribir programas que no funcionar\u00edan en .NET.<\/p>\n

\u00bfY qu\u00e9 problema hay, entonces, en utilizar un entorno de desarrollo basado en dichos est\u00e1ndares, y complet\u00e1ndolos con herramientas y bibliotecas libres (como GTK#, por ejemplo) para rellenar los huecos que faltan, y sin buscar compatibilidad con el .NET de Windows? Personalmente tiendo a alinearme con la gente que defiende que no hay ninguno (aunque me remito a las razones t\u00e9cnicas que esgrimo en mi anterior entrada<\/a>): por una parte el riesgo de patentes es pr\u00e1cticamente nulo, porque Microsoft se ha comprometido a no atacar con ninguna de ellas (aunque pienso que la raz\u00f3n es que, estrat\u00e9gicamente, ser\u00eda peor para ella); y por otro lado, aunque .NET avance demasiado r\u00e1pido para mantenerse a la par (cosa que ni siquiera hoy en d\u00eda se est\u00e1 consiguiendo con Mono) o si Microsoft cambiase las APIs creando problemas de compatibilidad, tampoco ser\u00eda un problema porque el objetivo no es ser compatibles con ellos.<\/p>\n

Pero…<\/strong><\/p>\n

Obviamente hay un pero, porque si no, el t\u00edtulo de este post no tendr\u00eda ning\u00fan sentido. Ese pero<\/em> surge del hecho de que la misma existencia de .NET, tan abierto, tan estandarizado, tan portable, no parece tener sentido viniendo de una empresa que ha monopolizado la web durante a\u00f1os<\/a>, que ha intentado poner trabas al software libre<\/a> mediante t\u00e1cticas cuanto menos discutibles<\/a>, y que ha sido acusada de mantener una posici\u00f3n de monopolio en el mercado de los sistemas operativos y navegadores<\/a>. \u00bfPor qu\u00e9 sacar un producto que puede beneficiar tanto a tu rival, y adem\u00e1s darle tantas facilidades, cuando tu historial habla siempre de acciones totalmente opuestas? \u00bfSe est\u00e1 regenerando Microsoft?<\/p>\n

La respuesta, en mi opini\u00f3n, est\u00e1 en Silverlight<\/a>: Microsoft perdi\u00f3 el control que ten\u00eda sobre la web y ahora quiere recuperarlo, pero la gran cantidad de navegadores disponibles hoy en d\u00eda, as\u00ed como la sensibilizaci\u00f3n que hay hacia el uso de est\u00e1ndares, le impide repetir la t\u00e1ctica de a\u00f1adir sus propias extensiones a HTML. Por otro lado est\u00e1n Java<\/a> y Adobe Flash<\/a>. El primero, a nivel web, est\u00e1 hoy de capa ca\u00edda, aunque intenta recuperar el terreno mediante JavaFX<\/a>. El segundo es un peso pesado, pero est\u00e1 perdiendo terreno gracias a HTML5<\/a> y al peso de la comunidad, que intenta incentivar el uso de est\u00e1ndares. Y es justo aqu\u00ed donde Microsoft intenta atacar con Silverlight: crea un nuevo plugin para que los desarrolladores hagan lo que hac\u00edan con Flash, pero con la ventaja de que es tecnolog\u00eda basada en .NET, lo que significa que se puede reutilizar c\u00f3digo de otras aplicaciones aunque no sean aplicaciones web (cosa imposible con HTML5); es una plataforma agn\u00f3stica respecto al sistema operativo y a la arquitectura gracias al uso de una m\u00e1quina virtual (igual que Java y Flash), y encima se basa en est\u00e1ndares abiertos (ECMA-334 y ECMA-335), lo que permite a terceros hacer implementaciones propias, como por ejemplo Moonlight<\/a>, que se basa, como no, en Mono.<\/p>\n

\u00bfY donde est\u00e1 el problema? Pues en que Silverlight no est\u00e1 dentro de ning\u00fan est\u00e1ndar<\/strong>. Como dije al principio, los dos est\u00e1ndares ECMA cubren \u00fanicamente el lenguaje C# y su biblioteca est\u00e1ndar, as\u00ed como la m\u00e1quina virtual, pero todas las bibliotecas espec\u00edficas de Silverlight est\u00e1n fuera, por lo que Microsoft tiene libertad absoluta para cambiarlas y ampliarlas a su antojo.<\/p>\n

Con esto echamos por tierra el principio de que no importa que cambie la especificaci\u00f3n porque la compatibilidad no es un objetivo: si Mono no es 100% compatible con .NET, Moonlight no lo ser\u00e1 con Silverlight y no servir\u00e1 para nada. Y si hay que garantizar la compatibilidad, el software libre siempre ir\u00e1 a remolque, y a buena distancia, de Microsoft, por lo que la gente se ver\u00e1 obligada a utilizar la m\u00e1quina de .NET, pues Mono y Moonlight no implementar\u00e1n todo lo necesario (y la especificaci\u00f3n se mantendr\u00e1 en continuo aumento). Para aquellos que piensen que exagero, me remito a los diversos clones de Flash que se han intentado hacer en el mundo del software libre: ninguno funciona lo suficientemente bien como para reemplazar sin problemas al plugin oficial de Adobe. Y que no se me interprete mal: hay un gran trabajo detr\u00e1s de todos ellos; simplemente es una tarea muy grande sobre un blanco muy m\u00f3vil.<\/p>\n

Hace tiempo ya nos topamos con el primer aviso cuando el SIGPAC se pas\u00f3 a Silverlight<\/a>: la respuesta de los creadores comenzaba diciendo que los datos ya est\u00e1n disponibles en formato WMS, que es un est\u00e1ndar para acceso a informaci\u00f3n cartogr\u00e1fica, aunque s\u00ed se puede alegar que no son los datos, sino el servicio, el que tambi\u00e9n deber\u00eda ser accesible desde cualquier sistema operativo. A continuaci\u00f3n, a\u00f1ad\u00eda que la versi\u00f3n en Silverlight es accesible desde multitud de sistemas operativos, incluido Linux, gracias a Moonlight, aunque luego aclaraba que, en este \u00faltimo caso, se conoc\u00edan algunos problemas porque el SIGPAC necesita la versi\u00f3n 3 de Silverlight, y Moonlight implementa s\u00f3lo la versi\u00f3n 2. Cinco meses despu\u00e9s s\u00f3lo hay una versi\u00f3n preliminar de la 3, todav\u00eda en fase alfa, mientras que Silverlight ya va por la versi\u00f3n 4: el software libre siempre ir\u00e1 a remolque si la especificaci\u00f3n depende de una \u00fanica empresa en lugar de ser un est\u00e1ndar oficial.<\/p>\n

Lo mismo ocurre con los mundiales de f\u00fatbol en Telecinco: para verlos necesitas Silverlight, y Moonlight todav\u00eda no sirve (aunque la versi\u00f3n alfa de la 3.0 parece que s\u00ed lo soporta, pues en la p\u00e1gina oficial dice textualmente: \u201cWith Moonlight you can watch the Olympics on Linux with our 3.0 preview\u201d). Por otro lado, vemos que tambi\u00e9n quiere integrarlo en televisores y otros dispositivos<\/a>, lo que parece indicar ya la estrategia de Microsoft: meter Silverlight en todos los \u00e1mbitos que pueda.<\/p>\n

Y si alguien a\u00fan se pregunta qu\u00e9 gana Microsoft consiguiendo que todo el mundo utilice una plataforma que se consigue gratis o de la que cualquiera puede crear una versi\u00f3n alternativa (aunque siempre vaya a remolque de la oficial), la respuesta (aparte de vender m\u00e1s herramientas de desarrollo y de que, como su versi\u00f3n ser\u00e1 siempre la m\u00e1s avanzada y s\u00f3lo la hay para windows, se asegura de que windows se utilice m\u00e1s, que ya es bastante) es que tiene el poder de forzar el uso de otras tecnolog\u00edas en las que colabora, muchas de ellas de pago. Por poner un ejemplo, Microsoft forma parte del MPEG-LA<\/a>, que cobra los royalties por el uso de H.264<\/a>, codec de v\u00eddeo que se utiliza en Silverlight para realizar streaming. Al ser Silverlight su tecnolog\u00eda, ellos deciden qu\u00e9 entra y qu\u00e9 no, pudiendo eliminar a la competencia (por ejemplo, a Theora<\/a> o a WebM<\/a>) y ganando ellos dinero con las licencias de esas tecnolog\u00edas. De hecho, la licencia de Microsoft por la que promete no perseguir implementaciones libres de Silverlight excluye expresamente el pago de royalties por codecs patentados<\/a>. Por otro lado, que actualmente sea gratis no significa que, en el futuro (cuando est\u00e9 extendido y sea casi obligatorio integrarlo si quieres vender), no haya que pagar por poner Silverlight en el \u00faltimo modelo de televisor.<\/p>\n

Y esto es lo realmente peligroso para el software libre, pues no solo iremos siempre a remolque de la implementaci\u00f3n privativa, sino que, en muchos casos, podremos vernos completamente atados (baste ver los problemas que tiene Debian o la Mozilla Foundation para incluir algunos codecs de serie en pa\u00edses con patentes de software).<\/p>\n

Por todo esto, aunque no rechacemos a Mono en s\u00ed, creo que s\u00ed deber\u00edamos rechazar con todas nuestras fuerzas a Silverlight y a Moonlight, y exigir que se utilicen \u00fanicamente est\u00e1ndares abiertos como HTML5 para realizar las p\u00e1ginas web, en lugar de sistemas privativos controlados por empresas. Precisamente ahora que tenemos las herramientas necesarias para ganar la batalla a Flash no debemos cometer el error de caer en un nuevo plugin privativo.<\/p>\n

O esa es, al menos, mi opini\u00f3n.<\/p>\n","protected":false},"excerpt":{"rendered":"

Hace unos meses, en plena discusi\u00f3n mundial sobre si el uso de Mono en Linux supon\u00eda un riesgo para el software libre o no, publiqu\u00e9 una entrada ofreciendo mi punto de vista. Sin embargo, lo que cont\u00e9 era s\u00f3lo la mitad, porque en ese momento me pareci\u00f3 que no era adecuado echar m\u00e1s le\u00f1a al … Seguir leyendo El verdadero peligro de Mono<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-613","post","type-post","status-publish","format-standard","hentry","category-sin-categoria"],"_links":{"self":[{"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=\/wp\/v2\/posts\/613","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=613"}],"version-history":[{"count":0,"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=\/wp\/v2\/posts\/613\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=613"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=613"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=613"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}