Tercera parte de la mini serie sobre cómo crear un proyecto open source exitoso.

Regla Nº 15 Confiar en que una licencia OSI salvará un producto mediocre.
Los usuarios no adptan un producto por su licencia, lo adoptan por su funcionalidad y calidad, si la licencia es compatible con sus necesidades.

Regla Nº 16 Confiar en que si se fabrica un producto superior la gente lo comprará sólo por ser técnicamente mejor.
Despreciar el marketing es muy típico de los ingenieros en general y de los informáticos en particular. Conviene no olvidar que incluso en las empresas con mayor inversión en innovación los gastos de I+D no suelen superar nunca el 10% del presupuesto.

Regla Nº 17 Confiar en que La Comunidad contribuirá significativamente al desarrollo.
La Comunidad puede contribuir a testear el producto y a internacionalizarlo, en algunos casos incluso puede añadir extensiones o nuevos módulos; pero es muy díficil (y poco recomendable) que el núcleo del producto lo toquen más de 6 ó 10 personas.

Regla Nº 18 Confiar en que los usuarios aceptarán un producto sin terminar con la promesa de mejoras futuras.
Los clientes están hastiados de vaporware. Se lo han vendido demasiadas veces. De modo que es poco probable que se sientan muy inclinados a empezar con la versión 0.5 alfa a la espera de la 1.0.

Regla Nº 19 Minusvalorar los costes ocultos de desarrollo.
El software tiene deseconomías de escala. Cuanto más crece el proyecto más costoso se vuelve añadirle cosas. Lo que empieza como un ágil felino con 3 ó 4 programadores de alta productividad puede degenerar en un mastodóntico dinosaurio que consume toneladas de hierba al día sólo para seguir con vida.

Regla Nº 20 Sacar builds inestables.
Estoy profundamente en desacuerdo con el dicho Open Source "release soon, release early". Sacar builds inestables sólo sirve para frustrar a los usuarios y llenar de flames el buzón de soporte.

Regla Nº 21 No dar soporte adecuado: gratuito y de pago.
Muchos modelos de negocio Open Source hablan de vivir del soporte y los servicios de valor añadido. Y, no obstante, mucho proyectos paradójicamente lo reducen a lo eliminan porque: a) Consume mucho tiempo y b) Es aburrido.
¿Si se pretende vivir de los servicios hay que poner toda la carne en el asador para potenciarlos?

Ver la segunda parte de esta serie: Mejores prácticas.