Sigo con aspectos que me interesaron de la última charla de Miguel de Icaza en Barcelona:

Miguel estuvo charlando largo y tendido sobre las aplicaciones que en la actualidad estaban usando MONO para sus desarrollos. De hecho, para Icaza, estamos en un punto en el que lo interesante ya no es MONO en sí, sino los proyectos que están en su órbita.

Personalmente me sorprendió, y Miguel también admitió su sorpresa, es que uno de los principales mercados en estos momentos radica en el mundo de los videojuegos. Nos mostró un potente entorno 3D para el desarrollo de videojuegos llamado Unity, que a parte de tener muy buena pinta, nos brindó la oportunidad de ver que tal anda Miguel de puntería…

Aunque, ya para asombro brutal,  fue el anuncio de la migración de todos los scripts de Second Life, a los que “algunos” les sonará… a MONO. ¿El por qué? Mitad de recursos de memoria, 150% más de rendimiento. Impresionante! Me dejó perplejo ver que MONO ha calado hasta la médula en un proyecto de tal envergadura; que estamos hablando de una granja de aproximadamente 6000 servidores!

Por lo demás, estuvo enseñando varias aplicaciones como iFolder o F-Spot. La primera vendría a ser el Groove libre, trabaja dónde quieras con tus archivos siempre en línea, y la segunda es un gestor de bibliotecas de imágenes de lo más potente. Vale la pena que les deis un vistazo.

La filosofía que quiere emplear Miguel de Icaza en el desarrollo por parte de Novell de aplicaciones con MONO, es la de crear proyectos de un máximo de dos meses, con un programador / crack a su cargo. Productividad al máximo, resultados atractivos.

Si quereis tener una visión más completa de la “oferta” MONO visitar:

http://www.mono-project.com/Companies_Using_Mono#Who_uses_Mono.3F

El otro ámbito estrella es Gnome, ya que en la actualidad todos los desarrollos se para éste entorno de escritorio se están realizando en MONO, inclusive el espectacular XGL.

Y yo que creía que suficiente tenían con poder compilar…

Desde los inicios de Windows Presentation Foundation, de cuando se le conocía con el nombre de Avalon, se encontró envuelto en un amasijo de opiniones que trataban de ubicarlo dentro del panorama actual que Microsoft ofrece, en otros posts anteriores he comentado el “qué” y el “por qué”, ahora le llega el turno al “dónde”, ya que las visiones de cómo encaja WPF han sido complejas al menos hasta hace muy poco. Pero vamos al tema.

Descubriendo las intimidades de Longhorn
Avalon (WPF) fue presentado como una de las principales novedades del nuevo sistema operativo de Microsoft, el Windows Vista (anteriormente conocido como Longhorn). Se trataba de un subsistema de Longhorn dedicado a la gestión de gráficos 2D/3D. En esas fechas, la visión de una tecnología que fusionara las herramientas de creación de interfaces de usuario era difusa.

El enfoque que se estaba dando a Vista a nivel de desarrollo, y que en la actualidad perdura (aunque lamentablemente de una forma más difuminada), no era otro que poder gestionar las entrañas del sistema operativo mediante código administrado y una exhaustiva jerarquía de objetos, que incluirían además de WPF a Windows Communication Foundation (anteriormente conocido como Indigo) y Windows Workflow Foundation entre otros (algunos como WinFs quedaron poro el camino). Las especificaciones de éste conjunto de subsistemas Windows requerían del .NET Framework 2.0 para ser utilizadas.

Llegados a éste punto las cosas más o menos cuadraban; Windows Vista admitirá una interfaz de componentes para ser gestionados desde el .NET Framework 2.0 que vendrán a suplantar las “maravillosas” llamadas al antiguo Win32.

WinFX se populariza
Mientras la pelota estaba en el terreno de Windows Vista el tema estaba ubicado en ese oscuro mundo de los Betas Testers, pero Microsoft estaba dispuesto a hacer llegar al máximo conjunto de gente sus “nuevas maravillas”, con lo que decide enmarcarlas todas en un paquete al que llama WinFX, y permite instalarlo en los tan populares Windows XP.
 
Fue aquí dónde nació la sombra de la duda. El programador de a pie empieza a plantearse lo que realmente es WinFX, y empiezan a coexistir dos corrientes de opinión a cual con más adeptos.

WinFX como ampliación del Sistema Operativo
Al instalar WinFX ampliamos las posibilidades que nos brinda el sistema operativo, para más tarde aprovecharlas desde el .NET Framework 2.0.

WinFX no es más que un Framework
WinFX es visto como un Framework que nos permite trabajar con el sistema operativo de forma mucho más cómoda. El nuevo Framework se gestionará mediante otro paralelo diseñado con propósitos más generalistas, el .NET Framework 2.0.

Framework sobre Framework = Nuevo Framework

La solución al conflicto se reveló el pasamos mes de Junio por parte de Microsoft, alineándose con la corriente de opinión que veía a WinFX como un Framework independiente, pero intentando por todos los medios posibles procurar no dejar del todo contento a nadie. Intentaré explicarme:

Dado que WinFX es admitido como Framework, la comunidad de desarrolladores empezaba a hacerse preguntas del tipo:

• ¿WinFX sustituirá al .NET Framework?
• ¿Qué Framework manda sobre el otro?

Y Microsoft responde con: WinFX + .NET Framework 2.0 = .NET Framework 3.0, es decir, las suma de Frameworks dan como resultado un nuevo y único Framework.

¿Qué es lo que no gusta? Pues el cambio de chip no ha sido del todo bien acogido por algunos. Pasamos de un .NET Framework dependiente de Windows, pero no orientado al mismo, a uno nuevo que se fusiona seriamente con el sistema operativo, poniendo en serio compromiso proyectos como Mono. (Ya hablaré de WPF y Mono, en breve…)

¿Marketing o coherencia?
En todo caso: ¡Bienvenidos al .NET Framework 3.0!

A diferencia de la primera charla que realizó Miguel en Barcelona, en la que sólo se tocó el tema un poco por encima, en ésta ocasión, las patentes de software y los posibles litigios en los que se podría ver envuelto el proyecto MONO centraron buena parte de la charla.

NOTA: Me gustaría recalcar lo absolutamente ignorante que soy en la materia, aunque creí entender algunos conceptos que realmente me sorprendieron.

En sí MONO, conceptualmente, no es un proyecto fuera de la ley. Pese a lo que mucha gente cree .NET no es un estándar cerrado y propietario de Microsoft, sino que se basa en unas especificaciones públicas en ECMA, en las que han participado mucha gente aparte de Microsoft, como IBM o HP entre otros.

¿Vaya chollo, no? Entonces es algo así como si habláramos de editores de HTML, dónde se parte de un “estándar” y cada uno lo implementa como le plazca. ¡Esto es genial! O al menos en apariencia. (Supongo que se pilla la ironía del ejemplo,, ¿no? Je je) Las patentes de software han llegado a un extremo tan voraz que resulta casi imposible implementar ciertas especificaciones sin toparse con alguna patente de software, y eso sí, me resultó francamente sorprendente.

Según Icaza, la política que se sigue en estos casos es la siguiente:

1.  Buscar un antecedente del uso del sujeto patentado, de forma que anule la aplicación de la patente, o dicho de otro modo, demostrar que alguien se ha marcado un tanto que no se merecía.
2.  Intentar buscar la trampa algorítmica que pueda hacer colar el tema, práctica usada en MONO.
3. 3. Pasarse por el forro la patente. Práctica “estrella” en MONO.

La argumentación que dio a la hora de infringir patentes en un proyecto de Software Libre no dejó de sorprenderme, a la vez que, analizándolo un poco en frío, la encontrara un poco contradictoria. El concepto se basa en la teoría de que cuando eres tan insignificante, nadie te da tanta importancia como para meterse contigo; ¿total que van a sacar de ti? Un ejemplo de ello es YouTube; Mientras fueron una empresa pequeña se pasaron por el forro todo los derechos de autor habidos y por haber, lo compra Google, que si algo tiene es pasta, y venga acuerdos a base de talonario… Hasta aquí de acuerdo, pero… ¿eso no es hipotecar el futuro de MONO? Es decir, o me mantengo pequeño, muero de éxito o acabo absorvido.

Llegados a éste punto se le abordó el asunto ya tan comentado del acuerdo Novell / Microsoft en cuanto a patentes, y de nuevo volvió a sorprenderme. MONO no es propiedad de Novell, dado que como proyecto pertenece a la comunidad. El papel de Novell es ser el principal mecenas del proyecto, pagando en la actualidad los salarios de 20 programadores del núcleo central de desarrolladores de MONO, que en la actualidad rondan los 200. Al no pertenecer a Novell, el acuerdo con Microsoft queda al margen, aunque sí admitió que puede ser visto como una declaración de intenciones…

Aunque para sorpresa, lo que se dice sorpresa, fue cuando me enteré de lo poco que sabía del tema de patentes:

Alguien preguntó: “¿MONO no acabará desarrollándose en Europa dado que aquí no tenemos patentes de Software?”

Yo listo de mí, pensé; bueno pero sólo podrías comercializarlo en Europa, ¿no? Es por eso. Tranquilo Miguel, ya contesto yo… Pues venga bomba, la discusión de las famosas patentes de software en Europa es un simple trámite para facilitarles las cosas a las empresas, ya que en la actualidad ya existen, pero simplemente con otro nombre, patentes de máquina. De hecho, en EEUU cuando registras una patente de software, existe el servicio que pagando “x” dólares más, te convierte la patente a la “jerga” europea… lo cual me dejó estupefacto.

Una vez más, pude comprobar lo mucho que me falta por aprender…

En un mundo como el del software libre, es vital la unificación de esfuerzos, y es por ello que el planteamiento que incorporan las especificaciones .NET en cuanto al concepto multilenguaje son consideradas vitales. Partiendo de esa base, podemos unificar y/o reutilizar el trabajo que realicen diferentes programadores independientemente del lenguaje de programación que hayan usado, y eso es algo que no está nada mal.

Sólo por el multilenguaje la opción .NET era realmente atractiva (y más cuando Icaza había fracasado con el proyecto “Bonobo” en su intento de conseguir algo parecido mediante CORBA), pero según Icaza hubieron otros factores de decisión importantes.

El gran candidato a proporcionar un lenguaje de alto nivel al programador de Linux era sin duda Java. El problema de Java era básicamente, y aquí fui yo el primer sorprendido, su poca unión. ¿Falta de unión? Pues parece ser que sí. El programador convencional tiende a asociar Java con Software Libre, algo que hasta la fecha no es así (o quizás a partir de hoy, sí, las noticias vuelan!), dado que Sun mantiene licencias que excluyen a Java de éste mundo. Es cierto, es gratuito, pero tiene un propietario y no es libre. ¿Entonces, Java no es libre? Java de Sun (al menos en aquellos entonces), no, pero existían otras alternativas y proyectos en el mundo Java, que según Icaza padecían de una grabe falta de cohesión, no consiguiendo unificar esfuerzos en un camino concreto.

Éste punto Miguel de Icaza suele ejemplarizarlo con un fragmento de la película “La vida de Brian”, el cual me parece muy acertado, y aplicable a muchos otros ámbitos de la vida:

Pese a todo, Miguel de nuevo se mojó, y sin tapujos apostó por la plataforma .NET a la hora de valorarla tecnológicamente, y volviéndola a definirla como la suma de Java + todo lo que los usuarios de Java pidieron a Sun (y Sun sudó de ellos) + un porrazo de millones de dólares. También me llamó la atención afirmaciones del estilo (cita no textual): “Java es demasiado lento”, algo que suscribo, pero que en general, no se suele percibir así.

También era interesante sumar al carro un porrazo de programadores que arrastran las plataformas de desarrollo de Microsoft, que sin muchos esfuerzos podrían saltar a Linux y unirse a la causa. A eso, le sumamos material docente, entornos de desarrollo, divulgación, etc. que Microsoft brinda a .NET, y en definitiva a MONO, y la opción .NET seguía sumando enteros.

Pese a todo hay que volvernos a contextualizar en el tiempo, en el año en que discutíamos si todavía estábamos en el siglo XX o en el XXI, todavía no se habían iniciado movimientos como los que Sun está realizando, o viéndose obligado a realizar, con lo que es posible que los planes de Icaza no hubieran sido exactamente los mismos, no sé, en todo caso, en cuando tenga arreglado el condensador de Fluzo de mi DeLorean quizá escriba algo al respecto.

Pese a todo, MONO siguiendo su filosofía de unificar lenguajes-esfuerzos, no ha dejado fuera a Java, lo cual hubiera sido una contradicción, haciendo posible que programadores como yo a los que nos gusta programar con Visual Basic (cristianos mariquitas según Miguel), podamos heredar de clases picadas en Java, dentro del “paraguas” de MONO.

 Impresionante, ¿no?

En el momento en que Linux consiguió hacerse con gran parte del pastel del mundo de los servidores, un grupo de gente quiso ir más allá, e intentar que Linux fuera un agente importante en la batalla del escritorio.

Para llevar a cabo dicho propósito era necesario generar un compendio de aplicaciones y utilidades que facilitaran el uso de Linux a usuarios con nivel cada vez menos especializado. ¿Pero, que herramientas de Software Libre disponían éste grupo de aventureros / programadores en aquellos entonces? Pues simplemente C++, lo que comportaba programar a muy bajo nivel, con unos costos de desarrollo tiempo / recursos demasiado elevados. Es por todo ello que MONO nace como la necesidad de conseguir mayor productividad en el desarrollo de aplicaciones de escritorio (algo que con el tiempo ha ido más allá que el simple escritorio) para Linux sin dejar de usar software libre.

El pasado miércoles día 8 de noviembre tuve el inmenso placer de asistir a una conferencia sobre Mono, realizada por el gran Miguel de Icaza, al cual pude ver en acción hace ya un tiempo mediante un VideoCast de la Universitat Oberta de Catalunya (UOC), con el cual éste modesto blog inició su andadura.

Muchas de las cosas que se comentaron fueron una repetición de la presentación que ya había realizado en Barcelona, pero en general, la charla no tuvo desperdicio.

Debido a que me apetece comentar bastantes cosas del evento, voy a tratar de realizar una mini serie con lo que a mí entender fue lo más destacable de la charla.

NOTA: Todo lo que yo aquí escriba, es lo que yo he entendido, o lo que yo creía que el orador trataba de explicar, y es por ello que pido disculpas de antemano si alguien cree que caigo en deformaciones / alteraciones / omisiones de forma malintencionada. En todo caso, cualquier corrección y / o sugerencia será bien recibida.