Por qué encontramos bugs en versiones estables

Asterisk es uno de los proyectos software orientados a comunicaciones más grandes que existen actualmente, por este motivo, es uno de los proyectos en los que la comunidad tiene más importancia de la que normalmente suele tener en estos proyectos dirigidos por empresas en los que se «inyecta» dinero para pagar a desarrolladores con objeto de continuar el desarrollo y solucionar los distintos fallos que se van encontrando continuamente. Cualquiera que haya estudiado programación, recordará que un programador puede, mediante un diseño estructurado, y una buena planificación, técnica y pruebas, evitar la aparición de bugs, pero jamás se puede garantizar la «no existencia» de estos, por lo que una vez entregado el proyecto, es común que los usuarios continúen aportando su «granito de arena» ofreciendo el famoso «feedback» consistente en comentarios acerca del buen o mal funcionamiento de las características de una aplicación software.

Asterisk, como gran proyecto formado por cientos de archivos, módulos, librerías y un largo etcétera, necesita continuamente el «feedback» de sus usuarios con el objeto de identificar tan pronto como sea posible cualquier comportamiento anómalo, no contemplado y perjudicial para la mayoría de los usuarios, por lo que se pone a disposición de todo el mundo, diferentes versiones -inicialmente inestables- de forma que los usuarios puedan probar dicha versión antes de que se convierta en una versión considerada como estable, pero ¿porqué si existen métodos de detección de errores antes de publicar una versión estable, encontramos bugs en estas últimas?

Existe unas versiones conocidas como «team«: http://svn.digium.com/svn/asterisk/team/ en las que los desarrolladores ponen a disposición de los usuarios versiones de Asterisk con nuevas características que estos han solicitado o que el desarrollador quiere implementar en Asterisk. De esta forma, lo que se busca es que los usuarios interesados en estas características, descarguen, prueben y verifiquen junto con el desarrollador que el funcionamiento de las nuevas características son correctas y lo más estable posible (considerando que los usuarios interesados son minoría).

Una vez verificado el funcionamiento de la nueva característica, los cambios que la conforman, son aplicados a una versión «inestable» llamada «Trunk«: http://svn.digium.com/svn/asterisk/trunk/. Esta versión es considerada la «versión de la comunidad» ya que si alguien quiere aportar su grano de arena en la evolución de Asterisk, esta es la versión que puede utilizar para la caza de bugs de forma que cualquier usuario que pruebe la versión Trunk y descubra un bug, debería informar sobre él (y sobre todo, cómo ha conseguido reproducirlo) en la web https://issues.asterisk.org/. De esta forma, y tras solucionar los bugs de la versión «trunk», la versión «estable» (branch) ya no incluirá los bugs más fáciles de reproducir.

Ahora bien, a modo de autocrítica, comentar que el 90% de los usuarios de Asterisk jamás han instalado la versión Trunk, el 99% de los usuarios jamás han informado de un bug en la web https://issues.asterisk.org/ pero eso sí, cuando han encontrado un bug, la gran mayoría preguntan en foros, listas y webs para buscar una solución rápidamente ya que la detección ocurre cuando han realizado una instalación a un cliente y este empieza a enfadarse, lo que nos lleva a varias conclusiones:

1.- La mayoría de los usuarios de Asterisk únicamente les interesa el producto (ad hoc) y no tienen interés en colaborar instalando versiones «inestables» y reportando los bugs que se detectan. Es decir: lo mismo les daría utilizar Asterisk, un sistema propietario, comercial o incluso una solución franquiciada tipo centralita-de-toda-la-vida, mientras eso agrade al cliente y sea rentable económicamente.

2.- Una gran cantidad de supuestos profesionales, no prueban las necesidades del cliente ANTES, y por lo tanto se encuentran con los bugs cuando están en medio de la implementación (lo que se conoce coloquialmente como ‘en casa del cliente’). Esto puede ser tanto porque no se conocen bien las necesidades del cliente hasta el último momento (lo que implica una mala gestión) o bien porque el cliente cambia sus necesidades en el último momento (lo que implica un fallo en la parte de consultoría).

3.- Otro motivo puede ser la imposibilidad de hacer pruebas, bien porque el usuario de Asterisk no disponga en sus instalaciones de los recursos necesarios para estas pruebas (un simulador de líneas), tiempo suficiente o los conocimientos necesarios para simular la instalación en local ANTES de comenzar la implementación en el usuario final.

4.- Por último (y quizá este sea el  motivo más común) es que se peca de exceso de confianza, considerando que una versión «estable» ya ha sido probada por suficiente gente y por lo tanto, se puede ahorrar el hecho de revisar si todo funciona como debería ya que –«¿porqué va a fallar algo que ha estado funcionando perfectamente en todas las versiones anteriores?»– Una mezcla entre confianza ciega, despreocupación y cierto grado de vagueza que provoca que en el último momento, cuando el «cliente final» haga de betatester involuntario de la versión estable que le han instalado y configurado, descubra con una gran sorpresa que aquello que le dijeron que funcionaba, no lo hace como esperaba. Está claro que si esta es la razón del porqué existen bugs en las versiones «estables», no es culpa de los desarrolladores, si no de varios motivos, empezando por aquellos usuarios que no han probado la versión Trunk lo suficiente, continuando por el usuario que instala el Asterisk y que no ha verificado que todo funcionaba correctamente y por último del cliente final por haber seleccionado a una empresa que no es todo lo responsable que debería.

Por estos motivos, y como siempre se suele decir: más vale prevenir que curar, se podrían dar varios consejos para evitar situaciones embarazosas a la vez que se colabora en la estabilidad del proyecto Asterisk:

• – Intentar obtener todos los datos posibles sobre las necesidades del cliente, configuraciones completas, terminales, funcionamiento estandar del sistema y elaborar una lista completa de «pruebas» de calidad que la solución deberá pasar antes de iniciar la implementación sin «obviar» ninguna características por muy probada que esté y muy común que esta sea. (por ejemplo: no es la primera vez que aparece una versión de Asterisk donde no funciona el Pickup y se detecta demasiado tarde por no haber hecho una simple prueba de 10 segundos).
• – Intentar formarse tanto técnica como comercialmente para conocer lo que se ofrece, conocer las limitaciones y las ventajas frente al resto de sistemas para evitar ofertar lo que no se sabe hacer y hacer el ridículo cuando el cliente vea cómo preguntan en las listas acerca de algo que en la página web de la empresa se dice que se domina perfectamente.
• – Intentar simular tan exactamente como sea posible toda la instalación de forma escalada (no hace falta desplegar 500 terminales SIP) pero sí probar todas las características de cada modelo de terminal y verificar la versión de firmware que cumple con todas las características que promete el fabricante.
• – Cuando se detecte un error en Asterisk, lo primero que hay que hacer es preguntar en las listas de usuarios (asterisk-users y Asterisk-ES) por si es un fallo de configuración  o bien es un verdadero «bug» de Asterisk, en cuyo caso debemos informar de este en https://issues.asterisk.org/, por lo que deberíamos analizar los pasos que hemos realizado y que nos ha producido ese error, de forma que los desarrolladores puedan reproducirlo y descubrir dónde está el error. En caso de que sea realmente un bug, serás recompensado como colaborador bug-hunter de la próxima versión estable. Por este motivo siempre es recomendable cazar los bugs en la versión «trunk»… para evitar que lleguen a la versión «estable».

Así que la próxima vez que veas a alguien quejarse de que la versión estable tiene algún bug, párate a pensar por un momento la cantidad de personas que han descargado la versión anterior Trunk, y no lo han detectado, seguramente te de una idea de la cantidad de personas que, aun utilizando Asterisk, aprovechándose del trabajo de cientos de desarrolladores que dedican horas de forma totalmente desinteresada a este proyecto, realmente contribuyen a su desarrollo.

En una conversación en un grupo de usuarios de linux hubo una frase que me llamó la atención:

-«En el mundo del software libre, hay dos tipos de empresas: las que contribuyen de una forma u otra en el desarrollo del software libre, y las que únicamente les interesa la gratuidad del producto intentando conseguir todo el jugo posible del esfuerzo de los demás, pero que cuando les toca a ellos desarrollar algo, lo hacen como software privativo para que nadie más pueda usarlo.«