Haz que tu proyecto sea un éxito (2/4 – Mejores prácticas)

Segunda parte de la mini serie sobre cómo crear un proyecto open source exitoso.
Regla Nº8 Si lo vas a vender, el producto debe ser una solución completa
Para los usuarios es muy difícil coger un poquito de aquí y otro poquito de hallá y montar su infraestructura tecnológica como si fuese un kit de hágaselo usted mismo. ¿Porqué fueron un éxito de ventas Lotus Notes o Exchange? Pensándolo bien ¿Que alternativas factibles tenían las grandes empresas en su momento para montar GroupWare y Workflow? Sendmail y un puñado de programas pegados no, desde luego.
Si la solución no es completa puede que llegue a hacerse popular, pero será muy difícil ganar dinero con ella. Ese es el caso de JUnit, por ejemplo.
Regla Nº9 Debe percibirse una propuesta de valor tangible para el cliente final.
No sé cuantas veces he oído a un informático que este programa optimiza tal o cual proceso. Pero ¿cual es el valor económico para el cliente? Hay que tener en cuenta que (en general) los clientes están más interesados en conquistar mercados que en reduir costes.
Regla Nº10 Debe haber un modelo de negocio para los intermediarios.
Es prácticamente imposible llevar a buen término ninguna misión sin la ayuda de otros. En el caso de Open Source uno de los problemas abiertos es el modelo de negocio para los resellers. Cuando se vendían cajas era muy fácil, porque bastaba con ofrecer una comisión sobre ventas al minorista, pero ¿qué sucede cuando el producto es gratuito? Recientemente el incremento de la demanda de Open Source por parte de las administraciones públicas ha despertado el interés de las consultoras por este tipo de soluciones, que, hasta la fecha, había sido más bien escaso ante la (aparente) ausencia de ingresos sustanciosos.
Regla Nº11 Debe ser más barato de adoptar que de fabricar.
Si el producto es demasiado pequeño o demasiado difícil puede que al cliente le compense más hacérselo él mismo que superar la curva de aprendizaje.
Regla Nº12 Debe dirigirse al nicho de mercado adecuado.
No todos los sectores se adaptan igualmente bien a Open Source. Y, de los que se adaptan, algunos pueden estar demasiado copados como para que resulte interesante entrar.
Preferentemente debe ser un nicho lo más horizontal posible, porque en los nichos verticales las soluciones tienden a tener que adaptarse en exceso a las necesidades de cada cliente dificultando enormemente la reutilización de código.
Una trampa habitual es empezar pensando que se fabrica un producto y terminar con 6 ó 7 ramas de código diferentes e incompatibles a la medida de cada cliente vaca.
Regla Nº13 Debe contar con el respaldo de otros fabricantes.
El respaldo de los OEM y de las grandes empresas importa. Es por ello que es mejor desarrollar en Java o Mono que en otros lenguajes, se puede contar con (al menos) la simpatía de Sun, IBM o Novell. Excepción hecha de PHP que es por si mismo terriblemente popular.
Regla Nº14 El ámbito de alcance debe ser lo más global posible.
Salvo que vivas en EE.UU. tu mercado local es probablemente demasiado pequeño para soportar los costes de I+D.
Ver la primera parte de esta serie: Fundamentos.