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.

Saltar al contenido del PDF

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.

tooltips de balón en FWH

Muchas veces la diferencia entre un programa y un buen programa está en los detalles. Por eso, un programador debe visitar con asiduidad los foros del lenguaje o herramienta de desarrollo que utiliza y estar al tanto de cualquier comentario que se pueda hacer sobre el mismo.

Hace un par de semanas en el foro de FWH Antonio Linares publicó la manera de cambiar los tradicionales tooltips cuadrados por unos de tipo balón. Los cuadrados son estos:

Para conseguir los tooltips de balón lo único que hay que hacer es ir al código fuente de la clase Window y quitar un comentario que aparece en la linea 2762 – o simplemente buscar ballon en el prg -. Hay que dejar la llamada a CreateTooltip con el último paráametro a .t.

hWnd = CreateToolTip( Self:hWnd, cToolTip, .t. ) // for ballon tooltips !

Luego se recompila la librería y nuestro programa. Ya tenemos tooltips de balón 😉

septiembre, el primer mes de curso

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:

usando TDbf

Hasta hace poco nunca había usado nada para manejar DBF que no fueran los comandos y funciones estándar de clipper y luego de xHarbour. Hace unas semanas comencé el desarrollo de una aplicación que tiene que ejecutarse en red y me planteé mirar las distintas clases para manejo de DBF que existen para xHarbour.

Haciendo caso de mi amigo Manolo y de algún otro consejo recibido via messenger me decidí a probar TDbf de Manu Expósito. Me bajé la clase desde su grupo de Yahoo y me puse a probarla. El ahorro de código que se produce al usar esta jerarquía de clases – como a Manu le gusta llamarla – es realmente impresionante. La clase crea automáticamente una data para cada campo del fichero que se manipula, con lo cual no tienes que definir campos ni hacer asignaciones. Además la clase maneja un buffer que es el que contiene estas datas, de manera que puedes cargar el buffer desde tu dbf y guardar los datos con una llamada a un método de la clase. Un mantenimiento básico usando TDbf sigue esta estructura:

IF NUEVO_REGISTRO
   oDbf:Blank() // pongo en blanco el buffer
ELSEIF MODIFICACION
   oDbf:Load() // cargo el buffer desde la dbf
ENDIF

DEFINE DIALOG oDlg RESOURCE "EDIT" OF oParent

REDEFINE GET aGet[1] VAR oDbf:TaCodigo  ;
   ID 12 OF oDlg UPDATE           		;
   PICTURE "@!"                        ;
   VALID Clave( aGet[1], nMode )
...
ACTIVATE DIALOG oDlg	;
   ON INIT DlgCenter(oDlg,oApp():oWndMain)</p>

IF oDlg:nresult == IDOK
   lReturn := .t.
   IF NUEVO_REGISTRO
      oDbf:Insert()
   ELSEIF MODIFICACION
      oDBF:Save()
   ENDIF
ENDIF

Además, Manu está preparando una TDbf Pro para antes de que acabe el año y que estará escrita en gran parte el C, con lo cual irá mucho más rápida que la actual clase. Ganas tengo de verla.

alanit
Resumen de privacidad

Esta web utiliza cookies para que podamos ofrecerte la mejor experiencia de usuario posible. La información de las cookies se almacena en tu navegador y realiza funciones tales como reconocerte cuando vuelves a nuestra web o ayudar a nuestro equipo a comprender qué secciones de la web encuentras más interesantes y útiles.