Durante los últimos 15 años mi zona de confort ha estado delimitada por el uso de sistemas operativos Windows y desarrollo de programas con xHarbour y FWH. Con este par de lenguajes he sido capaz de hacer programación de escritorio en entornos Windows y me he sentido muy cómodo con ellos. Han servido para mi propósito al crear primero jsnsoftware y luego alanit, que era vender software de acuerdo a la modalidad de distribución conocida como shareware. La aventura ha sido muy satisfactoria a nivel personal, pues me ha permitido aprender muchas cosas relativas a hacer y vender software empaquetado. Ha sido una de las cosas que he hecho en mi vida de la que estoy más orgulloso.

Hace tres años que compré mi primer Mac. Desde entonces que tengo el gusanillo de programar en OS X, pero siempre han surgido cosas que me han hecho aplazar el aprendizaje. Quizás la más importante haya sido que Windows era mi primer sistema operativo como usuario. Cuando tenía que arrancar el ordenador para hacer alguna cosa, casi siempre arrancaba Windows. Cuando arrancada Mac era para hacer alguna tarea específica que no podía hacer con Windows. Sin embargo, en el último año las tornas han cambiado. Ahora Mac OS X es mi primer sistema operativo, con el que arranco habitualmente el ordenador, y sólo arranco Windows cuando tengo que hacer alguna tarea específica que no puedo hacer con Mac OS X. Sin embargo el cambio no es completo, me falta precisamente lo que más me gusta hacer con un ordenador: programar.

Así que he decidido retomar el empeño de aprender Cocoa y hacer software para Mac OS X. Esto supone definitivamente abandonar mi zona de confort y entrar en un terreno totalmente desconocido para mi. Aunque en verano los niños mandan, quiero dedicarme a leer el libro de la vespa cuando tenga un ratito, teniendo presente una frase del prólogo del libro que me ha encantado: Antes de continuar, te aseguro que no eres tonto y que simplemente algunas cosas son difíciles. Armado con esta simple afirmación y la cabeza descansada, estás listo para aprender Cocoa.

El despliegue de software - deployment en inglés - es el conjunto de actividades que permiten que un determinado software se pueda usar en cualquier máquina. Muchos programadores no saben lo que es el despliegue y otros muchos confunden el despliegue con preparar un paquete de instalación de su software mediante programas como InnoSetup o similares. También existe determinado tipo de software, de acuerdo a los cinco mundos de Spolsky, que no necesita despliegue. Los programadores que hacen software interno o empotrado rara vez tendrán que preocuparse por el despliegue de su aplicación. Pero si alguna vez lo tienen que hacer, casi seguro que se meterán en un buen lio.El despliegue no comienza cuando se termina el programa, sino que debe comenzar precisamente con el comienzo del mismo. Una de las partes que más dolores de cabeza dan en el despliegue es la parte de creación de bases de datos o estructuras de datos del programa. Para que el despligue de una aplicación sea correcto debe incluir procedimientos automáticos de creación de la base de datos que vaya a utilizar, y esto debe planificarse cuidadosamente desde el inicio de la aplicación. Hace poco hablaba con un amigo que trabaja en una empresa pública. Resulta que han hecho una aplicación interna muy buena y se la han premiado como una mejora de los procedimientos administrativos. Esto ha hecho que se conozca la exstencia de la aplicación y se la pidan de otras organizaciones similares, y ahí ha empezado su calvario. Ahora están desmontando la aplicación, pues tiene un fuerte acoplamiento con otras aplicaciones internas y no tiene sistema automático de creación de las bases de datos que utiliza. El problema de todo esto es que nunca pensaron que su aplicación iba a salir de su organismo, y no pensaron jamas en términos de despliegue. Moraleja: no importa que tipo de software hagas, piensa siempre que algún dia querrás distribuir tu aplicación. Piensa en terminos de despliegue.Con el despliegue debes asegurarte de que tu programa va a funcionar en cualquier ordenador que cumpla unos requisitos mínimos de máquina y de sistema operativo. La creación de directorios, copia de archivos, registro de componentes, activación del programa y creación de enlaces en el menú inicio o en el escritorio debe ser completamente transparente al usuario. No hay nada más frustrante que descargarte una aplicación y tener que hacer tu los ajustes a mano para que funcione el programa y que después de un buen rato de pelearte con la aplicación no consigas hacerla funcionar. A mi me ha pasado más de una vez y se te queda muy mal sabor de boca. Si quieres evitarte problemas de despliegue tienes que intentar que tu aplicación sea autocontenida en la medida de lo posible, y que no tengas que recurrir a instalar otros componentes de terceros y menos aun que estos componentes de terceros se tengan que configurar a mano.En alanit todos los programas están hechos pensando en el despliegue. Cuando un programa arranca lo primero que hace es comprobar que existen todos los ficheros de datos necesarios para funcionar, y si alguno no existe se crea automáticamente. La instalación de nuevas versiones es no agresiva, si existen ficheros de datos del usuario el programa de instalación no copia los ficheros de datos que el programa trae por defecto. Y por supuesto, ningún paquete de instalación no se llama setup.exe.

Creo que en cualquier profesión debes marcarte el camino a seguir en cuanto a tu propia carrera profesional. Aunque mi trabajo de día es en una empresa que muchas veces no sabe donde va y le cuesta mucho decidir que camino tomar, en lo que concierne a mis intereses personales intento definir cual es mi plan director a medio plazo. Este plan director u hoja de ruta refleja cuales son mis áreas de interés, que tecnologías son las que voy a intentar aprender y desarrollar a medio plazo, marcando cual va a ser mi linea de desarrollo profesional a nivel personal. Después de dar muchas vueltas a la farola, tengo decidida cual va a ser mi hoja de ruta para el 2008.Mi principal interés ahora mismo es el desarrollo web. Entre todas las plataformas que se pueden utilizar para ello, he decidido utilizar PHP. Los motivos para elegir este lenguaje son varios, pero quiza haya pesado mucho ver la cantidad de cosas que hay hechas con PHP, como por ejemplo WordPress que es el gestor de contenidos que utilizo para hace funcionar este blog. Otros factores a su favor son tratarse de un lenguaje libre y multiplataforma, que tiene conectores con muchos gestores de bases de datos y que cuenta con mucha documentación y una amplia comunidad y con muchos frameworks que facilitan el trabajo, aunque de momento no me planteo trabajar con ellos sino centrarme en conocer el lenguaje.Me he puesto a aprender PHP a la antigua usanza, via libro tocho y leyendo despacito. El primer libro que estoy leyendo es Desarrollo Web con PHP, Apache y Mysql, que me ha parecido un buen libro sobre el tema. Más adelante quiero leer otro de la misma colección sobre posicionamiento con PHP que por lo que he hojeado me ha parecido muy interesante. Aunque los conceptos de xhtml y css los tengo bastante claros, quiero leer también los libros sobre esto que hay en librosweb. Muchas cosas para el poco tiempo que me tengo, pero creo que merece la pena dar el salto a desarrollar para la web.Aunque tengo instalado Apache+MySql+PHP5 tanto en Vista como en OS X, mis pinitos con PHP los hago con OS X. El motivo es que OS X es un sistema Unix y la mayoría de sitios de alojamiento corren bajo Linux, con lo que la codificación de archivos, el sistema de permisos y demás es similar. Ya me ha pasado de hacer un script con PHP en Windows que al subirlo al servidor no funcionaba por culpa de la distinta codificación de archivos en Windows y Linux respecto a los caracteres de salto de linea, así que trabajar en un sistema Unix me ayuda a conocer mejor los entresijos de este tipo de desarrollo.No voy a dejar de momento el desarrollo de aplicaciones de escritorio para Windows, y quiero mantener y mejorar los programas de alanit. Pero también me gustaría aprender Cocoa para programar para OS X, aunque esto esté en un segundo orden de prioridades.

Hace como dos años, decidimos cambiar la estrategia de negocio y ofrecer ediciones gratuitas de nuestros programas. El año 2005 fue el peor en cuanto a ventas de los programas y decidimos ofrecer versiones de los programas sin límite de registros ni de tiempo de uso, pero limitando la funcionalidad de seleccionar claves de tablas auxiliares. Cuando se intenta usar esta funcionalidad los programas muestran una ventana diciendo que esa funcionalidad está disponible unicamente en la edición registrada, muestra un enlace a la página con la comparativa de ediciones y otro a la página de compra del programa.De esta manera pensabamos llamar más la atención al ofrecer software gratis al tiempo que incentivamos el registro del mismo. Pensabamos que la edición gratuita era plenamente funcional, con la pega que todos los datos de claves ajenas había que meterlas a mano y que era mejor manera de ofrecer el software que limitar las versiones a un determinado número de dias o de registros.La semana recibimos un correo de un señor muy enfadado que decía que se había descargado la edición gratuita de Azeta y que no había podido evaluarlo porque al tratar de usarlo el programa le remitía constantemente a la compra del programa. El señor decía sentirse engañado y que hubiese preferido una versión limitada en tiempo o registros a introducir. Aparte de los calificativos que nos propinaba, nos decía de todo de una manera muy educada, correos como ese son los que te mueven a reflexionar sobre si estás haciendo las cosas bien.Por los correos que recibimos, sabemos que hay mucha gente que usa las ediciones gratuitas con total normalidad, de tal manera que ni se plantean pagar por las ediciones registradas. En ese sentido pensamos que la estrategia es buena pues da a conocer el programa y la persona que no la va a registrar, porque hay personas que nunca registran un software por muy util o barato que sea, lo puede usar sin más. Nosotros usamos mucho software gratuito, que a veces son ediciones recortadas de versiones más potentes, y en este sentido pensamos que publicando ediciones gratuitas de nuestros programas devolvemos lo que recibimos.La alternativa sería utilizar versiones recortadas en número de registros o en tiempo de uso, pero pensamos que estas versiones presentan varios inconvenientes. La primera es que frena a su utilización por los potenciales usuarios, que saben que la versión va a caducar. La segunda es que los programas limitados de esta manera son muy más fáciles de crackear. No es que pensamos que hay muchos crackers interesados en nuestros programas, pero ver versiones anteriores de nuestros programas circulando sin control no fue algo bonito.Por todo esto pensamos seguir ofreciendo ediciones gratuitas de la manera en que lo estamos haciendo. Con anterioridad ofrecimos ediciones limitadas en el número de registros a introducir, y pensamos que acertamos con el cambio a las ediciones gratuitas.

Hasta ahora en alanit hemos vendido software a la manera tradicional, es decir cobrando por la licencia del programa y después por las actualizaciones. Hace un año o así decidimos que la compra de un programa llevaría aparejada la gratuidad de actualizaciones durante un año, pasado el cual el usuario que quisiera actualizar su programa debería pagar de nuevo la licencia. Esto conlleva a veces algún problema con los usuarios, en el sentido de que si al sacar una actualización el usuario se queda fuera por un margen de tiempo corto, un par de semanas por ejemplo, pues se puede quejar. Ante esto hemos optado por no poner problemas al acceso a estas actualizaciones y digamos que no somos estrictos en las fechas. Lo que si lleva aparejado este tipo de licencia es que tienes que controlar cuando ha comprado un señor la licencia del programa y demás, pues una cosa es que no llegue a la actualización por dos semana y otra por dos años.

Ahora estoy preparando un nuevo programa. Mi idea es lanzar una nueva web para el nuevo programa, que será exclusiva para él, de manera que se diferencie de los otros programas que vendo actualmente. Esta diferenciación obedece a que estoy planteandome una nueva modalidad en la venta de software: cobrar una sola vez por el software. La idea es vender el programa más caro, no por los 20 € actuales sino por 40 €, y dar actualizaciones gratuitas del mismo por tiempo indefinido. Así al usuario le ofrezco actualizaciones y soporte indefinido, y me quito yo problemas de intendencia de enmedio. ¿ Porqué este cambio ? Pues quiza porque la modalidad de venta que uso actualmente ya se como funciona, y quiza sea momento de experimentar algo nuevo. Lo que no tengo claro es si ofrecer una garantía de uso mayor y actualizaciones ilimitadas supondrá un atractivo suficiente al usuario para que pague por el programa más dinero del que paga habitualmente por los otros. Por una parte voy a perder los ingresos de
los usuarios fieles que actualizan el programa cada vez que hay una nueva funcionalidad interesante, pero por otro si el número de ventas mensuales se mantiene voy a ganar mas dinero.

De momento esta nueva modalidad de venta es una idea y requiere maduración. Si algún lector conoce algo similar o tiene alguna experiencia o sugerencia al respecto estaré encantado en escucharla.

Ya me referí una vez a la larga cola, una teoría que explica que la existencia de superventas va unido a un modelo de distribución básado en el acceso a los productos, y de como la modificación de este acceso a los productos redistribuye la demanda entre más elementos. Hace poco encontré el documento Distribución digital de la cultura: la larga cola, que ahonda en la citada teoría y nos sirve de espera hasta que se publique el libro original en castellano.

Hace ya algún tiempo que dije que uno de mis objetivos para este año es aprender a programar en Mono y/o .Net. El motivo principal es conocer todos los entresijos que hay detrás de la plataforma .Net usando un lenguaje moderno como es C#.

Como tampoco es plan de dejarse los dientes en esto lo mejor es comenzar por .Net, leyendo cosas sobre el tema y adentrándose en la terminología del CLR, el MSIL y demás. En este primer propósito me ha servido bastante estos dos trabajos: Estudio de la plataforma .Net e Introducción al lenguaje de programación C#. También estoy leyendo Técnicas y herramientas de desarrollo ágil para .Net para conocer que posibilidades brinda .Net para hacer desarrollo ágil.

Para aprender C# tengo pedido el libro Como dominar C# desde el principio y sobre Mono he pedido Mono: A Developer’s Notebook.

Me he instalado el SDK de .Net 1.1 y también el IDE OpenSource SharpDevelop. A partir de aqui lo que toca es leer e ir haciendo pinitos. En fin, que aburrirme lo que es aburrirme no creo que me aburra mucho este año.

Gracias a José he leido el artículo Software: No longer business as usual. El artículo expone preocupación de grandes empresas de software debido a la creciente resistencia de los consumidores a pagar por software empaquetado, y de cómo el software open source o financiado por publicidad está haciendo crecer esta resistencia.

Un análisis similar se puede aplicar al mercado donde nos movemos los micro-isv: cada vez hay más competencia en cualquier segmento de software y continuamente aparecen empresas con modelos de negocio distintos a la tradicional de venta de licencia de uso, como por ejemplo software basado en web financiado por publicidad o incluso aplicaciones web cuyo objetivo último es vender la propia aplicación web. En software basado en web es factible usar modelos de pago por uso mensual, por ejemplo, pero en software de escritorio el tema es más complejo.

Una reflexión muy interesante sobre este tema la leí hace tiempo en el foro de JoS, y venía a decir que el modelo tradicional de venta de licencias de uso era similar al de la venta de libros y que había que ir a un modelo similar a la venta de suscripciones de revistas. El autor del post decía que una vez que un usuario hace un registro de un programa queda a expensas de cuando decidirá el desarrollador que una nueva versión es de pago o se trata de una actualización gratuita. Por ejemplo, si registras un programa hoy y la semana que viene el desarrollador saca una actualización de pago… pues la has ****do en caso de que no te regale la actualización. En el modelo de licencias como de libros, el desarrollador se centra en el desarrollo de la nueva versión que es la que le va a reportar ingresos de actualizaciones y deja un tanto de lado las correcciones de errores de la versión actual. En el modelo de software como de suscripciones a revistas tal co
mo se planteaba en el post, al registrar un programa tendrías derecho a las actualizaciones gratuitas durante un tiempo determinado, por ejemplo un año, a partir del cual si quieres actualizas el programa para obtener las actualizaciones dutante otro año o te quedas con la versión que tienes, que es tuya y no te la quita nadie. Este modelo es beneficioso para el usuario en tanto que no queda a expensas de cambios de versión arbitrarias, y por otra parte es beneficioso para el desarrollador en tanto que puede realizar una mejora continua del programa y no se centra unicamente en la nueva versión de pago.

En cualquier caso, creo que dejar claro las condiciones de acceso a las actualizaciones de los programas es un aspecto a cuidar y que puede inclinar la balanza a la hora de que un posible usuario decida o no hacer el registro de un programa.

Hace unos dias en el foro de Planeta Código planteaba la pregunta de si es mejor hacer versiones de evaluación limitadas en prestaciones o versiones gratuitas. El hilo del mensaje está aquí.

En el impagable foro de the business of software ha surgido el mismo tema y tras varias respuestas alguien ha proporcionado el enlace a un pequeño estudio con datos experimentales sobre el tema. Lo primero destacable es lo que dice el autor de que hay cinco cosas básicas para triunfar:

• el programa debe responder a las necesidades reales de los posibles usuarios

• el programa debe ser realmente bueno, y no algo de segunda fila
• los potenciales usuarios deber tener conocimiento de que el programa existe
• el programa debe llegar a estos usuarios
• y tiene que haber una razón para que paguen por él

A continuación plantea un caso con datos reales - esperemos que ciertos - sobre ventas de un software en que se dejaba una versión completa a los usuarios y otro en que había un incentivo para hacer el registro y que era un recorte de funcionalidad. Las ventas del segundo fueron 5 veces mayores a las del primero. La conclusión que saca el autor del estudio es que si el usuario no tiene necesidad de pagar para conseguir una funcionalidad que necesitan no te va a pagar por tu cara bonita.

Para mi Septiembre es casi siempre el primer mes del año. En verano suelo reflexionar sobre lo que he estado haciendo durante el año anterior y de alguna manera tratar de planificar el próximo. Supongo que ayuda la faceta de docente, que de alguna manera te liga al calendario escolar.

Para este año, la idea es terminar durante el mes de septiembre las nuevas versiones de Cuaderno de Bitácora y el Puchero con la supresión de BtnGet y las altas dinámicas de claves ajenas. Una vez hecho esto intentar queremos jugar en las major leagues: internacionalizar los programas y lanzarnos a vender en el mundo mundial. Antes de eso tenemos que terminar algunas cosas de la web, como la gestión de la lista de correo que se nos está atragantando. Intentamos instalar phplist pero la cosa se complicó, y vamos a probar con dadamail que parece más sencillo aunque menos potente.

Los iconos de los nuevos programas van a ser de iconexperience. Hemos comprado las colecciones Application Basics y Objects & People y estamos adaptando los progamas con los nuevos iconos. Realmente quedan impresionantes… como en esta captura de azeta:

Y para este invierno los libros que tengo en cartera son:

• Liberando los ideavirus, de Seth Godin
• La frontera del éxito de Malcolm Gladwell