¿Has pensado alguna vez en iniciar tu propio proyecto Open Source?
¿Lo empezaste pero consigió ganar la masa crítica que esperabas?
Una de las críticas frecuentes que se hacen a Open Source es que existen demasiados proyectos. Quizá es excesivamente fácil empezar un programa sin tener ningún plan claro acerca de su viabilidad.
En esta mini serie doy algunas claves acerca de cómo diseñar, implementar y promocionar un proyecto open source para que sea popular y rentable.
He dividido los contenidos en 4 artículos:
– Fundamentos
– Mejores prácticas
– Trampas a evitar
– Publicidad, promoción y ventas
Regla Nº1: Los buenos programas empiezan por resolver una necesidad de la persona que los creó.
Pregúntate a ti mismo ¿mi propio software en realmente útil para mi mismo? Si la respuesta es afirmativa has empezado por el buen camino. Si ni tú mismo usas tu propio software, es probable que tampoco le interese a nadie más.
Regla Nº2: Los programas populares resuelven los problemas de mucha gente.
Aunque el programa sea realmente bueno, si sólo resuelve los problemas de una minoría de personas, es probable que nunca adquiera una gran notoriedad. Es la diferencia entre fabricar un compilador y fabricar un compresor estilo WinZIP. Hay una cantidad razonable de gente que necesita compilar pero hay una cantidad mucho mayor que necesita comprimir algo para poder enviarlo.
Dsde luego inventar un algoritmo para la nueva generación de internet semántica puede ser muy divertido (y si te lo compra Google también muy rentable) pero es más probable que el publico en general se interese por algo estilo eMule. Por eso los proyectos como GNOME son tan populares, porque todo el mundo necesita un escritorio.
Regla Nº3: Es igualmente importante el tamaño del mercado que cuanta competencia está entrando.
Es por ello que quizá no es tan buena idea fabricar en solitario otra distro de Linux u otro compresor.
Cuanto mayor sea el target el producto, mayor la probabilidad de que una gran empresa ponga su ojo sobre dicho trozo de la tarta. Como las batallas por los reproductores multimedia.
Regla Nº4: El factor de innovación es relevante.
Los usuarios no cambian de una tecnología a otra sólo porque aporte pequeñas mejoras. Debe haber un salto cualitativo real para que se produzca una migración de una aplicación a otra. Un ejemplo es el tabbed browsing de Mozilla, es una mejora de usabilidad bastante útil, pero, en si misma no justificaría la existencia de un nuevo navegador. Es por este motivo que Opera languidece, el navegador es bueno, pero, a la postre no hay tanta casi diferencia con Internet Explorer.
Regla Nº5: Se escriben progamas para un mercado, no para un concurso.
Sólo hay básicamente 3 plataformas para desarrollar un proyecto orientado a consumo masivo: PHP, .NET (Mono) o Java.
Si escribes tu programa en algo más exótico que eso tienes un 99% de probabilidades de que no progrese mucho.
Programar para el mercado también implica a veces hacer algunos sacrificios en el purismo del diseño.
El noventa y pico por ciento de los usuario [aún] tienen Internet Explorer, de modo que desarrollar sólo teniendo en cuenta los navegadores libres no es una muy buena idea.
Regla Nº6: Todos los grandes programas nacen de otro pequeño.
Los usuarios buscan killer applications, programas que hacen una única cosa muy bien: ya sea comprimir, mandar mail o bloggear.
Poner toneladas y toneladas de funcionalidades mediocres extra no mejora el producto, sólo lo complica y lo hace más difícil de mantener.
Regla Nº7: Hay que desarrollar para la economía globalizada.
Es más probable captar el primer cliente en Marruecos que en EE.UU.
Si, ya se, EE.UU. es la meca del software y África es el tercer mundo.
Pero es poco probable que te inviten a entrar por la puerta grande en Boeing o en McDonnell-Douglas. En cambio es posible que encuentres un mercado desabastecido en el sur, siempre y cuando diseñases tu software para soportar Unicode y escritura de derecha a izquierda, claro.
Ver la segunda parte de esta serie: Mejores Prácticas.
-
Entradas por RSS -
Entradas Populares