Su consulta no nos molesta

Antes de que lean esta entrada tengo que hacer una aclaración: en un proyecto de software libre, los usuarios son uno de los recursos más valiosos, no solo lo digo yo, lo deja muy claro Eric Raymond en "La Catedral y el Bazar" (no dejen de leer ese ensayo). En particular, en mis proyectos, donde no hay un gran equipo trabajando en el testing, el diseño, la documentación, etc. como sí puede suceder en una gran empresa, o en una fundación con más recursos, el feedback de los usuarios es vital, y por eso hay que cuidarlos, y no atacarlos como voy a hacer a continuación.

Creo que el problema se debe en gran medida a que el usuario medio, por decirlo de alguna manera, está acostumbrado a utilizar software privativo (pensando en enlatados de uso diario, no en desarrollos a medida para una empresa), y esto le ha generado muy malos hábitos, al menos desde la perspectiva de un desarrollador de software libre. Más allá de mis alegatos a favor del software libre, no soy un extremista, y sé que hay software privativo de muy buena calidad, que hay empresas serias y desarrolladores muy capaces en ellas; pero la forma en que se trabaja de un lado y del otro es muy diferente, y los usuarios, en consecuencia, también lo son.

Es común que un proyecto de software privativo libere versiones estables, acabadas, bien testeadas y pulidas en los detalles como mucho una vez al año. Así vemos versiones como 3.0, o 2012, bien definidas. En algunos proyectos de software libre esto también ocurre, pero en la mayoría no es así. En la mayoría, se liberan decenas de versiones en un año, a veces hasta más de una en un mismo día. A mí me pasa frecuentemente. Cuando tengo una funcionalidad nueva implementada, no veo la hora de hacerla publica, porque cada nueva funcionalidad le suma valor al proyecto, y ¿si de casualidad un usuario lo descarga sin ella y justo la necesitaba?, tal vez lo pierda innecesariamente (sí, suena un poco paranoico). De igual forma, cuando hay un error importante, necesito corregirlo y subir de inmediato la nueva versión, para que los potenciales usuarios no piensen que es un software mal hecho, o de muy baja calidad y también se pierdan. Es como que una buena funcionalidad mejora la imágen que el usuario se puede hacer del proyecto, y un bug grosero la daña, a veces irreversiblemente. Y una cosa lleva a la otra, si libero rápido una nueva funcionalidad, puede que no haya tenido tiempo de notar algún error importante. Pero el punto es que de la misma forma en que me siento orgulloso de agregar funcionalidades, me da vergüenza ver errores gruesos en las versiones publicadas, entonces publico versiones bastante seguido.

Cuando un usuario se queja de un error, lo primero que pregunto es "¿qué versión tenés?". Las respuestas válidas serían: "la de ayer", "la de la semana pasada", "la del 15 de febrero", "la 20111031 para linux de 64bits"; pero las respuestas que obtengo a veces son del tipo de: "la del 2011". ¡¿¡Qué!?! ¿Cómo? ¡Pero si publiqué quichicientas versiones en el 2011! ¿Cómo que la del 2011?. Esto me pone verde, pero el usuario está acostumbrado a la dinámica del software comercial, y no se imagina que tal vez la semana pasada alguien reportó ese problema y lo corrigieron enseguida, que lo subieron en un par de días sin tantas vueltas, que no hicieron una ceremonia de presentación para anunciar la nueva super versión, que ni siquiera cambió el splash. Así que sépanlo, me gusta que estén actualizados, al menos antes de reportar un error, y sepan que no duran mucho tiempo actualizados, que en el software libre se pueden acortar los tiempos gracias a la ayuda de sus buenos usuarios, y que el desarrollo puede ser lento algunas veces y vertiginoso y desorganizado otras, pero avanza, siempre avanza.

El otro punto que quería remarcar, retomando la idea de la distancia entre usuario y desarrollador, es lo mal acostumbrados que están algunos usuarios que aceptan errores groseros, enormes, garrafales, sin chistar. A veces un alumno viene con su notebook a consulta y resulta que en su Windows por algún bug mio o de alguno de los programas que uso, no le anda una funcionalidad clave. O luego de intercambiar varios mails me entero de que tenía un problema enorme por el que nunca preguntó. Por dar unos ejemplos, supongamos que la última versión de PSeInt ni siquiera arranca, entonces usan la anterior; o que ZinjaI ignora los puntos de interrupción al depurar, algo que me pasó hace muy poco con una actualización de gdb. ¿Cómo puede alguien vivir con eso? ¿Cómo es que no agarró un bidón de combustible y vino a quemar la oficina? ¿Por qué no recibí amenazas y maldiciones? ¿Acaso es algo para dejar pasar? Y sí, parece que sí. Es inimaginable con muchos softwares privativos que un completo desconocido vaya a quejarse ante la gran empresa desarrolladora de que en una máquina no anda. Parece que nadie le va a dar bolilla, menos aún si es una copia pirata como suele pasar. Y suponiendo que no lo sea, tal vez hasta tendremos que esperar a la próxima versión, casi un año, para que aparezca corregido, y volver a pagar una licencia. Entonces el usuario se vuelve tolerante, se acostumbra a ciertos errores, convive con ellos, y a veces hasta es feliz igual. ¡Con el software libre esto no debe ser así! Recibir un buen reporte de error es de lo mejor que nos puede pasar, los desarrolladores de software libre nos ponemos contentos si vemos que el usuario se interesa en el proyecto, que ayuda a identificar los problemas, que le ahorra la molestia al próximo usuario que pueda tener el mismo problema, y sobre todo que tiene esperanzas de que atendamos su queja y de que nuestro proyecto mejore. A veces, por falta de tiempo, tardamos en responder; a veces, lo que es prioridad para uno no lo es para otro; pero siempre leemos las quejas, siempre intentamos mejorar el proyecto, y este feedback es clave para ello.

Creo que muchos desarrolladores del mundo del software libre comparten mi visión. Después de todo, nuestros proyectos están ahí colgados, para que todo el mundo los pueda ver. Para que disfruten con lo bien andan, o para que critiquen lo horrible que explotan. Preferimos lo primero, y para eso necesitamos usuarios activos, usuarios que confíen en que sus quejas o sugerencias son escuchadas, que se sientan con derecho a participar. No tomen un bug terrible como algo normal; no les podemos devolver su dinero, pero podemos intentar mejorar. Guarden la tolerancia para el mundo real y la paciencia para cuando manejan su auto, que tanta falta hacen, pero para el software, háganse escuchar, que lo necesitamos. Algunas veces habrá que aceptar los errores, otras sólo será cuestión de esperar unos días y bajar la última versión. Eso sí, siempre con respeto y buena onda, que del otro lado hacemos lo mejor que podemos, pero también tenemos nuestras limitaciones.