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.
