As concern over the latest TPVP changes continues, Oz has offered-up additional information on what section 2.k in particular means, and how it affects TPVs is terms of official Viewer releases, etc.
In a comment on the thread Questions about new TPV policy initiated by Cummere Mayo, Oz states:
Thanks for taking the time to pull your questions together, Cummere. I know a number of others have had similar questions, and I wanted to take a minute to address them here. I hope this will help clarify things.
1) What is meant by shared experience?
Making a simple statement that covers all possible cases is not easy … there is an unavoidable element of judgement in interpreting this rule; I’ll try to answer below, but that should not be taken as modifying the policy itself. We will certainly help developers with proposals to understand whether or not a feature might fall under it. It’s worth noting that the vast majority of all changes made by third-party viewers have certainly not been a problem. The fact that there have been some problems in the past motivated our adding this rule so that in the future developers would work closely with us to prevent any more like them.
A shared experience change is one that modifies the definition of the elements that make up the virtual world, or how they behave, in such a way that users on other viewers don’t experience the same virtual reality.
This rule does not affect changes to rendering, user interface, or the controls a viewer offers for interacting with the world.
2) What counts as the latest released Linden Lab viewer? Do the Snowstorm and Beta viewers count as released?
The Release viewer is the benchmark, but the difference in time is normally quite small (a few weeks). If the relative release schedules of our viewer and that of some TPV are causing a problem, then we will discuss making allowances for that if the stability of the feature makes that a reasonable thing to do. The whole point of the Development and Beta viewer builds is to test things – which implies that those tests may reveal the need to modify the feature, potentially including changes that would not be compatible with the earlier version, so the likelihood of this kind of problem would have to be taken into consideration.
3) Does this mean systems like RLV and integrated AO’s are no longer allowed?
No.
4) Does this mean that third-party viewers may no longer experiment with and help test new features?
No – if the feature would fall under the 2.k rule, then it is faster and easier for everyone if the primary development and testing of it be done based on the common upstream code we make available to everyone, but parallel work by developers in test versions (not the default downloads) of TPVs will usually be ok as long as everyone (including the users of those test viewers) understands that the feature may change in incompatible ways, or even in an extreme case be withdrawn (such as if it is found to be harmful in some unresolvable way).
5) Does this mean that text only viewers or “voice only” viewers would no longer be allowed?
No – failing to provide a common feature is not the same as adding a new feature. Users who choose to use such viewers are making a choice that is up to them.
In terms of impact on TPV, the core paragraphs are:
A shared experience change is one that modifies the definition of the elements that make up the virtual world, or how they behave, in such a way that users on other viewers don’t experience the same virtual reality.
This rule does not affect changes to rendering, user interface, or the controls a viewer offers for interacting with the world.
These give unequivocal clarification to a misunderstanding I’ve seen posted on a number of blog commentaries: that UI changes developed by TPV are unaffected by the policy update. To be fair to Oz, he made this very clear in the meeting last week when the changes were announced – but some commentators still seem to have the wrong end of the stick when it comes to UI changes.
To put it simply: the policy changed doesn’t impact on things like revised Build floaters, additions to the Snapshot floater (to upload to Flickr, for example) and improved Camera control floaters, etc. Similarly, things like object derenders are well outside the scope of the policy, as is the ability to audio or visually mute others (which is a concern I’ve seen raised elsewhere, despite the fact it is LL themselves who are introducing Visual Auto-mute), so people have no reason to worry on these scores.
I still find “shared experience” as defined in the policy itself to be far too vague – Oz’s clarifications notwithstanding; and it is the policy that will be used as a yardstick, not additional comments in a forum which may well be lost in archives over time. As such, it would be useful if wording such as Oz gives in the two paragraphs above were cited within the policy as examples as to where the line is drawn.
Better yet, I’d like to see the Lab take-up Tateru Nino’s suggestion. Over on her blog, she publishes the answers she has had to date on the policy changes (and if you’ve not read them, I urge you to do so). In particular Tateru suggests:
A well-documented baseline feature-set, that content-creators could refer to with confidence, would make a lot of sense, and probably be of broad utility and benefit…
Which is an excellent suggestion. Such a baseline document doesn’t have to be within the TPVP itself. LL have a wiki, and it could be placed there as a part of resources for TPV developers or those wishing to get into TPV development – as long as the policy provides a link to the baseline,then the needs of the policy are served and people get a clearer understanding as to what is “allowed”, etc.
Tateru’s piece raises the spectre of enforcement – and Section 8 of the policy is somewhat vague to the point of unpredictability, as Tateru states. It was an issue back when the policy was first introduced, and these latest changes bring those concerns back into focus. Again, providing an outline set of exceptions (say, alongside the baseline feature-set mentioned above) would go some way to further focusing developer’s thoughts and people’s understanding.
That said, and in fairness to LL, where problems have occurred with TPVs over the past few years, they’ve made every effort to sit down and discuss issues with the developers concerned, and provided opportunity and time for ways to be mended rather than simply dropping the hammer. As such, I doubt that they are going to stop any such dialogue as a result of these policy changes which may be required in the future. Again, as I’ve said elsewhere, LL isn’t the malicious ogre as can sometimes be portrayed.
I still have concerns that section 2.k will have an adverse affect on broader Viewer innovation than perhaps the Lab anticipates – which is not so say I don’t understand the reasons for the Lab taking this step (which Oz also moved to clarify in part in a comment he made in reply to my original piece on the policy changes). Hence why I feel that were the Lab to take one or two additional steps in the matter and provide a baseline functionality document, together with some examples of potential exceptions that might cause problems (with any required caveats about such a list not necessarily being complete, etc.), would actually help the wider audience of concerned SL users understand what is happening and why, as well as providing TPV developers old and new with a more solid foundation for their work going forward.
Related Links
- My original TPV Policy changes article
- Tateru’s article on answers to questions
- SL forum thread on questions on the TPVP changes
- Recording of the TPV Developer meeting at which the changes were discussed.
Inara Pey: Living in a Modemworld 