On Wednesday, September 18th, and after some lengthy deliberation, Jessica Lyon issued a Firestorm blog post outlining the future of that viewer’s future support for OpenSim environments.
The post is going to make difficult reading for OpenSim users, but the reality is that for assorted reasons, the Firestorm team have to consider priorities and how to best support their two disparate user communities.
The most important point with the blog is that Firestorm is not about to abandon OpenSim: but there are certain hard realities that need to be faced.
The first of these is that Firestorm are struggling to meet the demands of OpenSim support. While it is easy to talk about OpenSim in the singular – as if it is a single network of grids running to the same overall framework of server code – this isn’t really the case, as Jessica notes:
So many grids and no standard specification. Grid features that vary from grid to grid. We fix an issue on one grid that breaks something on another. Compatibility with OpenSim is vastly more difficult than it is with Second Life. Add to that the fact that we have to continue to merge upstream code from LL on a regular basis. We just don’t have the human resources.
Resources in this case being a developer who not only has the time to devote to OpenSim development on behalf of the Firestorm Team, but also the depth of knowledge of the various OpenSim protocols required to implement viewer-side updates while avoiding many of the problems Jessica mentions.
To try to assist in matters going forward, Jessica outlines some of the steps that the Firestorm team will be taking:
- Firestorm will no longer accept OpenSim viewer features without direct communication via viewer patch contributions, or better yet, some kind of reference viewer. Simply put, the team cannot expected to keep up with all developments in OpenSim, which features have been introduced in some grids and how they might impact others.
- Firestorm can only include features compatible with the current recognised OpenSim version number – features based on in-development or upcoming server code cannot be accepted, particularly those that may work on one grid one way, but differently on another or not at all.
- Firestorm can no longer guarantee keeping old / deprecated protocols active within the viewer indefinitely. Attempting to do so simply increases many of the complexities involved in developing and maintaining a viewer – and Firestorm is already hard-pressed in keeping pace with updates rolling out of Linden Lab for Second Life and with the major updates and improvements being made to OpenSim.
This last point has particular relevance when it comes to upcoming major releases like Linden Lab’s Environment Enhancement Project (EEP), which will entirely replace Windlight. This is actually what prompted Firestorm to try to split viewer development between different repositories – one for OpenSim and one for Second Life – which in turn resulted in a lot of concerns being raised by OpenSim users that have, in part, informed the thinking leading up to this blog post.
Simply put, Firestorm cannot continue to support both Windlight and EEP, and will be focusing on EEP as that reaches release for Second Life, with the hope that OpenSim will find the means to adopt the EEP protocols in the future. Similarly, it is likely that projects such LL’s on-going Love Me Render work to improve viewer rendering, the Estate Access Management project and others may well impact Firestorm’s ability to support OpenSim.
So What Does This Mean?
Simply put, it means that if Firestorm is to continue supporting OpenSim to the fullest possible extent, it is going to need the help and support of the OpenSim community.
Part of this can be due through the likes of communication and viewer patch submissions and testing, as noted above. However, the most practical way to help Firestorm is for those within the OpenSim community who are competent viewer developers and who have – or can quickly understand – the Firestorm code, to volunteer their time and expertise.
To do so, drop the Firestorm team an e-mail providing your name, contact details and a brief outline of your experience in viewer code development, and how you believe you would be able to help.
So if you are that person – please do considered applying; or if you know someone who can help – point them towards the Firestorm blog post. In the meantime, OpenSim users who may read this blog are asked to follow the link to Jessica’s blog post to read her comments first-hand.
Inara Pey: Living in a Modemworld 
I think, that with much of the PC and electronics world in general, there should be a committee that is formed between Linden Labs and the Open Simulator communities, so that a generalized standard that is required to be met, is developed.
It seems, to me, that more people are finding out about Second Life (Linden Labs) and Open Simulator platforms and individual Grids, that for the overall growth of Virtual Worlds, there should be a minimum standard that should be met. This, I think, would ensure the continued growth of our community, in general.
LL is the 800 pound gorrilla in the realm, and I doubt that it would be beat, and Firestorm being one of the most widely used TPVs for Second Life, should be a leader in this committee, as a viewer developer, as it seems that they have the second most experience (next to Linden Labs), with developing viewers and features.
This is my honest and humble opinion, and this would also allow Open Simulator grids to contribute to features and technologies for Second Life and vice a versa.
LikeLike
It’s an interesting idea – but potentially hard to implement for a wide variety of reasons. The first is that of “standards” themselves. Who defines what is “standard”? Second Life, for example utilises the Havok physical engine, and is very much built around that. Havok brings with certain constraints (such as the way region size is deeply baked into the SL architecture) It also comes at a licensing price. Because of the latter in particular, OpenSim grid have opted to work with different physics engines that are (for them) more cost effective. These physics engines also allow a degree of greater flexibility in architecture – such as very large regions or “vari-regions”, which Havok doesn’t appear able to support.
So, how do you define a standard here? Who gets to define the direction for physics within SL and OpenSim? Linden Lab as the 800 lb gorilla? Or OpenSim to keep their costs down. Or do you keep the issue of physics out of the equation? If you do the latter, then you’re immediately into branching “standards” and – in particular in this case – viewer capabilities. This is because SL’s use of Havok allows LL to leverage certain capabilities from the physics engine within the viewer – capabilities that OpenSim cannot easily (if at all) leverage. So, almost from the get-go you’re in a position of having to make allowances in the use of “standards” that immediately bring about the kind of splits in viewer development and support that Firestorm have had to make in order to support both platforms, and which are becoming increasingly difficult to manage.
In some respects, that’s just the tip of the iceberg. There are many other issues – both technical and (for want of a batter term) cultural and (frankly) commerical that would make such an approach – as good as it sounds on paper – very, very difficult to bring about given the overall independent maturity of both SL and OpenSim environments.
LikeLike
Sounds like it is time for Firestorm to split , one for SL and one for OpenSim. Maybe rename the Opensim version, OpenStorm or something. Guessing that most users of Firestorm are on SL and carrying the OpenSim code that is not used in SL. Would make Firestorm more efficient by using less memory and possibly gaining speed. The same would be true for OpenSim users not carrying SL code.
LikeLike
As per Jessica’s blog post, linked to through mine, part of the current problem has been that Firestorm tried to fork between OpenSim and Second Life development, and this simply hasn’t worked from the OpenSim perspective.
LikeLike
I can relate to why Firestorm have to go this way as it seems that the OpenSim community has a small core of people working on a “standard” but then other people working on their own patches and tweaks. Unless OpenSim pulls all these threads together, which seems unlikely as some of the ‘stand-alone’ people develop for commercial OS grids and perhaps have different goals.
It almost feels as this ‘non-cooperation’ may lead to OpenSim effectively become a bunch of totally separate ‘products’ and that would mean a total end to Firestorm development, putting pressure on developing separate viewers by the separate OS teams.
LikeLike