SourceForge puede ser (todavía) el repositorio de proyectos Open Source más grande que existe, lanzado en el siglo pasado (1999) y con más de 230.000 proyectos y 2 Millones de usuarios registrados. Por eso, este análisis tiene cierta relevancia en su intento de descubrir cuáles son las aplicaciones de código abierto más descargadas de todos los tiempos.

El estudio usa las mismas estadísticas publicadas por SourceForge, que obviamente no incluyen aquellas aplicaciones hospedadas afuera de ese sitio. Sin embargo, los números involucrados son sencillamente impresionantes por su acumulado histórico:

1. eMule: 520.970.337 descargas.
2. Vuze (antes "Azureus"): 489.705.154 descargas.
3. Ares Galaxy: 217.874.303 descargas.
4. 7-Zip: 86.568.760 descargas.
5. FileZilla: 78.252.037 descargas.
6. GIMP for Windows: 69.140.671 descargas.
7. Audacity: 67.176.645 descargas.
8. PortableApps: 63.566.590 descargas.
9. DC++: 57.183.915 descargas.
10. Microsoft core fonts: 55.374.584 descargas.

Y para todos los que vivimos en las nubes más que con los pies en la tierra, esta noticia sin duda hará más divertido (y corto) nuestro fin de semana: el proyecto del simulador de vuelo libre, abierto y multiplataforma FlightGear anunció así de brevemente el lanzamiento de su versión 2.0 con importantes novedades que incluyen nuevas y dramáticas condiciones de iluminación y nubes 3D, mejor soporte para escenarios personalizados, un mundo exterior más dinámico (autos, trenes, etc.), más de 200 modelos de aeronaves disponibles para descargar, y mucho más.

El lanzamiento coincide también con el de SimGear 2.0, el conjunto de librerías de código abierto para la creación de simulaciones 3D, juegos y otras visualizaciones de datos en el que está basado FlightGear.

Nota: el video incluído arriba es sólo una pequeña demostración de lo que podemos encontrar en FlightGear 2.0, para tener una mejor idea de todo lo que ofrece esta nueva versión no se pierdan su nueva galería de capturas de pantalla.

Y después de haber sido "incubado" desde finales del año pasado en la Apache Software Foundation (ASF), el sistema de control de versiones centralizado de Subversion (SVN) finalmente ya es oficialmente un proyecto de primer nivel en la prestigiosa organización sin fines de lucro. Un comité de directores de la ASF así lo votó ayer y la comunidad de SVN se apresuró a festejarlo poco después. El nuevo hogar de Subversion ahora puede encontrarse en subversion.apache.org.

Aunque para los actuales usuarios de SVN todo esto significará poco, sí es un indicio indiscutible del ascenso en la aceptación del modelo de desarrollo compartido pero descentralizado de otros sistemas de control de versiones más modernos como Git, Mercurial y Bazaar, a costa de la popularidad de los viejos sistemas centralizados como SVN. Lo que a su vez hace inevitable la pregunta:

¿Se está convirtiendo Apache en el cementerio de elefantes de los proyectos de código abierto?

Red Hat comenzó a migrar a sus clientes desde Xen a KVM comenzando a medidados del año pasado como parte de su nueva estrategia de virtualización construída completamente sobre la máquina virtual basada en el Kernel Linux (proyecto que a propósito lidera desde que compró Qumranet en el 2008). Su distribución Red Hat Enterprise Linux (RHEL) se convertiría poco después en la primera en soportar comercialmente a KVM.

Ahora Novell quiere seguir esos mismos pasos, apostando también fuertemente a KVM, pero bajo sus mismas reglas. Y así comenzaría a hacerlo con su proyecto AlacrityVM, un nuevo hypervisor basado en KVM pero "enfocado en la performance" que ya demuestra unas mejoras notables.

Según la página de AlacrityVM:

“Los entornos virtualizados a menudo imponen significativas penalidades en la performance en una carga de trabajo determinada cuando se los compara con equivalentes nativos. Este proyecto está motivado en la creencia de que esto no tiene que ser necesariamente así, y que no necesitamos hardware exótico para conseguirlo. AlacrityVM demuestra que la mayoría de los cuellos de botella en la performance se deben a pilas de software sub-óptimas.”

Adobe estuvo recibiendo duras críticas últimamente, notablemente también la del mismo Steve Jobs, por culpa de su plataforma Flash. Como parte de su defensa, en su blog Open at Adobe se publica un artículo donde intentan explicar por qué no pueden abrir el código del reproductor de Flash. Y aparentemente el culpable sería un viejo conocido:

“La principal razón por la que no podemos el Flash Player como Open Source es porque hay tecnología en el reproductor que no es nuestra, como el códec de video de alta definición estándar de la industria, H.264. Adobe paga por ese códec para que el video se reproduzca confiablemente en todo el mundo, en varios navegadores y sistemas operativos. Así que lo hacemos tan abierto como podemos - liberando las especificaciones.”

Las especificaciones del formato de archivos de Flash (SWF) sí están abiertas, y teóricamente cualquiera puede hacer su propio reproductor, incluyendo a Apple. Gracias a esas especificaciones es que sí existen reproductores libres, como Gnash y Swfdec.

La promesa de Nokia de hace dos años se hizo realidad hoy mismo, cuando finalmente el gigante finlandés de la telefonía móvil abrió todas casi todas las 40 millones de líneas código fuente de su sistema operativo Symbian bajo la licencia EPL (Eclipse Public Licence); que notablemente no requiere que sus usuarios contribuyan sus modificaciones de vuelta a la comunidad.

La mayor parte del código está disponible en el sitio de desarrolladores de Symbian, con algunos componentes amparados bajo otras licencias similares a la EPL y algunas herramientas bajo la Symbian Foundation License (SFL). El código de estas últimas está disponible sólo a las instituciones que se hagan miembros de la Symbian Foundation.

Adelantándose a rematar cualquier inevitable comparación con el sistema operativo Android de Google, Lee Williams, el director ejecutivo de Symbian Foundation aclaró que:

“Cerca de un tercio del código de Android está abierto y nada más. Y lo que está abierto es una colección de middleware. Todo lo demás está cerrado o es propietario”.

Symbian actualmente hace funcionar a la mayoría de los teléfonos de Nokia (aparentemente más de 330 millones) y también a otros de algunas empresas más, como Sony Ericsson, Motorola, Samsung y Panasonic. ¿Suficientes para atraer a más desarrolladores?

El hacker del Kernel Greg Kroah-Hartman reflexiona en su blog sobre el problema de las modificaciones en el núcleo de Linux hechas por Android, el sistema operativo para dispositivos móviles de Google que está aumentando su popularidad entre los modernos teléfonos celulares de varios fabricantes.

Básicamente, estos problemas, que ya causaron la eliminación de los drivers de Android de la actual versión de desarrollo 2.6.33 del Kernel, se deben a que su código fuente no es convenientemente mantenido por sus desarrolladores. Pero el verdadero motivo de esa aparente inexplicable desidia nos revela un poco más sobre la verdadera naturaleza de Android:

Kroah-Hartman explica que Android "es mucho más que sólo unos pocos drivers raros", se trata de un nuevo tipo de locks que debe ser integrado al Kernel, una infraestructura de framebuffer "totalmente diferente" y de drivers que deben ser modificados para soportar "un modelo de seguridad a veces bizarro".

Pero lo peor de todo es que si Google no fusiona su código con el Kernel las empresas que produzcan drivers u otro código para Android no tendrán la posibilidad de contribuir sus creaciones a la comunidad de Linux, quedando condenadas a ciclos de desarrollo y mantenimiento mucho más largos.

Según Kroah-Hartman, Google no muestra señales de estar trabajando para modificar su código, por lo que intentará exponer "todo el lío de Android" en la próxima conferencia CELF Embedded Linux, a llevarse a cabo del 12 al 14 de Abril.

Hasta este momento la muy anticipada versión 2.8 de GIMP no tenía ni siquiera una fecha de lanzamiento tentativa, prefiriendo sus desarrolladores sólo mencionar que sería lanzada "cuando estuviera lista". Ahora es el contribuyente de ese proyecto Martin Nordholts el que adelanta en su blog que finalmente hay una fecha estimada y que esta sería el próximo Lunes 27 de Diciembre.

Obviamente, esa fecha todavía debe considerarse como un objetivo tentativo, que entre otras cosas ayude a los desarrolladores de GIMP a orientar mejor su trabajo.

Por otro lado, Nordholts reporta además que se avanzó en la refactorización y la "limpieza" del código para implementar la próxima única ventana de GIMP y que también se agregará soporte para múltiples ventanas acopladas (como se muestra en la captura de arriba).

Con este brevísimo mensaje se anunció que el "Steering Committee" del GCC (GNU Compiler Collection) aceptó el frontend gccgo para su inclusión en su versión 4.5 o posterior, el que agregará soporte para el lenguaje de programacón Go de Google en la imprescindible colección de compiladores del proyecto GNU.

Esta noticia llega sólo días después de que en el último el índice de TIOBE, empresa que publica mensualmente un ránking de la popularidad de los lenguajes a nivel mundial, Go apareciera por primera vez en el puesto número 13 convirtiéndose en el escalador más rápido de todos y ubicándose sólo detrás de Objective-C (el del iPhone y Mac OS X) a pesar de haber sido lanzado oficialmente hace menos de 3 meses.

Además de C y C++, GCC incluye actualmente frontends para lenguajes como Ada, Fortran, Java, Objective-C y Objective-C++; otros frontends disponibles pero que todavía no son parte oficial de GCC incluyen a Cobol, D, Pascal y Modula-2/3, entre otros.