En el día de hoy, en el blog oficial del Visor Firestorm, Jessica Lyon, Project Manager de The Phoenix Firestorm Project, publicó un post informando sobre el estado de avance de la próxima versión de dicho visor y qué nuevas características tendrá o no incorporadas.
Luego de aprovechar el post para criticar a los desarrolladores de otros visores (Sin nombrarlos específicamente) por tener incorporadas características lanzadas por Linden Lab en sus distintos Project Viewers y que no están disponibles en Firestorm, a la par de explicar porqué dichas características no están disponibles en su visor y alabar las bondades de su gestión al frente del equipo de desarrollo, solo queda en claro que de todas las características disponibles en la actualidad (HTTP Pipeline, AISV3, Ban Groups, SL Shared 2) seguramente no estarán disponibles en la próxima versión del visor, ya que las consideran defectuosas y es mejor esperar que Linden Lab las corrija antes de ellos mergearas con el código actual.
Hasta aquí, puede parecer razonable lo dicho por Jessica Lyon, pero, en mi humilde opinión solo manifiesta la imposibilidad del equipo de arriesgar a incorporar características y afrontar las consecuencias para, a medida que van surgiendo los problemas, ir lanzando las correspondientes versiones corregidas.
Esto es, por algo existen las versiones estables para aquellos usuarios que no quieren tener problemas y las versiones Alpha o Beta para quienes gustan de probar todo lo nuevo asumiendo el riesgo y sus consecuencias. Algo que, escudados en la excusa de la «calidad» el proyecto Firestorm no hace.
Por ende, me permito aquí analizar detenidamente algunos párrafos de lo expresado por Jessica:
This is where I set targets for things that should be fixed and determine what features and functionality make it into the release and what doesn’t, when I have to say yes to some things and no to others based on recommendations from folks on the team, suggestions from users and gut feelings, often disappointing some while pleasing others among the support team, QA and developers.
Aquí es donde me puse metas para las cosas que deben arreglarse y determinar qué características y funcionalidades añadir en el lanzamiento y cuales no, cuando tengo que decir que sí a algunas cosas y no a otras, sobre la base de las recomendaciones de la gente del equipo, las sugerencias de los usuarios y los sentimientos viscerales, a menudo decepcionando a algunoso agradando a otros, entre el equipo de apoyo, control de calidad y los desarrolladores.
Me pregunto que ha cambiado en esta Jessica que, cuando nació el visor Phoenix, defendía a capa y espada que debía trabajarse en democracia y votar por cada cosa que debía o no hacerse (discusión que le costó al equipo la baja de, quizás, dos de sus mejores y mas experimentados desarrolladores) y hoy debe (y quiere) cumplir el rol de ser la voz definitiva en la toma de decisiones (tal como lo planteaba uno de los desarrolladores que renunció luego de dicha discusión).
Firestorm is not, and has never been, a “bleeding-edge” viewer. We have always focused on quality over quantity, stability over shiny. Slow and steady wins the day. Despite complaints and objections, this strategy has helped make Firestorm the most widely used viewer in Second Life by a long shot. In code, almost anything new has bugs and kinks that need to be worked out regardless of who wrote it and how vigilant they were at it. That’s because despite how much testing you do, it isn’t until it lands in the hands of the many that the deepest rooted software glitches start to crop up. Knowing this is one of the reasons we do not merge in and release new features from Linden Lab right away.
Firestorm no es, y nunca ha sido, un visor «de avanzada». Siempre nos hemos centrado en la calidad sobre la cantidad, la estabilidad por sobre lo lindo. Lento y constante se gana el día. A pesar de las quejas y objeciones, esta estrategia ha ayudado a hacer de Firestorm el visor más utilizado en Second Life por mucho tiempo. En el código, casi cualquier cosa nueva tiene errores y fallos que necesitan ser resueltos independientemente de quién lo escribió y cuanto haya lo haya revisado. Eso es porque a pesar de la cantidad de pruebas que hagas, no es sino hasta que llega a manos de la masa de usuarios que las ráices de los profundos fallos del software comienzan a surgir. Sabiendo esto es una de las razones por las que no se fusionan y liberan las nuevas características de Linden Lab de inmediato.
Bien, aquí hay varias cosa para comentar. Durante mucho tiempo, el caballito de batalla de Firestorm, al igual que sus predecesores (Phoenix y Emerald) era, precisamente, la cantidad de características «de avanzada» que tiene por sobre el resto de los visores, especialmente por sobre el visor oficial. Ahora resulta, que del día a la mañana Firestorm NO es un visor de avanzada. Cómo cambian las cosas.
Ahora, ¿estabilidad sobre lo lindo?. Para muchos usuarios Firestorm es totalmente inestable para otros un relojito de estabilidad (me incluyo en este último grupo) pero, seamos honestos, Firestorm dedica mucho tiempo a lo «lindo» y no tanto a lo funcional. Como muestra alcanza con ver que de los mas de 300Mb en Linux que pesa (el resto de los visores andan por los 150Mb) el grueso son archivos de Skines para el visor.
Luego, que esta estrategia de lanzar una versión a cada muerte de obispo sea la causa del éxito del visor es algo que me permito discutir. Firestorm es el visor mas utilizado solamente porqué heredó el prestigio y la base de usuarios de Phoenix, el que a su vez, heredó lo mismo del visor Emerald. No es una cuestión de estrategia, sino de costumbre y gustos. Ya siendo usuario de Emerald y de Phoenix he podido ver sus fallos y errores, asi como sus bondades y habiendo sido defensor de los mismos siempre he sostenido que no eran los mejores ni los mas novedosos (por caso,el visor que SI fue novedoso fue Dale’s SL Viewer) . Solo fueron los mas populares sencillamente porque reunían todas las herramientas dispersas entre el resto de los visores y le sumaban algunas propias y novedosas, aunque rebuscadas en su implementación. Pero de ahí a decir que la estrategia de lanzar una versión estable cada 3 o 4 meses (quedando muy regazado hasta del visor oficial) es la causa de su éxito, me parece un desacierto total.
Los párrafos finales son dignos de análisis, porque el reconocimiento de que, por mas pruebas y controles de calidad que se hagan, recién cuando el software llega a manos del usuario comienzan a descubrirse sus problemas (esto es una gran verdad que se aplica a todo el software en general) choca contra el discurso previo (el éxito de la lentitud para evitar fallos). Firestorm, por mas que disponga de un equipo faraónico de desarrolladores y soportistas y beta testers, cuando libera una versión «estable» no está exento de fallos ni bugs, por el contrario, éstos comienzan a florecer como las plantas en primavera.
The point is this: just because another third party viewer or even LL has released something does not mean it will pass our quality standards.
El punto es éste: sólo porque otro visor de terceros o, incluso, el propio de LL, hayan lanzado algo nuevo no quiere decir que esto nuevo va a pasar con nuestros estándares de calidad.
Bien, a ver… no estoy seguro que me queda claro…. La gente del equipo Firestorm rechaza indefectiblemente toda crítica con el latiguillo «hacemos esto sin ver un peso, si no te gusta, podés usar otro visor». Entonces, si es todo a pulmón (aunque hayan comprado y pagado licencias para poder utilizar en el visor librerías propietarias de terceros) y nadie ve un peso, ¿es necesario tanto discurso empresarial? Digo, es un hobby, nadie cobra por ello (ningún desarrollador de ningún visor de terceros), lo hacen porque les gusta, entonces, sincenramente, no me cierra el discurso de ser una Entidad Sin Fines de Lucro registrada legalmente, con página en Linkedin y plantilla de unos 51 a 200 empleados y sujeta a estrictos controles de calidad, en todo caso, eso debería quedar en manos de Linden Lab que es la empresa que busca beneficios. ¿Soy claro?
Me parece que es mas sencillo que eso, se hace lo que se sabe hacer y se puede hacer, nadie va a ser ajusticiado por ello. Si a pesar de tamaño equipo y recursos, la gente de Firestorm no puede hacer algo mejor que lo que ya hace (que no es poco), me parece que no necesitan escudarse detrás de frases indirectas y agresivas como «no hacemos lo que hacen otro porque lo hacen mal» o «lo hicimos antes que los demás» o «somos mas serios que el resto». Todo esto suena a excusas y, hasta, a revanchismo e impotencia de alguien que está un poco cegado por el lugar que ocupa sin darse cuenta que todo en la vida es efímero y hay que saber ocupar el lugar que uno ocupa en un momento circunstancial de la vida.
Habiendo formado parte del equipo Firestorm, se que mientras los usuarios se lo pasan esperando 3 meses para ver una nueva versión, sin siquiera la posibilidad de probar alguna beta o alpha, los miembros del equipo utilizan cotidianamente versiones «internas» de prueba con un nivel de estabilidad casi similar a la versión estable y, muchas veces, con menos problemas que la que, luego, será lanzada como versión estable. Es algo que siempre me llamó la atención porque, guste o no (y yo también he caído en la trampa), uno, como soportista se encuentra utilizando una versión nueva, con fallos corregidos, fallos que no ve que le pasen a la hora de entender cual es el problema que afrontan el resto de los usuarios. No es fácil ayudar a alguien con un problema que uno desconoce porque no usa la misma versión que el resto.
El equipo Firestorm, tiempo atrás tomó una decisión (ya hablé sobre ello) y tiene que pagar un precio por eso (para bien o para mal) creo que lo mas digno es, si creen que ha sido la decisión correcta, hacerse cargo de la misma y sus consecuencias y no buscar excusas ni culpables en otro lado.
Firestorm es el visor popular, de eso no hay duda, no puede ser que Jessica Lyon nos diga que, ante la necesidad de muchos usuarios de contar con la característica de Group Ban, «usen el visor de Linden Lab como hacemos nosotros cuando lo necesitamos», sencillamente no habla bien de como encaran el tema. Crear, desarrollar, mantener y dar soporte a una pieza de software implica sus riesgos, es trabajoso, hay problemas, bugs, fallos, quejas, pedidos de ayuda y soporte. Si un software específico, con una amplia plataforma de usuarios hace que sus usuarios requieran ayuda para solucionar sus problemas en forma constante, algo no está bien. Sin embargo, hablamos de un equipo que cuenta con varios grupos de ayuda en distintos idiomas, con varios Soportistas por idioma, no debería ser una tarea tan ardua. No obstante ello, se vive buscando la forma de evitar que el usuario se queje, pida ayuda, etc. limitando las posibilidades para ello (eliminando versiones viejas, no lanzado versiones beta o alpha, etc.).
En definitiva, en lo personal me hubiera gustado que dijeran que iban a lanzar una versión Beta en forma, digamos, semanal o cada 10 días (como hace henri Beauchamps, por ejemplo) y con ello y la ayuda del usuario final, ir corrigiendo en la proóxima beta cada error que aparezca. A mi juicio, esa sería la forma de avanzar por un buen camino. Lo hacen otros desarrolladores, otros visores, con equipos unipersonales o de 4 o 5 miembros y no tienen problemas con ello, al contrario, si un usuario de la beta 1 pregunta por un problema específico, se le puede sugerir que actualice a la beta 2 que ya ha corregido ese fallo. Y, luego, como hacen ahora, seguir manteniendo un lapso de 3 meses entre versiones estables. Equipo de desarrolladores para soportar esta estrategia tienen de sobra. ¿O quizas no?
SaludOS/2