Vivir del software

Quizá en un post anterior pareciese que iba a dejar de desarrollar shareware, olvidarme de Windows, migrar a Linux y a volar. No es exactamente eso lo que llevo en la cabeza. Después de mucho trabajo, mio y de Jaime, creo que los programas y la web de alanit están a un nivel bueno y hay que perseverar en el tema de marketing y distribución. Después de mucho darle vueltas, de hablar con Jaime y de plantear el tema en el foro de el negocio del software hemos sacado varias cosas claras:

• Seguir adelante con la venta de shareware
• Seguir un modelo de negocio basado en ofrecer una versión lite gratuita y una versión de pago con más funcionalidad.
• Intentar establecer relaciones con sitiios de cocina para que promocionen el Puchero, que es el que tiene un público más objetivo.

El cambio sobre lo que estamos haciendo ahova va a consistir en dejar de ofrecer una versión de evaluación para ofrecer una versión gratuita. La versión de evaluación es similar a la registrada, sólo que limitada en los registros a introducir. El problema es que nos está resultando difícil conseguir aparecer en revistas sobre software debido a que prefieren versiones freeware, aunque sean menos potentes que las versiones de evaluación. Lo que vende es el título programa completo o programa gratis.

Las versiones de pago van a seguir siendo las mismas que ahora, y estamos en la fase de decidir que vamos a recortar de las versiones gratuitas, para que queden programas funcionales pero que les falte ese algo que incite al registro de la versión de pago.

error #3: Poner unos foros en la web sin integrarlos correctamente.

Cuando montamos lanueva web pensamos en poner unos foros para los usuarios. Estuve viendo sistemas de foros y decidí usar los foros de phpBB que es un sistema muy conocido y extendido. El problema de este foro es que es muy potente pero al mismo tiempo muy complejo, y me conformé con pegarlo a la web, sin integrarlo correctamente. El caso es que cuando entrabas en los foros parecía como que salias de la web para ir a otro sitio.

Mal hecho. Si quieres ser profesional tienes que parecer profesional.

Ahora he estado modificando un foro basado en el de JoS que encontré en la web de John’s adventures para integrarlo correctamente en la web. Podeis probarlos desde la nueva página de foros de alanit. Son más sencillos que los de phpBB pero están perfectamente integrados en la web.

error #2: Usar registro ligado a máquina y complicar el proceso de registro del programa.

Otro error que cometí fue complicar el proceso de registro. A finales de verano pasado supe que las algunas versiones de mis programas se podian descargar en alguna red P2P y, la verdad es que no me sentó nada bien. Decidí que las nuevas versiones llevarían registro ligado a máquina, esto es el programa generaría una clave de registro en función del ordenador donde estuviera instalado el programa y en función de esta clave habría otra que yo enviaría. El resultado sería que si el usuario quisiera instalar el programa en otro ordenador me tuviera que pedir una nueva clave de activación.

Mal, mal, mal. Esta manera de proceder es un error garrafal. El caso es que ya puse un post sobre el tema en este mismo blog, pero me pudo más el enfado de ver los programas circulando sin control y cedí a la tentación de ponerme el traje de policia. Ahora ya está corregido y en breve lanzaremos unas versiones nuevas que llevan un sistema de registro tradicional por clave que ya no es ligada a máquina.

El usar un modelo de registro ligado a máquina es malo por dos cosas: uno porque el usuario realmente no tiene una licencia de uso del programa, sino una licencia de uso del programa en un determinado ordenador y si cambia de equipo necesitará una nueva clave. Esto crea una inseguridad clara en los usuarios y muchos potenciales usuarios nunca registrarán el programa. En segundo lugar usar un registro ligado a máquina complica el proceso de registro en tanto que en el momento de registrar el programa el usuario tiene que enviar una clave generada con el programa en el ordenador donde lo va a usar. Mucha gente prueba un programa en un ordenador y luego lo va a querer usar en otro distinto, o quiere comprar un programa para un amigo o familiar, o lo que sea. Lo que está claro es que un registro no ligado a máquina es más sencillo. Como experiencia puedo decir que el número de actualizaciones de las versiones que pusimos a la venta en noviembre han sido la tercera parte de lo que yo esperaba, y estoy con
vencido de que mucha culpa la tiene el modelo de registro.

Esta claro que con un registro por número de serie, un usuario puede registrar una licencia y usarla en varios ordenadores, pero realmente creo que los desarrolladores debemos confiar en nuestros usuarios ya que son los que nos permiten seguir en el negocio. Tal como está la cosa con las redes P2P, registrar un programa es más cuestión de voluntad que de otra cosa, y debemos hacer todo lo posible porque el registro de nuestros programas sea lo más sencillo posible.

Con el lanzamiento de las versiones 6.00 y 4.00 de Cuaderno de Bitácora y el Puchero el pasado mes de Noviembre cometí una serie de errores bastante importantes. En una serie de post los iré explicando, diciendo que hice, qué hice mal y porqué.

error #1: Poner un programa a la venta sin tener el fichero de ayuda terminado.

Después de varios meses de desarrollo, y tras haber pasado por una etapa de prueba con nuestros betatesters decidimos poner a la venta las nuevas versiones de los programas. Preparamos la nueva web y lanzamos los programas, dejandonos los ficheros de ayuda sin hacer y pensando que en un mes los tendriamos listos. Han pasado casi 6 meses y esta semana tendremos listos por fin los dichosos ficheros de ayuda. Al no tener los ficheros de ayuda no hemos querido enviar los programas a revistas ni a sitios de descargas pues pensamos que los programas no están completos.

Además, cuando liberas un programa siempre llegas con la lengua fuera y luego te da un bajón de ritmo de trabajo. Aunque al programa le falte la ayuda, inconscientemente piensas que el programa está terminado cuando no lo está y ralentizas un poco el ritmo. Para postre tras anunciar la nueva versión a los usuarios registrados siempre se produce una avalancha de correos que te quita mucho tiempo de desarrollo pues lo tienes que decicar a contestar estos correos.

Cuando se hace desarrollo a ratos como hacemos Jaime y yo, los plazos son incalculables. No sabes si un dia vas a tener 2 horas o ninguna, pero lo peor es que las planificaciones salen al revés. Cuando se acerca Navidad o Semana Santa piensas que vas a tener más tiempo para programar, porque seguro que cae algún dia de vacaciones. Sin embargo es al revés porque la familia, los amigos o cualquier otra actividad absorben tu tiempo libre y en vez de tener más tiempo tienes menos.

El post de Ian Landsman Starting a micro-isv… in the beginning there was nothing contiene algunos aspectos a destacar para cualquiera que quiera empezar en esto de ser un microvendedor de software.

Lo primero que tienes que hacer es leer a la gente que sabe del tema. Ian recomienda a Joel Spolsky, Eric Sink, Brent Simmons y Dave Winner. Tambien recomienda leer a Seth Godin.

Luego habla de la elección del software a realizar, y se plantea hacer algo que conoce – en su caso un software de helpdesk – por dos motivos:

• Es un segmento que ya conoce
• No quiere crear una nueva categoría de software porque piensa que es muy costoso convencer a alguien de que use un producto del que no tiene ninguna referencia. Luego en los comentarios Ian añade que es más fácil innovar en una categoría existente que crear una nueva categoría de software.

Yo sinceramente estoy en desacuerdo con este último punto. Creo que si alguien es capaz de crear un buen software que es realmente innovador, sin duda triunfará. Me vienen a la cabeza casos como ICQ o Napster. Es cierto que luego puedes perder tu mercado por temas de marketing o de que una gran empresa entre en tu segmento, pero si yo tuviera una idea realmente innovadora iría a por ella sin dudarlo.

En el post recomienda encarecidamente crear un blog para comunicar todo aquello que haces a tus clientes potenciales y para recibir críticas y sugerencias. Y ya al final del post hay una afirmación lapidaria cuando habla de la imagen de marca: ‘si no pareces profesional no eres profesional’. En esto estoy totalmente de acuerdo, por muy bueno que sea tu software, si tu web tiene un aspecto de aficionado, con un logo mediocre y un aspecto mediocre, es difícil que un visitante se sienta atraido por tu software y se lo descargue tan siquiera para probarlo. Creo que una página bien construida, con unos buenos gráficos son una invitación a probar tu software.

Hace 10 dias que puse en marcha la nueva web y envié un correo electrónico a mis ususarios anunciando las nuevas versiones. Desde entonces han habido 259 descargas de la demo de el Puchero y 213 de Cuaderno de Bitácora. Entre los correos recibidos de los usuarios he entresacado algunos.

Usuario B0619: Recibí tu mensaje de correo y ya visité la página web, desde donde me descargué la versión 6.00 de Cuaderno de Bitácora. Una vez más, fieles a vuestra costumbre, habéis superado todas las previsiones en cuanto a calidad y diseño. ¡¡Enhorabuena!!

Usuario B0661: Enhorabuena por las actualizaciones. Si lo he entendido bien, aquellos usuarios que, como yo, se hayan registrado hace años y lleven un montón de tiempo usando el/los programa/s, deben pasar por taquilla para obtener las actualizaciones… ¿ Correcto ?

Tengo que decir que este usuario ha actualizado el programa.

Usuario B0113: Te envío un fuerte abrazo desde Barcelona y una vez mas agradecerte la utilidad que tiene este sencillo programa para mi, ya que son muchísimos datos los que tengo guardados con este programa…

Usuario P0647: Me encanta la nueva versión. Está fenomenal. Muchísimas gracias por tu correo y enhorabuena por la nueva Web y la versión actualizada del programa.

Usuario B0161: El programa está fantástico. Ya me gustaba cuando lo compré y ahora la verdad es que está cambiadísimo (para mejor, por supuesto). Me encanta lo de poder escanear la portada y adjuntársela al registro. Y aunque yo lo vaya a utilizar menos, porque lo míuo es la música, me parece muy bueno que la misma base de datos te sirva para tener organizado todo tipo de soportes (Videos, etc). Muy completo. Y la web está muy clara, y bien explicada, así que te felicito efusivamente.

y como no todo el monte es orégano …

Usuario P0676: Gracias por su propaganda, pero el hecho es que compré el PUchero hace más de un año, empezó a darme problemas y ya lo he perdido del todo, no puedo ni abrirlo, así que como comprenderán no voy a comprarles nada más porque el dinero que me gasté en el puchero ha sido inutil.

Gracias al blog de Esteban he conocido el blog de Lachlan Gemmell, que no tiene desperdicio. Es un blog de un programador que deja su trabajo para desarrollar una aplicación propia y cuenta sus aventuras. Leer sus consejos para dejar su trabajo, cómo le da la vuelta al día como un calcetín y la crítica que hace al artículo sobre micro-ISV de Eric Sin es algo que no hay que no ningún programador debe perderse. Este blog va a ir directo al blogroll en la próxima actualización.

Una de las maneras habituales de numerar las versiones de los programas consiste en segmentar el número de versión en tres partes, de la manera 9.99.99:

• El primer segmento es el número de versión propiamente dicho, que se cambia cuando se trata de una revisión en profundidad del programa.
• El segundo segmento es el número de release, que cambia cuando se hace un cambio de funcionalidad importante en el programa, pero no tan importante como para que sea un cambio de versión. Además existe la costumbre de que las los números impares de release son inestables, mientras que cuando se llega a una versión estable se cambia a un número par.
• El tercer segmento es el numero de build dentro de la release.

Hace unos dias, en uno de los grupos de news que visito – xHarbour o Fivetechsoft – alguien propuso una numeración en tres segmentos, pero de la sguiente manera:

• El primer segmento igual que antes.
• El segundo segmento de dos dígitos, el primero del año – en este caso 4 de 2004 – y el segundo del cuatrimestre – ahora sería también 4.
• El tercer segmento de número de build dentro de la release.

La ventaja de este segundo métido de numerar versiones es que sabes que versión es y te haces una idea de cuando fue liberada. En aplicaciones o software en que se liberan versiones continuamente esta segunda notación te hace tener claro lo actualizado o no que tienes tu software.

¿ Opiniones ? ¿ Cual os parece mejor ?

La otra cara de la moneda es dedicarse al desarrollo de componentes. Mientras que hacer software de gestión es algo, más o menos, al alcance de la mayoría de programadores hacer componentes es subir un peldaño más. Pero para hacerlos y atreverte a comercializarlos hay que tener valor, mucho valor. Comercializar un control supone poner tu trabajo en manos de un montón de personas inmisericordes que te van a exigir lo imposible.

Yo colaboré con Paco García en los inicios de Canalfive. Paco hacia los controles y yo la documentación y mentenía la web. Pero lo realmente complejo era el soporte. A Paco lo freían. Paco hacia tenedores y la gente los queria usar como cucharas. Y correo va y lio viene. Era increible. Además Paco nunca decía a nadie ‘esto no se puede hacer’ y había veces que para un usuario en partícular rehacía medio control. Una locura.

Yo no soy capaz de hacer controles. Alguna vez he hecho alguno muy simple y siempre he tenido que pedir ayuda a otra gente. En eso soy bastante torpe, y por eso no oculto mi admiración por los que son capaces de hacerlo. Muchas veces intento retocar algo de otra persona y a veces lo consigo, pero la verdad es que los controles no son lo mio. El tener el código fuente de un control para mi no asegura su continuidad. Además de tener el código tienes que saber donde meterle mano y hacerlo con delicadeza.