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í 😉

Anuncios

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.

xHarbour Coding Guidelines

Una de las perlas que se puede encontrar en el sitio de xHarbour.com son estas Coding Guidelines. No es que sea una gran novedad, pero la verdad es que ayuda a poner un poco de orden en el código. Las lineas maestras son las siguientes:

  • los comandos y funciones del compilador en minúsculas
  • los nombres de alias y de campos en mayúsculas
  • reemplazar tabuladores por 3 espacios en blanco
  • cadenas que se vayan a i18n entre comillas dobles, el resto en comillas simples

Estoy comenzando a usar estas guidelines y el código queda bastante claro, además escribo con mayúsculas las sentencias de FWH referidas a la GUI lo que me permite diferenciar claramente lo que hago en cada momento.

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.

dadamail

Uno de los mayores dolores de cabeza de la web de alanit era la lista de correo. Quería instalar un gestor de listas de correo que llevase la gestión de la lista en modo desatendido, de manera que los propios usuarios gestionasen las altas y bajas de la misma. Estuve mirando por la web y encontré un par de aplicaciones que tenían buena pinta. La primera que elegimos no hubo manera de instalarla, torpe que soy, así que nos quedamos con la segunda opción, que era dadamail.

Dadamail es sencillo de instalar y configurar. Puedes crear varias listas de correo y se pueden personalizar los formularios de alta y baja de la lista, así como los correos de confirmación y todo lo que se utiliza para la gestión de la lista. La personalización de la lista de correo la ha hecho Jaime y la integración con la web la ha hecho fenomenal.

20051008.jpg