semana vista

Semana vista es el título de un excelente blog sobre productividad personal puesto en marcha por el incansable Juanjo Navarro. El contenido del blog es tremendamente útil para cualquier persona que intente ser efectiva en su trabajo y sobre todo para el caso de realizar este trabajo para ti mismo o en casa. Post como siete sugerencias en informática doméstica o los consejos para trabajar en casa valen para más de una reflexión. Por cierto en un post sobre gestores de contraseñas Juanjo recomienda Colossus. Gracias Juanjo.

actualizaciones de programas

La semana pasada terminamos las actualizaciones de los programas y la web y subimos las nuevas versiones de Cuaderno de Bitácora y el Puchero a la web de alanit. Las principales novedades que traen las versiones son los nuevos bitmaps de los programas, que son los de iconexperience, y el tema de las altas dinámicas en tablas auxiliares. Además hemos corregido un montón de pequeños bugs y cosas que no estaban del todo bien hechas.

Pero quiza el cambio más importante, y lo que más nos ha costado decidir ha sido el cambio en el modo de distribución. A partir de estas versiones los programas de alanit se presentan en dos ediciones:

  • Una edición gratuita sin límite de registros a introducir ni límite de tiempo de uso, pero con algunas limitaciones en funcionalidad.
  • Una edición registrada con todas las funcionalidades del programa. El precio de esta edición es de 15 euros e incluye un año de actualizaciones gratuitas

¿ Que intentamos con este cambio de modo de vender los programas ? Pues principalmente ampliar el número de posibles usuarios en base a ofrecer ediciones gratuitas que haga más atractivo descargar el programa. Y por otra parte al bajar el precio lo dejamos a un precio que esperamos que los interesados en los programas ni se planteen buscar versiones P-) ni similares. Al ofrecer un año de actualizaciones gratuitas pensamos que damos un empujón más al interesado a decidir por el registro del programa al darle un margen grande para que su pago se amortice.

Los resultados de todos estos cambios son una incognita, pero el cambio de modo de licenciar los programas es firme y no hay vuelta atrás. Ahora nuestros pasos se encaminan a internacionalizar los programas y tener listas versiones en inglés en breve y a promocionar al máximo las versiones disponibles.

El primero en dar el salto de la i18n y el conejillo de indias para esto ha sido Colossus que ya funciona en español e inglés. Faltra traducir la ayuda, pero tampoco es mucha tela comparado con lo que puede ser traducir la ayuda de los otros programas.

Sobre la promoción de los programas queremos disparar a todo lo que tenga relación con nuestros programas desde sitios de descarga de programas hasta sitios web sobre cocina. Y dedicarle tiempo a esto, que es en lo que siempre pinchamos. Estamos convencidos de que vamos por el buen camino, que los programas tienen buen nivel pero hay que darlos a conocer más. De momento nos hemos llevado una alegría: el Puchero fue portada durante un par de dias en UptoDown y en una semana llevamos casi mil descargas de la edición gratuita.

a la búsqueda del modelo de negocio

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.

como ser un micro-isv

Este finde pasado estuve en la reunión de Olivares2000 que se celebró en la sede de Atisa. Tengo que decir que la organización fue excelente, la sala estaba completamente equipada y todo funcionó de maravilla, incluida la videoconferencia con Walter Negro. Quiero agradecer desde aqui a José Alfonso Suarez y al personal de Atisa por el exquisito trato recibido.

Mi contribución a la reunión fue una charla sobre el tinglado este de ser un micro-isv. Como hubo algún asistente que se interesó por la presentación, aquí dejo el PDF con el contenido de la charla.

GO2005 y más

Este fin de semana toca reunión de Olivares2000. Nos vemos en Madrid un grupo de entusiastas del xbase para contarnos cosas, y como a cada uno de nosotros le tiran cosas distintas tenemos mucho que contar. Yo voy a contar en que consiste esto de ser un micro-isv y ya tengo preparada la charla con presentación – OOo – incluida. Probablemente publique la presentación aquí o en el sitio de GO2000 cuando pase el fin de semana. Este año vamos a ser bastantes asistentes, y un ingrediente para mi muy importante de cosas como esta es el contacto humano con amigos con los que habitualmente te relacionas via internet, bien por correo o por msn. Por cierto, que este año mi amigo Manuel pincha y no puede venir. ¡ Killo, te voy a echar de menos !

Al margen de esto estamos de lleno en periodo de betatest de las nuevas versiones de Cuaderno de Bitácora y el Puchero. Aparte de lo que son nuevas funcionalidades de los programas, lo que más nos ha costado decidir es el nuevo modelo de distribución basado en una edición gratuita y otra de pago con funcionalidades añadidas. Y es que muchas veces las deciones estratégicas son las más dificiles de tomar, mucho más que picar código. De todo esto hablaré el sábado a las 10 de la mañana. Para asistir a las conferencias hay que registrarse en la web de Olivares2000.

hackers y pintores

hackear y pintar tienen mucho en común

las grandes compañías ganan al fracasar menos que las otras compañías grandes

una forma de escribir software genial es arrancar con tu propia iniciativa

el trabajo de día hace referencia al fenómeno presente cuando se tiene un trabajo que se hace por dinero y otro por amor

el software grandioso requiere una devoción fanática por la belleza

en la labor del hacker el trabajo viene en ciclos

parte de lo que debe hacer el software es explicarse a sí mismo

Paul Graham, Hackers & Painters – traducido aquí 😉

shareware sin protección

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.

software libre de puertas cerradas

Via Barrapunto he leido un interesante artículo publicado en la revista Novática y titulado Sobre proyectos de Software Libre / Código Abierto de «puerta cerrada»: enseñanzas del enfoque de selección de desarrolladores para Firefox de Mozilla, disponible en PDF. En el artículo se abordan los beneficios del enfoque de mantener cerrado el código de un proyecto libre, de manera que sólo es mantenido por un grupo pequeño de desarrolladores al cual se accede por meritocracia. El artículo es super interesante y ameno de leer.

El tema me ha recordado al caso MiniGUI y también al caso Ilias.

Personalmente creo que este enfoque es muy correcto para proyectos open source, ya que tener el código abierto y a disposición de que cualquier persona lo toque es una auténtica temeridad. Este concepto – que sólo unos pocos tengan acceso al código – contradice uno de los principios clásicos del movimiento Open Source, pero creo que esta situación cada vez va a ser más habitual.

cosas que no debes hacer … ¿ o sí ?

En su artículo Set your priorities Joel Spolsky habla de como establecer las prioridades a la hora de decidir que funcionalidades se van a incluir en una nueva versión de una aplicación. Como siempre propone un método particular para ello, pero antes dice dos cosas que no debes hacer:

  • No implementar una funcionalidad simplemente porque alguien se la ha prometido a un cliente
  • No hacer algo porque parece que sea inevitable

La explicación la da en su artículo, pero dedica una sóla linea a explicar que el primer punto no debe ir reñido con escuchar a los usuarios.

Cuando eres un micro-isv no hay departamento de ventas. Tu eres el departamento de ventas, asi que llevas mucho cuidado en qué le dices a un usuario acerca de una determinada funcionalidad requerida para el programa. Y tienes que pensar siempre en lo que te va a costar implementar esta funcionalidad y la mejora que va a suponer para el programa.

Muchas de las funcionalidades de el Puchero están hechas gracias a una usuaria del mismo que me ha ayudado muchísimo a mejorarlo. La primera vez que contactó conmigo me envió una relación de funciones que le faltaban a mi programa para estar a la altura de otros que ella conocía. A partir de ahi fui añadiendo opciones al programa y la verdad es que el programa sería muy pobre si no hubiera sido por ella. Así que tienes que llevar mucho cuidado en no soltar un *NO* cuando te piden algo para un programa y lo que debes hacer es tirar de la lengua a quien te lo pide. ¿ Porque se necesita esa funcionalidad ? ¿ En que mejora el programa ?

Muchas veces los desarrolladores no comemos nuestra propia comida para perros y eso se nota. Llega un correo de alguien interesandose por tu programa y la respuesta es *NO*. Ahi es cuando se tienen que encender las bombillas rojas. Acabas de perder la oportunidad de mejorar tu software.