Corría agosto de 1997, cuando dos jóvenes mexicanos, Miguel de Icaza y Federico Mena, decidieron crear un proyecto de interfaz gráfica que fuera totalmente libre y que fuese mucho más amigable y simple que la interfaz más usada en el mundo hasta el momento, KDE.

El proyecto, bautizado GNOME (GNU Network Object Model Environment), tuvo mucho éxito y adquirió escala mundial, siendo uno de los principales proyectos de software libre nacidos en América Latina.

En marzo de 1999 se publicó su primera versión estable, como un entorno de escritorio para sistemas Unix y sus derivados. Han pasado 11 años desde ese momento, y el proyecto ya está en su versión 2.30, con el lanzamiento de la versión 3.0 en vista para marzo de 2011.

Según el sitio del Proyecto GNOME, el grupo de desarrollo apunta a entregar un entorno de escritorio intuitivo y atractivo para los usuarios, y a fomentar el desarrollo de aplicaciones que se integren con el escritorio a través de la plataforma de desarrollo GNOME. Otras de sus metas son promover la libertad de desarrollo (manteniendo el código disponible para su uso), la accesibilidad y la internacionalización (actualmente está traducido a 161 idiomas).

La idea, en el fondo, es que el sistema sea atractivo y fácil de usar para las personas normales, lo que le ha traído más de algún problema a Icaza en el pasado con los defensores acérrimos del software libre, ya que su planteamiento a veces acepta colaboraciones con software propietario.

Pese al éxito, GNOME necesitaba recursos para mantenerse y algo de organización, para lo que en agosto del año 2000 se creó la Fundación GNOME. Esta fundación está encargada de los lanzamientos de nuevas versiones y de decidir qué proyectos pertenecen a GNOME. Cualquier desarrollador que haya hecho un aporte sustancial al desarrollo del proyecto puede formar parte de la fundación. Con esto, el desarrollo del sistema se ha vuelto un ente distribuído, como ocurre en la mayoría de los casos con los proyectos de código abierto.

¿Y qué fue de sus creadores? En octubre de 1999, Miguel de Icaza fundó Helix Code, junto a Nat Friedman. La compañía, que después pasó a llamarse Ximian, se dedicó al mantenimiento y creación de aplicaciones para GNOME. Uno de los primeros contratados en Helix Code fue Federico Mena, y hasta el día de hoy trabaja ahí. En el 2003, Novell compró Ximian, manteniendo el desarrollo de GNOME pero también encargando al grupo el desarrollo de algunos software propios de la empresa. Actualmente, de Icaza es el vicepresidente de plataforma de desarrollo de Novell.

Sin duda se trata de uno de los grandes emprendimientos latinoamericanos: la creación de un entorno para Linux, con ansias de ser global. Con la internacionalización del producto y con el aporte de desarrolladores de todo el mundo, organizados bajo el alero de la fundación GNOME, el proyecto ha logrado ser un éxito.

Link: GNOME

Para quienes a esta altura ya no lo recuerden, el asunto comienza cuando Apple decide cambiar una de las condiciones para las aplicaciones que correrán en iPhone OS 4 (y por extensión, en iPad), aumentando las restricciones respecto a qué lenguaje de programación estaba permitido.  Originalmente, el punto en cuestión decía que las aplicaciones sólo podían usar el API documentado y oficial del sistema operativo, algo bastante sensato para evitar problemas con API’s inestables que en algún momento podían desaparecer.  Pero posteriormente en iPhone OS 4 se agregó la condición de que sólo se podía programar en C, C++, Objetive-C o en Javascript soportado por WebKit, además no se permitiría ninguna capa de traducción intermedia.

Este cambio en las condiciones impuestas a las aplicaciones para iPhone OS 4 dejó totalmente fuera de la ley al resto de los lenguajes de programación, entre ellos se encuentra ActionScript y por lo tanto Adobe Flash, generando una larga cadena de declaraciones entre Apple y Adobe, terminando con Adobe llevándose la pelota a su casa.  Al mismo tiempo, los ojos de muchos desarrolladores se pusieron sobre MonoTouch, que también quedaría fuera de aquellas condiciones.

Durante el día del anuncio se intentó obtener alguna declaración de Miguel de Icaza, quien no quiso referirse directamente al tema, pero era cosa de esperar a que se aquietaran las aguas para encontrar su postura en su blog personal.

Las teorías de Miguel

Aunque Jobs ha tratado de explicar sus motivos, obviamente no dará aquellos que son parte de su estrategia corporativa, y es ahí en donde otros personajes han tratado de explorar.  Miguel de Icaza agrega dos posibles explicaciones : Una de negocio y otra de plataforma.

Respecto al negocio, la ventaja de Apple con iPhone es creó un nuevo estándar sobre lo que entendemos como teléfono móvil inteligente, desde aspectos de hardware hasta aspectos de interfaz, pasando por un componente clave del éxito: Su AppStore.

El problema es que una vez fijado ese estándar, ahora las otras compañías saben hacia donde dirigir sus esfuerzos, se sabe qué es lo mínimo requerido por un usuario de este tipo de dispositivos.  Es más, pueden evitar los defectos y/o errores de Apple y construir mejores productos si quisieran (o lograran visualizar).

Si Apple pierde el control de su plataforma, herramientas como Flash y Flex permitirían que las mismas aplicaciones disponibles para iPhone pudieran llevarse a los equipos de la competencia con bajo esfuerzo.  Eso lo haría perder su aspecto diferenciador : El ecosistema de aplicaciones.

Al forzar la tecnología usada en las aplicaciones para iPhone OS 4, éstas serán cautivas de la plataforma y no podrán beneficiar de ninguna forma a la competencia. Pretty cool huh?

El segundo aspecto explorado por Miguel es un asunto más técnico, ya que crear aplicaciones portables entre distintos sistemas hace que se vean extrañas en comparación a las aplicaciones nativas.  Otro aspecto negativo es que al tener capas de abstracción o emulación sobre el sistema nativo, cualquier cambio en éste se demorará en verse reflejado en esas capas, y así hubiera sucedido si tecnologías como Flash o Silverlight estuvieran disponibles para iPhone.

El control de Apple sobre las aplicaciones que corre su teléfono es bastante comprensible y astuto.  El usuario normal no distingue entre las capacidades del aparato, su plataforma o incluso, sus aplicaciones, por lo tanto si las aplicaciones funcionan mal, entonces el sistema completo será percibido como deficiente.  Si las aplicaciones usan tecnologías como Flash, en donde Apple no puede asegurar de que todo funcione correctamente, los usuarios finales tendrán una mala experiencia con el aparato.  Esto no es nuevo y basta ver lo que sucedió con Atari 2600 y los juegos desarrollados para esa consola, cuando el nivel de calidad de las aplicaciones cayó tan bajo que casi sepultó a los videojuegos a principio de los ’80.

En qué posición queda MonoTouch

Miguel dice que hasta el momento los que han hablado de MonoTouch no le han hecho gran favor, ya que es evidente de que desconocen cómo funciona.  En este caso no se trata de una capa de abstracción, sino que una forma de compilar directamente contra la API pública y oficial de Apple.

Es tan directa la relación entre el código ejecutable generado por MonoTouch y la plataforma nativa, que solo demoraron horas en dar soporte al iPhone cuando salió su SDK, y un poco más de tiempo para dar soporte a iPhone OS 4.

Dejando el lenguaje de lado (C#), MonoTouch es básicamente un set de bibliotecas de propósito general para facilitar el desarrollo de aplicaciones en iPhone, por ejemplo incorporando un recolector de basura y otros mecanismos para ayudar a evitar errores clásicos de la programación en C y sus derivados.  Se trata de una infraestructura de aplicaciones que cualquier desarrollador moderno esperaría.

Si bien no hay una declaración explícita de que MonoTouch cumple o no con las condiciones impuestas por Apple, Miguel da a entender que no es comparable a tecnologías como Flash ni tampoco se trata de una capa de abstracción sobre el sistema operativo nativo, sino que es simplemente otra forma de generar código ejecutable en él.

Finalmente en respuesta a uno de los comentarios, Miguel aclara que las condiciones impuestas por Apple están orientadas a las aplicaciones aceptables en su App Store y no a las aplicaciones privadas que por ejemplo podría entregar una empresa a sus propios empleados.  Independiente de lo que diga Apple, el desarrollo de MonoTouch continuará mientras haya interés en usarlo.

Estamos para servir a nuestros usuarios

Esto significa que continuaremos apoyando a MonoTouch en iPhone OS.  En parte porque las instalaciones empresariales no están sujetas a las nuevas condiciones y actualmente es un sector en donde MonoTouch se está usando.

Adicionalmente, hemos expandido nuestro trabajo para llevar MonoTouch a MacOS.  Lo estamos haciendo porque los desarrolladores quieren usar Mono en esa plataforma.  Al final del día, se trata de código abierto, por lo que si nosotros no lo apoyamos, otro lo podría hacer.

Pensamos que agregamos un valor significativo al hacerlo nosotros mismos, ya que tenemos un montón de experiencia en el área.

Dicho eso, iremos a donde los desarrolladores vayan.  Si mañana los desarrolladores necesitan Mono para lavavajillas, estaremos llevando Mono a los lavavajillas.

Como nota aparte: También estamos trabajando en Mono para Android.

Link: MonoTouch and Apple’s Section 3.3.1 : Two Theories (Miguel de Icaza)

En una primera aproximación, se enfocarán en el soporte para móviles, en forma similar al trabajo realizado con MonoTouch para llevar Mono al iPhone. Esto permitirá reutilizar al menos la misma lógica en iPhone y Android, dejando para el desarrollador la implementación independiente de los detalles específicos de cada plataforma. En palabras de Miguel:

Nuestra visión es permitir a los desarrolladores reusar el código de la lógica del negocio y el núcleo de sus aplicaciones en todas las plataformas móviles, dejando el código de interfaz de usuario como una parte específica que depende del API de la plataforma.

Es probable que MonoDroid se distribuya como un producto comercial, al igual que lo están haciendo hoy en día con MonoTouch.  Si bien es posible compilar Mono para ARM y dejarlo andando en equipos basados en Android, se espera que MonoDroid provea valor agregado de nivel similar al de MonoTouch, en donde se ha creado un poderoso conjunto de herramientas para facilitar el desarrollo de aplicaciones móviles a través de Mono.

Miguel ya adelantó en la conferencia Mix10 que una primera versión de MonoDroid se espera para Agosto.

Links:
- Mono for Android (The H-Open)
- What have we been up to? (Miguel de Icaza)

Cuando Microsoft creó CodePlex Foundation el año pasado, se formó un Directorio provisional que ahora es reemplazado por 4 miembros definitivos.  En este directorio provisional se encontraba Miguel de Icaza (Novell/GNOME/Mono) – quien provocó la ira de Richard Stallman cuando fue nombrado – y también se encontraba Sam Ramji, quien lideraba el equipo de código abierto de Microsoft, bastante respetado por la comunidad, incluso participando en diversos encuentros de código abierto.  De ellos dos, sólo se queda Sam Ramji y Miguel de Icaza deja su puesto para dar el paso a Jim Jagielski.

La inclusión de Jagielski es bastante potente, ya que tiene una trayectoria destacada en el desarrollo de código abierto orientado al mundo empresarial. Recordemos que el proyecto Apache es un gran cúmulo de proyectos de alto impacto para el desarrollo de aplicaciones y bibliotecas muy utilizadas en el mundo corporativo, incluyendo por supuesto al servidor web Apache que sigue dominando entre los grandes sitios.

Por otra parte SpringSource es la organización que está detrás del desarrollo del framework Spring, de inigualable respeto en la comunidad de desarrolladores Java, sobre todo en el área de aplicaciones empresariales en donde siempre ha mantenido una distancia con ventaja sobre la plataforma oficial Java Enterprise Edition.  Jagielski también fue CTO de Zend, la empresa que ha sido gravitante en el desarrollo de PHP.

Con Jagielski en el Directorio de CodePlex no queda duda de que la apuesta de Microsoft va en serio, y tienen con ellos a quien representa una de las mejoras combinaciones del mundo empresarial y del código abierto. En palabras de Jagielski:

CodePlex tiene una oportunidad única de seguir incrementando la importancia y la aceptación del código abierto, especialmente al interior de ambientes que hasta ahora han sido resistentes a él. A medida que CodePlex madura y evoluciona, estar en la posición de poder ayudar y guiar a la Fundación como Director, es un gran honor.

CodePlex es una confirmación de la creciente aceptación del modelo de desarrollo de código abierto en Microsoft, y el interés en la colaboración con otras empresas en la tecnología de código abierto.  La inclusión de Jagielski aumenta la credibilidad de CodePlex al tratarse de alguien que ha llevado adelante iniciativas de código abierto en el mundo empresarial, con proyectos que se han convertido en líderes de sus áreas.

Links:
- CodePlex refresh, FOSS projects more compatible with Windows (Ars Technica)
- The CodePlex Foundation Announces Appointment of Permanent Board Members (CodePlex Foundation)

Aunque existan artistas talentosos que pueden crear maravillas hasta con MS-Paint, una herramienta como GIMP es de gran ayuda para el resto de los “no-tan-talentosos”, y saber usarla puede cambiar totalmente el resultado final… Si hasta han resuelto casos policiales con conocimientos básicos de GIMP.

Algo destacable de los tutoriales publicados por Linux Format es que no tratan simplemente de enseñar cada herramienta incluida en GIMP, sino que cada artículo está enfocado en realizar un mini proyecto, como por ejemplo crear una propaganda tipo iPod, crear imágenes tipo SinCity o integrar GIMP con otras herramientas de dibujo, como Inkscape.  Esto permite entender el objetivo de las herramientas en conjunto y cómo aportan a un producto final.

Los tutoriales vienen en archivos PDF de alta resolución, y son los mismos que se usaron para imprimir en Linux Format. Debido al tamaño se distribuyen por bittorrent y hay permiso para compartirlos con todo el mundo.

Bonus Track: GIMP, GTK+ y GNOME

GIMP fue una de los primeros proyectos emblemáticos del escritorio de código abierto, y  motivó el desarrollo de GTK+ (GIMP Toolkit), el toolkit para interfaces gráficas que hoy utiliza GNOME. Antes de GTK+ los usuarios de GIMP tenían que comprar Motif, el toolkit usado en GIMP.

En forma paralela, Miguel de Icaza y Federico Mena comienzan a idear el proyecto GNOME como una alternativa libre para tener un entorno escritorio consistente en Linux. En ese tiempo contaban con el apoyo de varios amigos del código abierto, como Nat Friedman y el mismísimo Richard Stallman.

Después un frustrado intento por convencer a Trolltech para usar un esquema de licenciamiento dual para Qt, cosa que finalmente hicieron varios años después, en Agosto de 1997 toman la ruta de GTK+, en donde Federico Mena ya participaba.

Finalmente en Septiembre de 1997, GTK+ se convierte en una biblioteca independiente de GIMP y comienza el nacimiento de una nueva generación de aplicaciones.

Links:
- Free Gimp tutorial PDFs (TuxRadar)
- GIMP History (gimp.org)
- The Story of the GNOME project (Miguel de Icaza)

(cc) por James Duncan Davidson

Miguel de Icaza, co-fundador del proyecto GNOME y actualmente líder del proyecto Mono, ha sido distinguido con el premio Microsoft MVP (Microsoft Most Valuable Professional). Tal como lo dice en su twitter:

“Gracias a todos los que participaron en mi nominación a MVP, Ahora soy un C# MVP!”

El Premio MVP es un reconocimiento que entrega Microsoft a los mejores y más brillantes personajes de la comunidad técnica de todo el mundo, es decir a los profesores, artistas, doctores, ingenieros y técnicos que comparten sus elevados conocimientos, experiencias en situaciones reales y comentarios objetivos con la comunidad y con Microsoft.

Para recibir este reconocimiento, debes ser nominado por la comunidad tecnológica, MVP actuales y anteriores y gente de Microsoft. Los nominados deben someterse a un riguroso proceso de revisión por parte de un jurado compuesto por miembros del equipo MVP y Microsoft, los cuales evalúan la experiencia técnica de cada nominado y sus contribuciones voluntarias a las comunidades durante el año anterior.

Uno que no debe estar muy contento con todo esto es Richard Stallman, que recordemos, no ha visto con buenos ojos al proyecto Mono ni tampoco que Miguel sea parte de la CodePlex Foundation, la organización de Microsoft para promover el código abierto.

Link: MVP Award (Tirania.org)

(cc) por Beto García

Lejos quedaron los días en que un par de jóvenes amigos y entusiastas del código abierto decidieron crear una empresa alrededor del escritorio GNOME. Uno de ellos era Miguel de Icaza, co-fundador de GNOME y el otro, un inquieto chico norteamericano llamado Nat Friedman.

La empresa inicialmente se llamó Helix Code, y posteriormente fue renombrada como Ximian, agregando un nuevo registro a la familia de proyectos de Miguel con nombres relacionados con los monos. Poco a poco se convirtieron en una empresa reconocida internacionalmente, mejorando agresivamente el escritorio GNOME y en general el escritorio de Linux con su producto estrella Ximian GNOME.

En el año 2003, Novell decide hacer un giro drástico en su negocio para renacer como una empresa basada en Linux, y su primer paso fue acercarse a los líderes del escritorio: Ximian, la empresa de Miguel y Nat.  Según cuentan ellos mismos, a pesar de ir en bajada, Novell tenía suficientes fondos como para llevar a Ximian y GNOME a donde ellos querían sin tener que preocuparse de seguir buscando inversionistas, y por otra parte ambos serían responsables de contagiar al resto de Novell con las ideas del código abierto.

Al poco tiempo, Novell adquiere a otro grande de la industria, la alemana SuSE, dando paso a SUSE Enterprise Desktop y posteriormente a OpenSUSE, pero a pesar del peso técnico del equipo detrás de SuSE, Miguel de Icaza se mantuvo como Vicepresidente de Tecnología de Productos de Novell y Nat Friedman como CTSO (Chief Tecnology and Strategy Officer).

Pero como todo tiene su fin, Nat anunció este viernes 8 que, estando recién casado y ahora que su proyecto final está al aire, nada más y nada menos que SUSE Studio, es hora de dar un giro a su vida y dejar las filas de Novell.

En su blog, Nat cuenta que trabaja desde los 15 años con computadores, y viajar por el mundo siempre fue su sueño.  Entre sus pares, Nat es conocido por ser muy inquieto y ya parecía extraño que llevara tanto tiempo sin buscar nuevos rumbos.

Por lo que se puede ver, Nat no tiene ninguna urgencia en buscar otro trabajo, y sólo tiene en su mente las montañas (ski), hacer trabajos voluntarios y por qué no, meter mano en algunos proyectos sólo por diversión, como en los viejos tiempos.

Link: Hitting the road (blog de Nat)

Para quienes no la conozcan, Silverlight es un framework RIA (Rich Internet Application) desarrollado por Microsoft, que en base al runtime de .NET (Mono en el caso de Linux) y otras tecnologías estándares como XML y JavaScript, nos permite crear aplicaciones tanto para la web como para el escritorio.

Moonlight 2 está basado en Mono 2.6, Cairo y GTK+, y soporta todas las funcionalidad de Silverlight 2, pero además incluye varias características de Silverlight 3 como la posibilidad de que los desarrolladores puedan incluir sus propios codecs.

Miguel también comenta que Microsoft y Novell han actualizado su acuerdo de colaboración para continuar la implementación de código abierto para las versiones Silverlight 3 y 4. Además Microsoft ha actualizado las condiciones de uso de su patente para permitir que terceros puedan distribuir Moonlight, esto permite que las distribuciones de Linux puedan incluir Moonlight sin problemas.

Eso si, existe una importante diferencia entre la versión distribuida por Novell y la que se distribuirá por terceros, ya que sólo Novell tendrá acceso a los codecs licenciados, mientras que los terceros podrán distribuir una versión de Moonlight sólo con capacidad de reproducción de formatos libres utilizando Vorbis, Tehora y Ogg, aunque para la reproducción de otros formatos tendrán las siguientes opciones:

• Negociar directamente con los dueños de las licencias de los codecs (MPEG-LA y el instituto Fraunhofer, por ejemplo).
• Negociar con Microsoft el acceso al Microsoft Media Pack.
• Utilizar complementos como GStreamer o otros codecs con licencias comerciales.
• Utilizar hardware para la decodificación (VDPau).

Cabe señalar que Moonlight 2 fue desarrollado con 142.000 líneas de código escritas en C/C++ y 320.000 líneas de código escritas en C# (de las cuales, 125.000 líneas provienen de Microsoft Silverlight Controls, que es de código abierto).

Link: Releasing Moonlight 2, Roadmap to Moonlight 3 and 4 (Miguel de Icaza Blog)

Mono Tools en Visal Studio / Miguel de Icaza

Tu calendario está en lo correcto, no estamos en el día de los inocentes: el proyecto Mono, la implementación libre de la plataforma .NET de Microsoft, ha liberado Mono Tools para Visual Studio, un conjunto de herramientas que buscan simplificar el desarrollo de aplicaciones para Mono en Linux desde Visual Studio.

Con Mono Tools, cualquier desarrollador .NET que utilice Visual Studio puede ser asistido para que su aplicación sea compatible con Mono y Linux, usando las herramientas disponibles en este popular entorno de desarrollo integrado.  Y no sólo se trata de codificar y compilar aplicaciones, la integración es bastante avanzada e integra diversas tecnologías para facilitar la vida del desarrollador.

Mono Tools permite llevar las aplicaciones desde Visual Studio directamente a una máquina con Linux.  A través de UPnP puede buscar automáticamente equipos con Linux en la red local, o bien el usuario puede indicar el nombre de host o ip del servidor al que se quiere conectar para instalar y dejar andando su aplicación.

La depuración de aplicaciones corriendo en Linux se hace directamente desde Visual Studio.  El depurador de Visual Studio se conecta al equipo con Linux para hacer depuración en forma remota, de esta forma todas las capacidades de depuración de Visual Studio se pueden usar con una aplicación corriendo en Linux.

Una de las preocupaciones de los desarrolladores en .NET que desean llevar sus aplicaciones a Mono tiene que ver con el nivel de compatibilidad entre esta implementación y la propia de Microsoft. Para cubrir estas preocupaciones, se incluyó la herramienta MOMA (Mono Migration Analysis) que a través de Visual Studio permite detectar aspectos que pueden afectar la compatibilidad con Mono, por ejemplo alguna API que aún no esté implementada.

Si esto parece fantástico, aún quedan un par de características inimaginables hasta hace poco en Visual Studio. Una de ellas es una herramienta para generar los paquetes RPM de tu aplicación, de esta forma puedes fácilmente crear un archivo de instalación para distribuciones basadas en RPM, como por ejemplo OpenSUSE.

Finalmente y aplicando varias tecnologías, Mono Tools se integra con SUSE Studio para crear appliances que contienen tu aplicación y todo el sistema operativo que necesita para correr.  De esta forma Visual Studio genera un archivo que cualquier usuario puede usar para levantar tu aplicación junto a un sistema completamente funcional desde CD, unidades USB o incluso como imagen de disco de una máquina virtual.

Mono Tools se estuvo desarrollando hace poco más de un año en Novell, antes no se podía pensar en una extensión de este tipo para Visual Studio ya que Microsoft había puesto una restricción para que estas extensiones sólo fueran dirigidas a sistemas Windows, restricción que fue eliminada hace un par de años.  ¿Alguien más se quiere quejar del acuerdo Microsoft-Novell?

Links:
- Mono Tools for Visual Studio (blog de Miguel de Icaza)
- Novell brings Mono to Microsoft’s Visual Studio (InternetNews)

Desde hace bastante tiempo, Richard Stallman viene levantando la voz respecto a los riesgos de usar tecnología de Microsoft que podría estar cubierta por patentes de software, lo que originó un polémico artículo en Fayerwayer, y que posteriormente fue analizado por Oscar Valenzuela, presidente de GNU Chile, en el 3er capítulo de Drunk Podcast.

En esta ocasión y a diferencia de Stallman, Allison puede dar una visión desde un punto de vista similar al de Miguel de Icaza, primero por ser un desarrollador activo y segundo porque su proyecto Samba también es una implementación de tecnología de Microsoft.

Según Allison, las garantías que ofrece Microsoft respecto a futuros pleitos legales por problemas de patentes no son suficientes.  Allison está tan seguro de su posición que renunció a Novell apenas se firmó el acuerdo entre ésta compañía y Microsoft.

En un artículo que era esperado por muchos, Allison declaró que entiende la necesidad técnica de contar con un lenguaje y plataforma que evite perder tiempo en complicaciones que no aportan al producto final, pero no comparte el camino seguido por Miguel de Icaza para crear una implementación libre de la plataforma .NET de Microsoft.

Microsoft no ha sido suficientemente claro respecto a cómo usará sus patentes.  Lo ocurrido con TomTom demuestra que la compañía sí está dispuesta a usarlas, lo que pone en duda qué tanto respetará lo declarado en su Promesa a la Comunidad sobre no aplicar sus patentes contra determinados casos de implementaciones de su tecnología.

Allison dice que el acuerdo entre Novell y Microsoft es un respaldo para Miguel de Icaza, ya que es empleado de Novell, pero no para el resto de la comunidad, que tiene que confiar en una Promesa de discutible respaldo legal. A diferencia de Mono, el proyecto Samba se acoge a un acuerdo mucho más explícito y con respaldo del Departamento de Justicia norteamericano, concretado en el contexto de  los juicios antimonopolio contra Microsoft.

Finalmente Allison dice que una estrategia sana es mover a Mono y sus aplicaciones fuera de los repositorios oficiales de las distribuciones de Linux, tal como ya se hizo con otros componentes sujetos a licencias restrictivas, como los codecs de mp3.

Links:
- Monomania (artículo de Jeremy Allison)
- GNU Chile y las patentes (Drunk Podcast)

(cc) por James Duncan Davidson

Amado por unos y odiado por otros, Richard Stallman finalmente colmó la paciencia de Miguel de Icaza, fundador del proyecto GNOME y actual líder del proyecto Mono. En un reciente artículo publicado en su blog, Miguel contesta un ataque personal de Richard en donde además de formular teorías conspirativas sobre Microsoft y CodePlex Foundation, se refiere en términos despectivos hacia Miguel.

Richard Stallman es conocido por tener una de las posiciones más radicales entre los defensores del Software Libre, tanto así que bajo su perspectiva el Software que no es Libre es simplemente maligno. Para Richard Stallman, hablar solamente de Código Abierto (Open Source) en vez de Software Libre va contra el espíritu de la libertad, enfocándose exclusivamente en una conveniencia práctica.

Para Miguel de Icaza en cambio, el debate entre hablar de la Comunidad del Software Libre o hablar de la Comunidad del Open Source es simplemente ridículo.  Si Miguel ve que algo es bueno desde el punto de vista técnico, entonces es digno de recibir atención.

Entonces no es de extrañar que Miguel y su proyecto Mono, la implementación de código abierto de .NET de Microsoft, sea un mal camino a ojos de Richard.  Y ahora que Miguel pasa a integrar el directorio de CodePlex Foundation, la organización para promover el código abierto de Microsoft, Richard publica un artículo con teorías conspirativas en donde predice que esta organización es una trampa para atraer a los desarrolladores de software libre a la plataforma Windows, entre otras acusaciones.

Con el tiempo, lo que uno comienza a observar es que podemos reconocer dos tipos de miembros de la comunidad del Software Libre/Código Abierto o como le quieran llamar.  Están aquellos que trabajan creando software, resolviendo problemas, aplicando ingeniería y en el fondo, haciendo que las cosas sucedan.  En este grupo tenemos a personajes como Miguel de Icaza, Linus Torvalds, Keith Packard y Greg Kroah-Hartman entre otros.  Por otra parte tenemos a personajes como Richard Stallman que transitan por la órbita ideológica, muy necesaria por cierto, pero que muchas veces se queda atascada en discusiones inútiles como la de usar el término Free Software o Código Abierto, o la constante insistencia en agregar el prefijo GNU cuando se habla de Linux.

Según Miguel, en donde personas como Richard ven desolación, él ve oportunidades.  Claro ejemplo es el proyecto Mono, que en su momento vino a cubrir la necesidad de contar con una API, lenguaje y plataforma potente, moderna y libre. El proyecto ha evolucionado pese a todos los miedos y cuestionamientos infundidos por aquellos que no han movido un dedo por un proyecto de este tipo.

Y esto último es algo que cada vez es más habitual.  Muchos de aquellos que se llenan la boca hablando de la libertad del software, y exigiendo que se desarrolle o use Software Libre, jamás han colaborado con algo de código.  Su aporte a la comunidad sólo se mide en cuantas veces al mes mencionan al proyecto GNU.

Esto no es nuevo, y fue bastante visible en el desarrollo del mismísimo kernel de Linux.  Hubo un momento en que se requería un sistema de control de versiones suficientemente potente para manejar un proyecto y equipo de gran tamaño. En ese tiempo los sistemas existentes eran bastante limitados y apareció Larry McVoy con BitKeeper, un sistema de control de versiones propietario y avanzado desde el punto de vista técnico.  Como Larry admiraba los proyectos de código abierto y en especial el sistema operativo Linux, permitió que su equipo de desarrolladores lo usara en forma totalmente gratuita.  Linus aceptó con gusto.

Cuando esto sucedió, muchos defensores de Software Libre alzaron la voz y sacaron sus antorchas contra Linus Torvalds, “el impuro”, sin embargo no movieron un dedo para crear un sistema de control de versiones equivalente que sirviera para el desarrollo de Linux.

Varios años después, en una especie de complot, algunos personajes causaron que Larry tuviera que cesar el permiso de usar BitKeeper en el desarrollo de Linux, y en todos los años que pasaron nadie construyó un sistema equivalente que fuera libre.  El mismo Linus tuvo que poner manos a la obra y en sólo dos semanas creó la base necesaria para seguir trabajando.  Nuevamente demostró que para que las cosas sucedan, hay que trabajar y no esperar a que “alguien haga algo”.

Tal como un lector comentó acertadamente en Slashdot, Miguel es un constructor y no un derribador de puentes.  Desde hace años que su cercanía con sus pares en Microsoft ha ido logrando cambios en la compañía que si bien aún no se aprecian en niveles directivos, han iniciado una metamorfosis en donde CodePlex Foundation es uno de sus primeros hitos.

Link: De Icaza responds to Stallman (Slashdot)