El fin de una microISV es el de vender un producto (mejor ir de uno en uno), por lo que el primer problema al que nos enfrentaremos será el de escoger una de entre todas esas grandes ideas que seguro que tenemos para desarrollarla hasta el final. No hay que olvidar que queremos vivir del software, ¿no?.

Para determinar la idea escogida, podemos utilizar distintos criterios (preferencia o interés personal, posibilidades comerciales que le vemos, etc.), pero ¿qué ocurre si no tengo una gran idea clara?, ¿cómo la consigo?. Lo ideal sería que no nos molestásemos en pensarlo, que nos la dieran en forma de pedido, pero no siempre tendremos esa suerte. Aunque hay varias aproximaciones para hacer frente a un sequía de ideas, hay un punto común en la mayoría de los productos y servicios que han tenido éxito en internet en los últimos años: prestar atención.

Observar

La mayoría de los buenos productos nacen de la necesidad. Si observas con atención podrás detectar varias situaciones en las que un nuevo producto facilite la relación con la tecnología de los usuarios. No tiene que ser único, no tiene porque ser el más bonito, simplemente tiene que hacerles la vida más fácil. Debemos tener en cuenta que si hacemos algo tremendamente innovador y novedoso añadiremos una dificultad más a nuestras tareas: la de crear la necesidad de nuestro producto en el mercado. Este fue el caso de la empresa H5 Technologies, que creó un sustituto mejorado para los códigos de barra pero que no encontró clientes con ganas de dar el cambio.

Veamos algún caso más. Pierre Omidyer creo eBay como un sitio dónde su novia pudiera intercambiar figuritas dispensadoras de caramelos PEZ con otros coleccionistas. Chud Hurley y Steve Chen crearon YouTube a partir de una cena dónde varios amigos comentaban la necesidad de poder compartir online sus vídeos personales. El simulador de exámenes para la certificación PMP ProjectioPM se creo a partir de una persona que estudió para dicha certificación. Texmate, el conocido editor para Mac OS X, se creo por la insatisfacción de un usuario con el resto de editores. ¿Quiere de decir eso que no había foros dónde intercambiar objetos por internet?, ¿FTPs para compartir archivos?, ¿ningún simulador de exámenes PMP en el mercado?, ¿ningún editor de texto para Mac OS X?. No, simplemente vieron oportunidades o se mostraron confiados en poder hacer algo mejor a lo ya existente.

Alianzas Creativas

¿Y si no somos muy observadores?. Tranquilos, aún tenemos esperanzas. Aunque nos cueste mucho creerlo, los informáticos sabemos mucho de lo nuestro pero no demasiado del otros negocios.

Pongamos el caso de una consulta médica. Podemos tener más o menos claro que existen clientes/pacientes, citas/visita, enfermedades y medicamentos. ¿Sabemos ya lo necesario para ponernos a programar una aplicación de gestión clínica?. Obviamente no. ¿Sabemos si el problema real de una consulta es gestionar las citas? (¿no les vale el Outlook?), ¿o será el acceder rápidamente al historial? (¿compartir ficheros con una política de seguridad?). ¿O será agrupar los documentos físicos que genera cada paciente? (¿quizás es suficiente una convención de nombres?). ¿Sabemos si el visitador médico les regala el software con la compra de la última máquina XXX?. O el caso de de una consignataria naviera, ¿sabemos si nuestro sistema basado en teléfonos móviles tiene sentido?. Quizás los operadores tengan manos tan grandes que no puedan operar el teclado de nuestro dispositivo con agilidad. Estas dudas nos pueden inundar sea cual sea el área de actividad que escojamos.

¿Entonces que hacemos?. Aprender. Alguien te tiene que dejar aprender de su negocio para que el resultado sea óptimo. Si no lo hacemos así, puede que todo el tiempo que le dediquemos a nuestro producto no tenga sentido.

Supongamos que tenemos un amigo médico. Aunque realmente valdría cualquier tipo de profesión: carpintero metálico, antenista o camionero, simplemente cada uno tiene sus problemas a los que podemos dar solución (o minimizar) por medio de nuestro producto. Cada vez que os reunís, aprovechando que somos informáticos, nos cuenta sus problemas con la informática. Y si hay un hueco ahí… ¡bingo, tenemos una idea!. Si además nuestro amigo es el jefe, lo tendremos más fácil, aunque corremos el peligro de que nos explote.

Si no es el jefe (o si lo es pero además de amigo es justo), o si es un tercero que aporta otro servicio (como el visitador médico que comentábamos anteriormente), podéis crear algún tipo de alianza que sea buena para los dos: a ti para aprender de un sector y desarrollar un mejor producto, a él para mejorar su negocio. Por ejemplo:

• podemos desarrollar a una precio reducido. Ya que nos está permitiendo aprender sobre su sector, podemos cobrarle un precio reducido (quizás un fijo mensual suficiente para cubrir gastos). él obtiene un producto mejor, y a ti te están pagando por algo por lo que normalmente no lo harían, además de conseguir nosotros también un mejor producto. Por que no debemos olvidar que lo hacemos para crear un producto que venderemos a más gente, de no hacerlo así estaríamos haciendo una rebaja en el precio de un proyecto, y de eso ni hablar. * además lo ideal sería implicar a este socio en las ventas. Si el habla de nuestro producto a sus colegas (en reuniones, foros, boletines, etc.) tendremos mucho hecho del primer paso del marketing. Es más, lo están haciendo por nosotros. Para asegurarnos de que se implica realmente podemos ofrecerle un incentivo por cada licencia o instalación que vendamos.

Estas alianzas no siempre son posibles o fáciles, normalmente por causa de miedos infundados. Por eso hay que incentivarlas, para asegurarnos de que todos tenemos interés en que el producto tenga posibilidades de venta. Sigue sin ser una garantía, pero es otra pequeña ayuda.

¿Por dónde empezar?

Una vez ya nos hemos decidido por el producto en cuestión. ¿Por dónde empezar?. ¿Abrimos el entorno de desarrollo y nos ponemos a programar?. De eso se trata, ¿no?. Esto… no, o no del todo. Antes de comenzar a programar (o a analizar y diseñar, si somos correctos) tenemos que tener claro tanto lo que queremos que hacer, como todo lo que tenemos que hacer. A fin de cuentas vamos a dedicar a esto los próximos meses de nuestra vida, de modo que mejor hacerlo bien. Porque sí, serán meses, da igual lo rápido que programemos.

A la hora de vender un producto tenemos que tener en cuenta que hay muchas tareas además de las propias del desarrollo de software, que no por ser importante (si no programamos no tendremos producto) hace las demás menos vitales. Estas tareas son las que iremos describiendo en el resto de las secciones del documento. Al pensar en nuestro producto tendremos que pensar en como hacer que nos conozcan (marketing), en como conseguir clientes (comercial), en dar ayuda y soporte a nuestros clientes, en como distribuirlo, así como en distintos aspectos legales que nos afectarán (facturación, contratos, etc.). Todas estas labores tienen su coste, consumirán parte de nuestro tiempo y de nuestro dinero, pero es imprescindibles. De nada sirve que construyamos un gran producto si nadie lo conoce o no lo puede comprar.

Si estamos de acuerdo que todo esto forma parte de nuestro producto, deberíamos estar de acuerdo en dos cosas más:

• que su coste debería también ser imputado a ese producto, de modo que podamos ver las necesidades de inversión en él, cuando resulta rentable, etc.
• que organizar nuestro tiempo para ser productivos es vital. No queremos que seis meses después de haber comenzado con nuestra idea la tengamos que dejar con la sensación de haber perdido el tiempo, ¿verdad?

Software ¿libre?

En algún momento deberemos decidir como queremos licenciar nuestro software. ¿Software libre?. ¿Privativo?¹. ¿Una mezcla de ambos?. Analicemos un poco los pros y los contras de antes de dejarnos llevar por la propaganda o el corazón. Cuanto antes decidamos esto mejor para nuestra aventura, puesto que puede hacer que nos comportemos de forma distinta a la hora de planificar y ejecutar nuestro día a día.

Supongamos que escogemos una licencia de software libre. Con esto podemos conseguir que nuestra comunidad de usuarios crezca más rápidamente (no entender esto como que el marketing no es necesario!), pero tú quieres vivir de esto, ¿no es verdad?. Veamos de dónde se le saca el dinero tradicionalmente y si puede ser aplicable a nuestra situación.

• Servicios: Es lo que más se escucha al hablar de hacer dinero con el software libre. La parte mala es que una microISV, con recursos tan limitados como los nuestros, tiene una capacidad para dar servicio muy limitada. O al menos no con todas las garantías que a nuestros clientes les gustaría (¿qué sucede si nos ponemos enfermo?), por lo que puede ser difícil. Neodoo, por ejemplo, es una empresa española que da soporte sobre un software libre que no desarrolla, JBoss.

• Documentación: Normalmente va de la mano del caso la anterior, y se trata de ocultar cierta información (ejemplos, explicaciones más completas) de forma que nos paguen por acceder a ella o, mejor aún, nos contraten para ayudar a usar/integrar nuestro producto. Con el emule es mal momento para esto, pero como digo, suele ir unida a una oferta de servicios, que es lo que realmente interesa. Quizás el caso más conocido en esta situación sea el de la herramienta de generación de gráficos en Java JFreeChart.

• Licencias duales: En muchas ocasiones se juega con una licencia libre como medio publicitario o formas de conseguir comunidad de usuarios (con la intención de que pasen a pagar por el software de una manera u otra), pero sin liberar todo el código fuente, dejándolo para una versión comercial extendida de pago. O, otra de las razones de un licenciamiento dual, es emplear una licencia vírica², ofreciéndoles que pasen por caja si desean evitar esto. Un ejemplo sería el de la plataforma de VoIP Asterisk.

• Acceso al código fuente: Aunque la gente no lo suele entender, el propio Stallman empezó vendiendo emacs (tan fácil como: envíame 20USD y te envío el código en un disquete), de modo que nada impide que lo hagas de nuevo. El mundo de internet ha revolucionado esto y no puedes impedir que quién te lo ha comprado lo ponga en circulación, pero siempre puedes vender el acceso al SVN en modo de subscripción (es decir, con las actualizaciones). El ser software libre NO obliga a que pongas paquetes para descarga en sourceforge, las cuatro libertades tradicionales del software libre no van por ahí, sino de lo que ocurre después de venderlo.

Así que dadas las circunstancias… ¿deberíamos escoger una licencia libre para nuestro producto?. Depende. Depende de nuestro mercado, depende de nuestra plataforma, depende del tipo de producto y depende también de nuestra capacidad para crear una comunidad entorno a él (es la forma en la que tendremos beneficios).

En el mundo de Apple y Mac OS X, por ejemplo, los usuarios están más habituados a pagar pequeñas cantidades por su software, los de Linux a no pagarlo y los de Windows a usar el emule para descargarlo (perdón por el simplismo de esta segmentación). En tipos de productos dónde hay ya grandes herramientas libres (o un exceso de ellas, por ejemplo, de gestión de proyectos vía web o navegadores para la web) será más difícil colocarlo si no es realmente especial (en funcionalidad, soporte, etc.). No es lo mismo tampoco un producto para informáticos (que saben lo que es el software libre) que uno para farmacéuticos (que, probablemente, ni lo saben ni les interesa). Un software libre requerirá también que invirtamos en aspectos que fomenten la comunidad de desarrolladores y usuarios entorno a él, algo que también nos exigirá tiempo, ya que un software libre que no fomenta esto no tiene más sentido que el propagandístico.

La respuesta no es fácil, tenemos que vivir de nuestro producto (ya sea de su venta o de servicios alrededor de él) y tenemos recursos muy limitados, de modo que tenemos que pensar bien esta parte. Un jefe para el que trabajé solía decir que a la mayoría de los clientes la licencia les importaba más bien poco, que sólo les importaba tener un teléfono para quejarse si algo iba mal. Es posible que tuviera razón.