Hace ya algún tiempo que me estoy deshaciendo de todos los libros que tenía en casa. Excepto por unos pocos ejemplares de especial valor sentimental, la verdad es que la mayoría de los ejemplares siguieron la suerte que depara al papel en Fahrenheit 451.

No tiene sentido conservar un libro ¿para qué? Rara vez uno lo relee, y, si se trata de un ejemplar de consulta, para cuando se va a consultar, normalmente ya está obsoleto y es mejor consultar otra edición.

Steven Johnson publica en Wall Street Journal un artículo titulado How the E-Book Will Change the Way We Read and Write en el que destaca algunos cambios importantes que sufrirá el libro tal y como lo conocemos.

1. El número de página desaparecerá. Ya que la paginación depende del tamaño de la letra y del papel, en un dispositivo donde ambos pueden variar no tiene sentido hablar de lo que se encuentra en la página número tal o cual. En su lugar, todas las páginas deberán ser reemplazadas por URLs.

2. Los autores empezarán a optimizar las páginas y los capítulos para Google. Dado que la relevancia de un libro dependerá de su PageRank, se optimizará la redacción de los textos de modo obtengan mejor posición en los buscadores.

3. Se empezará a licenciar el libro por capítulos y no por volúmenes enteros. En realidad, lo que yo creo que sucederá es que la longuitud de los textos (excepto las novelas) se volverá mucho más corta. Esto es debido a que con un libro, es preciso escribir 100 ó 200 páginas de contenidos para poder justificar porqué se le piden al lector 50€ por un ejemplar. Pero, con una distribución prácticamente gratuita se pueden vender contenidos pequeños por 1 ó 2 euros.

La web de OSOR recopila una buena cantidad de casos de estudio de uso de Software Libre en la administración pública.

Ya sabía yo que meterme contra el modelo de las abejas y los árboles traería polémica.

Surgieron dos aportes interesantes, que copio y pego a continuación, uno sobre el filtrado de mejoras por niveles, y otro sobre el los Productos Open Source Comercial versus los Proyectos Open Source Comunitario.

• 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.”

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