A continuación algo que venía pensando hace un tiempo y que había comentado con algunos amigos. Tenía el borrador, pero creo que hoy corresponde publicarlo. Guarda relación con comprar un proyecto de código abierto o cómo ayudar a destruirlo.
Dado el tipo de licencia de un proyecto de código abierto, éste no puede ser comprado. Sin embargo, ello no impide que una empresa o un grupo de ellas, pueda contaminar o destruir un ecosistema (frágil), con o sin intención de hacerlo.
En términos prácticos, no puedes comprar el código de un proyecto FLOSS, pero sí puedes contratar a los programadores clave. Una vez que los has contratado, puedes desviarlos a otros proyectos o tareas rutinarias.
En el corto plazo suena a una estupidez. ¿Qué programador se iría a trabajar a una empresa que no quiere al proyecto? Además, al cabo de un tiempo, estos programadores se pueden reubicar en otras empresas.
Las empresas que nacen a la luz de un proyecto FLOSS, le dan nuevos aires y un mayor impulso al proyecto. Así ocurrió hace un tiempo con MySQL AB o Helixcode, con los proyectos MySQL y GNOME, respectivamente. Estas empresas se formaron por desarrolladores del proyecto, y dado su conocimiento del proyecto, contrataron a un conjunto de programadores clave.
Estas empresas nacieron para hacer negocios con el proyecto que los apasionaba. Tomaron programadores que contribuían en su tiempo libre y los contrataron para trabajar tiempo completo en dichos proyectos. Esto también impulsó la creación de otras empresas.
Que algunas empresas quedaran en el camino, no importaba. Porque el código que habían contribuido quedaba. Y, en el caso de Eazel, muchos de sus desarrolladores se reubicaron en otras empresas relacionadas con el proyecto que apoyaba Eazel (GNOME en este ejemplo).
Hasta aquí todo es miel sobre hojuelas. Las empresas pequeñas tienen que armar su modelo de negocios, proyectar rentabilidad en algún futuro próximo, etc. Muchas de las empresas pequeñas prestan servicios a empresas más grandes, que no saben como interactuar con proyectos FLOSS. Así, por ejemplo, Helixcode (posteriormente Ximian), prestó servicios a HP y también a Novell.
En algún momento, una empresa grande puede evaluar si absorver una empresa más pequeña. Así ocurrió con Sun al comprar MySQL AB (por un monto ridículamente alto), Novell al comprar Ximian o Intel al comprar OpenedHand Ltd. Pueden constituirse en una nueva división de la empresa, si son afortunados.
En el corto plazo es atractivo: es el respaldo de una empresa grande a un proyecto FLOSS. Y mientras dura la luna de miel, todos contentos. Pero la mística de una empresa pequeña, centrada en un proyecto FLOSS, en donde todos sus miembros saben de qué se trata, no se puede traspasar fácilmente a una empresa mayor.
Ante los vaivenes de la economía dicha mística sucumbe. Sobretodo cuando comienza la reducción de personal y/o la re-orientación de los negocios. Así, una empresa pequeña que pudo tener 20 ó 30 programadores dedicados al proyecto que los vio nacer, terminan con 3 ó 4 realmente trabajando en el proyecto, pero a veces, de manera parcial.
Antes estas circunstancias, es fácil buscar otros horizontes. Algunos, quizás, buscando relacionarse con el mismo proyecto. Pero la mística, en general, ya no es la misma. Y el proyecto perdió a un número importante de buenos programadores.
A esto yo lo llamo contaminar un proyecto, porque un grupo de programadores clave baja su productividad en el proyecto o termina abandonando el proyecto.
Por otro lado, se puede crear un ecosistema frágil, como el que creó Nokia cuando adoptó GTK+ en su tableta Internet 770. Nokia es un cliente muy importante, y se formaron empresas alrededor que comenzaron a prestar servicios a Nokia, todos relacionados con GTK+ y tecnologías afines a GNOME. La luna de miel se extiende. Se crean nuevas empresas por desarrolladores del proyecto que, obviamente, contratan a programadores clave del mismo proyecto.
Todo estuvo muy bien, pero lo cierto es que es lo mismo que colocar todos los huevos en la misma canasta. En el momento que Nokia decide cambiar de rumbo, las empresas cuyo principal cliente son ellos, quedan en la disyuntiva: cambiar de rumbo son su cliente o diversificarse. Aquellas que no lograron diversificarse antes, estarán obligadas a cantar la canción que el DJ decida colocar.
Alguna de dichas empresas, pudo encontrar un nuevo gran cliente que finalmente lo termina absorbiendo. Es el caso de OpenedHand, que fue comprada por Intel y luego pasaron a ser conocidos por el desarrollo de Moblin.
Y se repite la misma historia. En el momento que Intel decide cambiar de rumbo, desde GTK+ a Qt, ¿cuál es la ruta lógica que seguirán los programadores de OpenedHand? En el corto plazo, algunos continuarán trabajando en lo que venían haciendo, pero en el mediano o plazo, es insensato pensar que continuarán pagando a desarrolladores para trabajar en GTK+.
Al igual como anunció Nokia el 2009, el mensaje será: no se elimina el soporte de GTK+, sólo se transfiere a la comunidad.
El que una empresa decida cambiar de un GTK+ a Qt, es un dato anecdótico. Puede doler un poco en el orgullo de un proyecto e incentivarlos a replantearse. Pero en dicho cambio o adopción en sí, no hay daño.
El problema radica en envenenar al proyecto vía tomar desarrolladores clave y que ya no puedan dedicarse a trabajar en él.
Si una empresa grande quisiera hacerlo a propósito, podría. No tiene que atacar al código, ni sus licencias. Tiene que envenenar a su comunidad, y particularmente, a sus líderes. Un proyecto como el núcleo de Linux, no tiene por donde ser atacado, pero proyectos que no son tan grandes como Linux, son vulnerables.
Si el proyecto es pequeño, entonces lo que más uno podría desear, es que le ocurra a su proyecto. Aunque esto se puede esperar más de una empresa que recién parte.
Finalmente, conocimiento esta amenaza (con o sin intención), un proyecto puede prepararse para que no le ocurra.
Aclaración: lo que he escrito aquí es a título personal y de ninguna manera corresponde a la posición del proyecto GNOME, ni de la Fundación GNOME. Y lo aclaro, por si no parece políticamente correcto.
Germán,
Muy buen post. Excelente para la última lectura de la noche :-)
Saludos!
Interesante entrada de nuevo, Germán. En mi opinión, el mayor problema que esta situación trae es la pérdida de liderazgo en el proyecto. Esto supone que el proyecto sigue evolucionando por inercia, sin que se establezcan objetivos a mediano-largo plazo.
Tengo la impresión que GNOME carece de objetivos “estratégicos”. En cada ciclo se plantean una serie de cambios evolutivos, pero no existe una conciencia de lo que pretende obtener en x ciclos. La ausencia de líderes hace que nadie evalúe globalmente el proyecto y se prioricen las actuaciones que debe hacer la comunidad. Lo más parecido a un cambio estratégico es GNOME 3.0, pero es una excepción de la regla. Espero que esto cambie en el futuro.
PD: En mi opinión, lo más urgente es renovar GTK+, hacerla más moderna y atractiva para los nuevos programadores y fomentar su uso multiplataforma y multilenguaje. En momentos en los que no se sabe a donde se quiere ir, lo habitual es volver a los orígenes :)
A pesar de estar de estar de acuerdo con tu artículo, me parece que Nokia había decidido hace tiempo (mucho antes del anuncio de la alianza con Intel, supongo que poco después de la compra de Trolltech) de que la versión Diablo+2 (no recuerdo el nombre) sería utilizando Qt, por tanto se ha tenido tiempo para pensar que Gtk no iba a dar “más rendimiento” en los productos de Nokia.
Juanjo: En general, estoy de acuerdo contigo. No creo que Qt sea más fácil de usar, pero si hay muchos más recursos en hacerlo parecer así. La maquinaria de marketing detrás es bastante fuerte. La diferencia entre el sitio de GTK+ y el de Qt es abismante, pero no por ello uno es más fácil de usar que otro. Aunque ya nos alejamos del motivo de mi nota, en donde use a MySQL, Novell, Nokia e Intel como ejemplos.
arpia49: Precisamente me refiero a dicho anuncio (junio de 2009) cuando hablo de Nokia. En el ejemplo no es que hubiera tiempo o no para pensar que GTK+ no iba a ser utilizado por Nokia, sino que un grupo de programadores clave de GNOME iba a comenzar a desarrollar aplicaciones sin ninguna relación con GNOME, más bien con Qt.
Si tienes una empresa, cuyo principal cliente es Nokia; navegas al son de los que diga Nokia. Así son los negocios. Y para una empresa no es fácil decir: ahora buscaremos otro cliente que nos permita obtener el mismo nivel de ingresos que Nokia nos brinda. Algunos optan (o se ven obligados) a adaptarse y con ello se llevan a los desarrolladores (clave) de un proyecto.
Así se convierte un proyecto, como en el ejemlo GNOME, en un semillero de buenos desarrolladores para otros proyectos. Si las salidas son mayores que las entradas, el envenamiento puede destruir un proyecto, que es lo esencial de mi mensaje.
Germán: Si, creo que estamos de acuerdo sobre tema principal de tu entrada. La cuestión es entonces, ¿qué podemos hacer para contrarrestar o al menos aliviar sus efectos?. Creo que parte de la solución pasa por evitar que los proyectos entren en una inercia demasiado conservadora por falta de liderazgo para mejorar o innovar. En el caso de GNOME quizás sea interesante introducir metas de mayor calado cada varios ciclos estables.
Respecto al tema secundario que he introducido sobre las mejoras en GTK, te recomiendo esta presentación de la GUADEC 2008 de Alberto Ruiz, aunque seguramente ya la conozcas o incluso hayas asistido a ella :)
http://live.gnome.org/GUADEC/2008/Slides?action=AttachFile&do=view&target=marketing_gtk_Guadec2008.pdf
Excelente post, esto lleva pasando desde siempre y creo que la única solución es crear fundaciones que se dediquen al apoyo de estas aplicaciones. Por ejemplo ya se debería crear una Fundación MySQL para que el desarrollo no dependa de su mas directo competidor, osea Oracle.