responsabilidad civil en fallos informáticos

La semana pasada se publicó en Ciberpaís una noticia referida a la [Enlace bloqueado por la Tasa española AEDE]. Todos los aspectos relacionados con el ejercicio de una profesión suelen ser vistos desde un punto de vista totalmente subjetivo ya que cada uno cuenta de la fiesta como le va en ella, pero creo que sería bueno para la profesión en su conjunto que los proyectos informáticos estuvieran sujetos a responsabilidad civil, y que los distintos colectivos que integramos la profesión nos organizaramos para defender todos nuestros intereses, ofreciendo una imagen de profesión madura ante la sociedad.

más sobre descargas y sobre Google

Llevo una temporada sin postear en el blog por varias razones. Una es porque el trabajo de día me absorbe ahora más dedicación y me queda menos tiempo para mi verdadera pasión, que no es otra que alanit. Otra es que me comprometí a hacer una web para unos amigos y estoy de pruebas de diseños y demás. Y la tercera es que Fátima no me deja tocar el ordenador cuando está conmigo y quiere que juege con ella, y ya se sabe quien manda en una casa donde hay un niño.

En un anterior post comentaba que estabamos aumentando significativamente el número de descargas de ediciones gratuitas de los programas. Ahora puedo decir que con la perspectiva de tres meses desde la puesta en circulación de las ediciones gratuitas el incremento de descargas es realmente importante, de tal manera que casi se puede decir que hemos multiplicado por 10 el número de descargas de los programas desde noviembre, que fue el último mes antes de poner en marcha las ediciones gratuitas. Los registros han crecido pero ni mucho menos en esta magnitud, que más quisieramos nosotros, pero si se nota más movimiento y mayores ingresos pese a la bajada de precios de los programas.

Pasando a otro tema, el pasado fin de semana encontré en el kiosko una revista que me llamó mucho la atención. Es un número dedicado a Google de la revista Pc Cuadernos. La he empezado a leer y me está gustando bastante, creo que cuenta bastantes cosas interesantes sobre la optimización de un sitio web para Google y que le voy a sacar bastante partido. El contenido de la revista se puede consultar aqui y creo que es una compra para cualquiera que mantenga su propio sitio web.

mymicroisv y la teoría de la larga cola

Hace pocos dias se ha puesto en marcha mymicroisv – el nuevo blog del autor del libro ‘Micro-ISV: From Vision to Reality‘. El sitio está muy bien, pues además de artículos de Bob Walsh tiene más cosas como artículos, entrevistas y ficheros de plantillas que comenta en el libro. No deja de sorprenderme la capacidad de los norteamericanos para exprimir hasta la última gota de cualquier cosa y la de vueltas que le dan a cualquier cosa.

En un post de este blog se refiere a la teoría de la larga cola, que aplicado al software viene a decir que el posible mercado de miro-isv es mayor que el de las grandes corporaciones de software. Una explicación de esta teoría se puede leen en castellano en véase además, aunque el comentario sobre ‘ascenso de los mediocres‘ creo que es bastante desafortunado. En merodeando también se comenta esta teoría, incidiendo en la existencia de micronichos de mercado.

sobre descargas y registros

Pasadas ya las fiestas, y de vuelta al trabajo es hora también de retomar el blog. El propósito para este año es dar el salto con los programas al mercado de lengua inglesa para ver si ahi tenemos un hueco. Esto, junto con la promoción de los programas, va a ser lo prioritario de este año. Durante el año anterior hemos incrementado notablemente el número de descargas de ediciones de evaluación de los programas, pero sin embargo el número de registros mensuales se ha mantenido practicamente constante.

¿?

Uno de los principios de la venta de productos por internet – y el software es un producto – es que hay una relación entre las visitas de la web y las ventas de este producto. A más visitas más ventas. En nuestro caso hay factores perturbadores, pues muchas descargas se producen desde sitios externos a nuestra web como portales de descargas, pero lo que es incuestionable es que a mayor número de descargas hay un mayor número de potenciales usuarios. Sin embargo no hay más usuarios que registren el programa. Quizás sea pronto para sacar conclusiones y a medio plazo haya un mayor número de registros debido al incremento de descargas, pero de momento la cosa no está funcionando como esperabamos. También es posible que las ediciones gratuitas vayan a restarnos registros pues haya muchos posibles usuarios que con esta edición vean cumplidas sus expectativas y decidan no pagar por la edición registrada.

El tiempo irá desvelando todo esto.

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.

Como ser un micro-isv

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.

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.

crisis, pero no tanto

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.

corrigiendo errores III

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.

corrigiendo errores II

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.

corrigiendo errores I

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.