Originalmente, cuando comencé a recabar información para este artículo, tenía la intención de que fuera (valga la redundancia) «informativo» respecto del estado en que se encuentra cada uno de los distintos visores para Second Life (y Opensim). Pero, a medida que la información se iba acumulando en mi disco y mi mente, la forma en que ésta comenzó a golpear mi cerebro hizo que termine definiendo que este artículo sea más de opinión que informativo. En fin, cosas de las vidas, ya me parezco Linden Lab que propone una cosa y termina haciendo otra.
Estando a teóricos días de la puesta en marcha del proyecto SSB (Server Side Baking) es interesante notar que aún no hay noticias de cuando, definitivamente, Linden Lab comenzará los rollings restart de regiones para su implementación. Tampoco hay muchas noticias sobre el estado de desarrollo del SSB en los distintos visores que, a hoy, siguen siendo mantenidos por sus desarrolladores.
Todo indica que las cosas no están saliendo bien ni resultando sencillas (para casi nadie), especialmente, para Linden Lab, que, consecuencia (directa e indirecta) de su política errática (a mi juicio y el de varios) embarra constantemente la cancha de los desarrollos en el código del visor y provoca retrasos, problemas y quejas de parte de los desarrolladores de visores de terceros. Quejas directas e indirectas.
Por lo pronto, además de la falta de información sobre cuando se comenzará la migración por parte de la empresa, hace unos días quien se desempeña como Project Manager de «The Phoenix Firestorm Project, Inc» realizó, junto a miembros del equipo de desarrollo y soporte del visor Firestorm, una reunión pública en la cual se iba a conversar sobre cualquier tema y/o consulta que hicieran los usuarios. No obstante, el tema predominante fue el futuro a corto plazo del visor Firestorm, con un mensaje por parte de Jessica Lyon iniciado con una frase interesante, algo tipo «tengo una mala y una buena noticia» (no me digan que cuando alguien les dice eso, no se ponen a temblar). Por el lado de la mala noticia, ésta fue que está (casi) todo saliendo mal y no saben por donde empezar para lograr una nueva versión del visor que sea estable y ni hablar de incorporar el código del SSB porque las estrellas se empiezan a caer. Reconozco que no fue tan apocalíptico como lo dijo, pero quedó esa sensación. Por el lado de la buena noticia, ésta fue que, a pesar de todo, seguirán adelante.
Esto es, a partir de ahora (10 días atrás) la prioridad del equipo de desarrollo de Firestorm es conseguir que el código SSB funcione en el visor y éste sea estable, cosa que reconocen no les será tan fácil. Luego, habiendo logrado este cometido, comenzarán a dedicarse a la parte buena, agregar funcionalidades al visor y no morir en el intento. Paralelamente a esto, Firestorm sigue su camino de tener un equipo dedicado a dos visores: la versión para Second Life y la versión para OpenSim, versiones que, con las movidas que está haciendo Linden Lab, cada día serán mas distintas y distantes. Además, siguen trabajando en hacer backports (por presión o «pedido» de los usuarios) de elementos de la interface del ya extinto visor Phoenix.
Analizando un poco las cosas, creo, personal y humildemente, que el equipo Firestorm ha cometido algunos errores de apreciación y estrategia. Si bien (y esto lo expliqué en un post anterior), por cómo encararon el backport del V3 a Phoenix, para ellos no resulta(ba) fácil mantenerlo y por ello decidieron discontinuarlo, hoy en día, se ven obligados a mantener dos visores iguales pero distintos (FS_SL y FS_OS) y, para colmo, hacer que Firestorm se parezca a Firestorm, al Visor Oficial y, por sobre todo, a Phoenix. Eso, no hay mucho para pensar, lleva, inexorablemente, a un consumo exagerado de recursos y energías que, a larga, va a terminar de agotar a mas de un desarrollador (y también a mas de un usuario).
Yendo a los demás visores de terceros, salvo los casos de los visores Cool VL y Singularity, que, podemos decir, se encuentran al día en su adaptación al SSB (ambos tienen versiones Alfa/Experimental ampliamente funcionales), el resto de los visores de terceros todavía no ha dado señales de en que estado de desarrollo se encuentran respecto de esto. Esto lleva a especular que, o bien están trabajando tranquilamente en privado o bien aún no han encarado el desarrollo y esperarán a que el código de Linden Lab esté terminado para, a contra reloj, portarlo a sus visores y lanzarlos con premura.
Por el lado de Linden Lab, varios desarrolladores se quejan de los problemas que la propia empresa está causando (a si misma y a los demás) con este desarrollo, toda vez que los servidores de prueba del SSB aparecen plagados de errores y (si bien a Linden Lab es algo que no les interesa, tienen que prestar atención al grueso de usuarios que lo utilizan) el como, increíblemente, el código del SSB ha «roto» varias funcionalidades del RLVa (RestrainedLove, Api de terceros), funcionalidades que están incorporadas en todos los visores de terceros. Por eso, teniendo Linden Lab solamente un promedio del 25% de uso de su propio visor, nos deja un 75% de la masa de usuarios que, potencialmente, harán uso de esta funcionalidad, por ello, si no se corrige este problema, el daño será bastante grave. Obviamente, la respuesta de la empresa al reclamo de los desarrolladores de terceros para contar con una plataforma apta de pruebas es lento y, recién ahora, han accedido a habilitar los scripts en las regiones Beta «SSB compatibles», lo que obliga a trabajar apurados a los desarrolladores.
Ante este panorama, no sorprende la falta de noticias por parte de la empresa respecto de fecha para la implementación del SSB, ya que, obligada a solucionar la catarata de errores en el código de su propio proyecto (tanto a nivel servidor como a nivel visor), se suma el hecho que este problema se traslada (en gran medida, no en toda) a los demás visores y, especialmente, a su visor estrella, el Firestorm, el cual, acapara gran cantidad de usuarios y, con esta movida del SSB, se espera (tanto por parte de Linden Lab como de The Phoenix Firestorm Project, Inc) reciba a gran parte de la masa de usuarios obligados a migrar del visor Phoenix y otros clase V1.
Sin embargo, esta demora provoca lo inevitable, muchos usuarios, ya sea porque son amantes incondicionales del V1 o porque tienen computadoras de prestaciones limitadas, ya han comenzado el proceso de migración pero hacía los visores Cool VL y Singularity. Otros, no tan estrictos en cuanto a sus gustos, y/o con computadores suficientemente potentes, migran hacia visores como Nirans, Dolphin, Kokua y el resto de los compatibles con el V3.
Que algo inquieta o, al menos, hace que la empresa intente expandir su percepción del estado de ánimo de sus usuarios es el hecho que, hace ya casi dos meses, ha comenzado a monitorear y participar (cuando le compete) en las charlas del equipo de desarrollo del visor Singularity, argumentando que ha crecido mucho en base de usuarios y, por lo tanto, deben prestarle mas atención.
Eso no significa que Linden Lab esté buscando una nueva alianza con este visor, pero indica algo claro, el «mercado» de visores ya no se limita solamente al Visor Oficial y Firestorm, sino que el juego se encuentra mucho mas abierto y, a la hora de tomar decisiones que impacten en la masa de usuarios, el resto de los visores deben ser tenidos en cuenta también, algo que no pasaba hasta hace pocos meses atrás.
Igualmente, lo importante de todo esto es que, siendo el visor con mayor cantidad de usuarios, Firestorm, quiera o no, le impone a Linden Lab los tiempos de implementación del SSB (La empresa no implementará algo que deje fuera de SL a mas de la mitad de sus usuarios), Como ya he comentado, al blanquear la situación y reconocer que, (dicho técnicamente) al hacer el merge del código de la versión 3.4.5 del visor Oficial con el código de Firestorm, todo se fue a pique y en las pruebas internas, el ratio de caídas por sesión es alarmante. Por ende, se cae en un círculo vicioso. Firestorm toma el código del visor oficial, lo prueba, falla, lo informa a la empresa y se sienta a esperar que la empresa lo arregle, mientras tanto, otros desarrolladores ya han corregido los fallos e informado a la empresa (que hace caso omiso de las correcciones ofrecidas). La empresa «corrije» los fallos, Firestorm toma el nuevo código, lo prueba y siguen los problemas y se repite el ciclo, con un agravante, los demás desarrolladores, cuando ya tenían todos los fallos corregidos, ahora se enfrentan con nuevos fallos a corregir. Y la rueda sigue su giro…..
¿Qué significa esto? Sólo dos posibles líneas de acción (conociendo a la empresa), la menos probable pero que sería la correcta: sentarse con los desarrolladores de visores de terceros y corregir todos los fallos en forma mancomunada y ordenada, a lo sumo, se tendrá un retraso de 2 a 3 semanas por sobre los tiempos originalmente pautados. La segunda opción (y la más probable) es que la empresa libere el código «así como está», fije un plazo de una semana para que se adapten los visores de terceros y comience la migración. Ya sabemos como termina esto, como diríamos por aquí «esta película ya la vi».
Por si todo esto fuera poco, Linden Lab parece encaprichado en poner en marcha un proyecto detrás de otro y lanzarlo cuando aún no se ha estabilizado el anterior. Entonces, los usuarios del Visor Oficial (y los desarrolladores de visores de terceros con interface del Visor 3), cuando aún no estén repuestos del cambio obligado por el proyecto SSB tendrán sobre sus cabezas el proyecto CHUI (no se rían, es asi, por Communication Hub User Interface), el cual, busca unificar en un solo lugar todo lo atinente al manejo de las comunicaciones del usuario con sus amigos, grupos, demás residentes y, ¿por qué no? hasta con sus respectivos dioses. En los próximos días intentaré dar un pantallazo sobre este proyecto, aunque en las pruebas que he realizado sobre el mismo, no he visto nada nuevo, al menos para mi. Por lo tanto, me sumo a la opinión de muchos de que el proyecto CHUI (podrían haberle puesto Chewie que suena parecido y mas lindo y es más épico) es ni mas ni menos que volver al pasado adoptando muchas cosas funcionales y visuales del discontinuado Visor 1, es por eso que, quienes nunca hemos abandonado el uso de visores con dicha interface, no podemos ver algo novedoso en este proyecto.
Por otro lado, los usuarios de MAC OSX pueden estar interesados en el proyecto COCOA Project Viewer de Linden Lab, que es la implementación en el visor de las Apis COCOA de Mac OSX. Como no tengo un ambiente OSX que soporte el uso de un visor de Second Life (el que tengo no puede ejecutar SL) sólo puedo guiarme por los comentarios de los usuarios que si lo han probado y que, en su gran mayoría, concuerdan en que la prestación del mismo es ampliamente superior a las versiones oficiales del visor, incluyendo las de terceras partes basadas en el oficial. Se reconoce un promedio de 15% a 20% de mejora en la velocidad de FPS utilizando Cocoa Viewer que usando el Visor Oficial o el Visor Firestorm. Así que queda planteado otro desafío para los desarrolladores de terceros (y aquí, sumemos otro tema y problema mas en la carpeta de los desarrolladores Firestorm), probar dicho código en sus visores y, eventualmente, migrar a este código, ya sea de manera voluntaria o bien obligatoria si Linden Lab decide migrar definitivamente su versión para MAC a las Apis Cocoa.
Dejé para el final algo que quiero comentar sobre uno de los visores de terceros, el visor Nirans. Sin discutir las bondades de este visor, por el contrario, si bien tiene altos requerimientos de hardware para poder usarlo, es un muy buen visor, es triste y preocupante ver la actitud con que se mueve su desarrollador NiranV Dean, quien, cuando las cosas no se hacen como quiere o los demás no hacen lo que quiere, comienza a pelarse, discutir, insultar y menospreciar a todos los demás por no ser tan «inteligentes» de hacer lo que él dice. Incluso, si bien es libre de pensar y opinar a su antojo, me parece muy burdo y fuera de lugar tratar de idiotas y de discapacitados mentales a todos los usuarios que insisten en usar visores clase 1 y, por extensión, a todos los desarrolladores que escuchan a esos usuarios (Cool VL, Singularity y Firestorm).
Incluso, esta actitud, ha hecho que Linden Lab le suspendiera la cuenta por dos días en virtud de su comportamiento y por haber agraviado a varias personas, como así también a la propia empresa. Obviamente esto motivó un ataque de histeria por parte de NiranV que lo llevó a declarar que suspendía el desarrollo de su visor, declaraciones que, hoy, retractó haciendo un juego de palabras que, creo, terminaron mareándolo a él mismo.
Pues bien, estando a pocos días de la fecha establecida para la migración al SSB, podemos trazarnos un pequeño panorama de las aventuras que nos esperan a los usuarios, a los desarrolladores y a los soportistas a partir de, no mas de los 15 o 20 días próximos.
Como decía al gran y querido Tato Bores: «Vermouth con papas fritas y ¡¡Good Show!!»
SaludOS/2