Roberto Galoppini comenta en su blog la revisión del Modelo de las Abejas y los Árboles de James Dixon (CTO de Pentaho).

Este modelo compara el funcionamiento de una Comunidad Open Source con la de una colmena de abejas con una reina y un ejército de obreras.

Cada uno puede tener su opinión, claro está. Yo opino que el modelo de la colmena está fundamentalmente equivocado. Y reto a cualquier lector a poner un ejemplo de un solo producto Open Source Comercial que realmente funcione de esa forma. En el web de la comunidad de Penthao, con más de 29.000 usuarios registrados, no hay ni un sólo proyecto de un tercero, y a duras penas se puede conseguir una respuesta útil en los foros sin soporte de pago incluso para cosas que son claramente bugs.

Veamos el resumen del modelo según Dixon:

Los desarrolladores del núcleo son amenudo los fundadores del proyecto. Típicamente ellos realizan la mayoría del desarrollo. Y diseñan el roadmap del producto. Ellos son la abeja reina.”

Hasta aquí de acuerdo.

La Comunidad participa en muchos roles, que involucran diseñar, implementar y testear el software. La Comunidad se beneficia del Proyecto y el Proyecto se beneficia de la Comunidad. La Comunidad es como las abejas obreras.”

Rotunda y radicalmente falso. Voy a explicar lo que hace realmente la Comunidad:

1º) Si no saben cómo hacer algo (lo que sea) escriben un mensaje pidiendo ayuda.

2º) Si el cliente final les hace una pregunta que no saben responder, trasladan esta pregunta a la abeja reina.

3º) Si algo no funciona, escriben un mensaje pidiendo que lo arreglen, urgente, urgente, urgente.

4º) Si necesitan agregar algo al proyecto, desarrollan ellos mismos lo mínimo imprescindible y que le puedan facturar al cliente. Cuando el cliente deja de pagar, dejan de realizar extensiones, las cuales, la mayoría de las veces, se quedan a medio hacer.

5º) Una vez que tienen hecha su extensión de producto, tratan de que la abeja reina les ayude a comercializarla, pero compartiendo lo mínimo posible con otras abejas obreras.

Los miembros de la Comunidad no son abejas obreras, en realidad se parecen más bien a los zánganos. Y esto lo digo sin ninguna connotación peyorativa ¿Porqué iban a ser obreras? La reina gana invirtiendo en el proyecto en forma de revenue share con las obreras. Pero ¿qué gana una obrera invirtiendo tiempo extra de desarrollo en nada que no necesite estrictamente para si misma? La idea de que contribuyendo código la obrera ganará karma y que gracias a él conseguirá más proyectos es ingenua. Porque las empresas piensan en términos de inversiones y retornos, no en términos de karma e imagen en el mercado.

No hay 'go to market' en un producto Open Source [...] Los proyectos de fuente abierta crean software, no un 'producto completo'”

Craso error. Es prácticamente imposible monetizar un producto que no es una solución completa. Los clientes compran soluciones, no trocitos de soluciones en forma de un kit de hágaselo usted mismo.

No hay un rol específico de marketing, de modo que los proyectos Open Source ocupan un espacio en la mente del consumidor y atraen a los miembros de la Comunidad a través de artículos técnicos, blogs y boca-a-boca”

Si, y dos huevos duros. Claro que hay un rol de marketing. Que se haga mediante buzz marketing o comiéndole la oreja a los de Gartner es una cosa. Pero ¡ay! ¡pobre de aquel que se olvide del marketing en un proyecto Open Source y confie en que se difundirá viralmente por si solo!

Posts relacionados:
Open Loquesea
Vuelta al modelo de negocio de licencias
Haciendo dinero del canal
Clientes que no pagan ni a punta de pistola
Reflexión comunal sobre el Open Source
The Long Tail ERP

• Sobre Open ERP se comenta:

En Open ERP han montado 3 niveles de colaboración. El core del producto únicamente lo modifica el quality team el cual lo forman 20 personas de las cuales 5, NO pertenecen a Tiny Bélgica. Son 5 colaboradores de empresas externas.

El siguiente nivel es el commiters team. En este grupo de 80 personas hay gente que pertenece a empresas partners oficiales de Open ERP y gente independiente.

Y el último nivel es el community team. Aquí puede entrar cualquiera.

Cuando alguien de community desarrolla algo, simplemente abre una rama en lauchpad y lo sube. Si alguien lo quiere usar lo usa. Si la persona quiere que se incluya en ramas oficiales de extra addons o módulos adicionales de la herramienta, le solicita a un commiter que lo valide y lo suba a una rama commiters. Cuando un commiter considera que algo es tan general que puede incluirse en el core de la herramienta, solicita a un miembro de quality que lo evalúe y se incluya.

[...]

Nosotros estamos montando un proyecto de colaboración inter empresas. Yo si veo que una empresa colabora en lo que sea y tiene bugs arreglados y un karma alto, voy a subcontratarles antes que a otros que no han hecho nada por la comunidad. Esto es evidente. Y si colaboras, participas en foros y te haces un nombre, te llaman.”

• Sobre Adempiere, Carlos Antonio Ruiz comenta:

No conozco ningún producto Open Source Comercial que funcione.

Creo que cuando mencionas Open Source Comercial todo lo que dices es cierto, la abeja reina saca provecho de la "Comunidad", pero es que normalmente la comunidad son una serie de partners que pagan y por esta razón esperan algo a cambio.

Pero probablemente encuentres ese modelo si miras un Proyecto Open Source Comunitario.
Es diferente hablar de un "producto comercial" que hablar de un "proyecto comunitario".

Es la diferencia entre:

MySQL Producto Open Source Comercial (de MySQL a Sun y ahora a Oracle).

PostgreSQL Proyecto Open Source Comunitario (imposible comprarlo, no puede cambiar de manos como MySQL, tampoco puede llegar alguien a cerrar código como hizo Sun con MySQL, y nadie anda con temores de que llegue Oracle y lo desaparezca comprándolo).

Openbravo y Compiere Productos Open Source Comercial.

Adempiere Proyecto Open Source Comunitario.”