Oz discusses TPV Policy changes

Note: the rest of the discussion was related to clause 2.k of the TPVP changes, and as such, much broader in scope (over an hour). As such, I’ve included timestamps to many of the summaries of Oz’s comments as well as to questions / comments from Jessica.

(38:00) Policy change 2.a: You must not provide any feature that alters the shared experience of the virtual world in any way not provided by or accessible to users of the latest released Linden Lab viewer. Seen as broadly written to the point that TPV developers feel they must go to LL to clarify if any change outside of the UI will fall under the purview of the clause. Also LL have always had the ability to tell TPVs what they can and cannot use, so the clause is seen as heavy-handed and muscle-flexing by LL. So why did LL feel it was necessary to write such a clause?

LL have always had the ability to say to any TPV “something you’re doing is not good for Second Life, and we need you to stop or we’ll remove your ability to connect to Second Life.” It’s necessary to have that ability to protect SL as a business  & as a place where people can come and feel safe. As such, the clause is nothing new.

While acknowledging the clause is “on the nebulous side”, the idea behind it is to provide guidance. A more complicated clause, with edge-case examples was considered, but it was decided to go with a more simple clause. It is meant to be a great deal less that most of the speculation around it has taken it to be.

(40:50) This clause is trying to control the appearance of the world itself, rather than control the viewer. If someone were to make a Viewer that renders cubes as pyramids, then that would break the world view – the shared experience – as only those on that Viewer would see cubes-as-pyramids. If a Viewer renders everything on a different scale to other Viewers, that would break the shared experience.

(41:50) There have been very few things Viewers have done that fall into this category. The most obvious example in the Emerald Viewer additional attachment points.

(42:45) While it was in many ways it did break the shared experience, the Emerald system  also served as a test bed and demonstrated there was a demand for such a capability, and encouraged LL to develop multi-attachments.

Within broad limits, LL does not object to people doing tests. A prototype Viewer that demonstrates a particular feature, as long as it doesn’t “horrifically break something important”, is something LL can work with TPV developers to do; but releasing them to a mass audience is not the same thing.

(44:15) The TPV development community feels 2.k stifles innovation because developers are frightened to invest time on potential new features as there is no assurance that LL will accept them – what guidelines might be applied to determine if something might be classified as a shared experience feature?

“There is one simple rule that any developer can readily understand: if the feature requires that you change the data that is stored about the world or some component of the world in the Second Life asset system or in some external database that has to be accessed in order to properly access the feature, then it’s a shared experience.”

If a developer comes up with a feature that requires an additional piece of data in order to function and which will not function correctly without the data, then it is a shared experience, and will require collaboration with LL to ensure that the additional data is correctly handled by the back-end system and is correctly understood by the asset system and simulators, etc.

(47:08) Multi-attachment is a good example, as the way in which information about what is attached to an avatar had to be changed to properly support the feature.  Region Windlight setting are another example, as they required a change to the way information about a region is stored, and mechanisms needed to be supplied to support the manipulation of that stored data.

(47:56) Parcel Windlight is another example, however as it is already in use, LL will work with the Firestorm team to ensure that the necessary data to support the capability is correctly stored with the parcel data on the server-side, and can be correctly updated, which will be “Better and more flexible that what you’ve got now”.

(48:50) What happens in one or two years time when those responsible for the policy may have left, and 2.k is being interpreted by LL staff who may not be familiar with the history?

“With all due respect, I don’t think there is any way to answer that question.”

Th objective of the policy is simple. Second life is LL’s business, and needs to be operated as a business. LL is providing a virtual world service and it is not viable for LL to allow TPVs to redefine what that world is in ways that could conceivably hurt LL’s business. Even if TPVs don’t go deliberately about hurting LL’s business by breaking the business model itself and how revenue is generated, they can break it simply be fragmenting it to the point where users cannot have a reasonable set of expectations that if they build something or create something, that other users will be able to experience it the way they do.

(51:07) If these things happen, then the business is hurt and if the business is hurt, SL is hurt. The two cannot be separated.

(51:56) TPVs play a huge role in making the business a success

LL has been incorporating TPV features into their Viewer and have “a whole pipeline”  of features implemented in TPVs that are on their way to being included in the LL Viewer – such a the Spell check and Auto-correct capabilities.

(53:02) There are shared experience features also in the pipeline, such as the mesh deformer.

(53:30) The mesh deformer is a concern as the SL community has paid Qarl to develop the feature, and if LL now decide the code is not up to par, no TPV (accessing SL) will be allowed to have it

It doesn’t look like that’s the way it is going to work out. Progress is being made and LL are committed to working with Qarl on the deformer. Mention is made of the original breast physics code (Emerald), which would most likely not have been accepted by LL had it been submitted, and the point is made that the LL avatar physics were actually developed by a Linden employee in his own time and offered to the Lab, and so could be treated as an open-source contribution.

The key is that LL have a standard for code, and while it may take time, contributions do get accepted. So far, LL have not been the bottleneck in this as they have not had to allot any time to the project.

18 thoughts on “Oz discusses TPV Policy changes

  1. Thanks for this. It does alter the way I feel about the TPV policy change, at least tentatively. Thanks to Oz for doing it.

    Three things struck me: one is that the LSL change has been put on hold. I had no idea of this, and I would be willing to bet that most people concerned about it don’t know, either.

    The second was Oz’ statement that viewer usage number are no secret. As far as I know, they *are* secret, and this ranking of viewers by use is the first I’ve seen.

    The last thing is that he said that users have resistance to change, and gave as an example that when the sidebar, etc. were added to the viewer people complained, and then when they were removed people complained. I don’t think this can be counted as “resistance to change”. It’s just people expressing a preference.

    Otherwise, it was reassuring and interesting. Glimpses into LL are rare, and this one was fairly extensive.

    Like

    1. There has been a lot of misinformation circulating vis-a-vis the TPVP changes and knock-on effects that is taking time to correct (the most noticeable being the initial knee-jerk reaction that the policy changes halt *all* TPV development).

      That llGetAgentStatus is being looked at again has been known in some circles for a while – although admittedly, it is probably most widely known by those Watching the JIRA. Jessica made mention of it is last week’s Phoenix Hour broadcast, but again, the news might have been lost amidst all the issues around that meeting – sim crashes, sim restarts, stream breakages and poor audio.

      In referring to the Viewer use numbers, I think Oz was saying they were no secret in the context of the TPV developers – remembering that it is Jessica asking the questions. Usage numbers are regularly discussed in the TPV developer meetings, and are published in the meeting transcripts and as such are known, but again not in the platform-wide context you and I would regard as “well-known”.

      Where change is concerned, I think it fair to say a little of blame resides on both sides in many cases: there are times when LL doesn’t really disclose what is coming down the road, and so when things do happen, there is a fair amount of sturm und drang. Equally, and I have to agree with Oz, even when changes are announced and trumpeted well ahead of time, people state their opinion in such a forceful manner it does come over as outright resistance to whatever is going on. As such, it is fair to say the LL need to manage their side of things a little better – although they have made improvements in the last 12 months, and the user community needs to sometimes needs to consider changes being proposed / rolled-out with (dare I say) fewer histrionics.

      I think Oz did a sterling job.

      Like

  2. We should remember that LL does not make any more money if someone uses their viewer instead of a third party viewer. While they might take some pride in having the “most preferred” viewer, at the end of the day what matters to them is that people are logging into SL and spending some money…no matter which viewer they are doing it with.

    Like

    1. Precisely – and hence again why increasing the market-share wasn’t a motivator for the TPVP changes.

      Like

      1. Maybe. I’m not so sure. The viewer to some extent controls how the user is directed. The first thing you see when you login with Firefox is usually a link to their blog or wiki. The viewer can provide immediate links to the Marketplace or destinations inworld that may be revenue generating. In many ways the viewer is to SL what the browser is to the web. Why do Google and Microsoft and the Mozilla foundation care which browser you use ? Because there is a lot of money to be made by corralling a user base in your browser (viewer).

        Like

        1. I don’t see the web parallel as you describe it.

          Firestorm includes the ability to view the Destination Guide & Events pages (Phoenix, iirc actually displays the destination guide images towards the bottom right of the splash screen (it’s been a while since I’ve run that Viewer, admittedly)). Once in-world, users will be using LL’s search engine and Destination Guide regardless of the Viewer flavour. Similarly, Viewer-based purchases of L$ go via the Lindex regardless of flavour.

          While other Viewers don’t have the market-share of FS/PH, all V3.2-based Viewers pretty much use the LL splash / login screen as does Singularity (4th most popular Viewer according to LL) and so on.

          Currently, there isn’t a viable alternative to SLM that offers the range of products – if one exists at all. Apez was sold to Egoisme, but doesn’t appear to be in operation under either brand; MVX vanished; SLapt.me has gone; we all know what happened to On-Rez (there was another marketplace, but I cannot for the life of me remember the name, and nothing is coming up on Google), so there isn’t really a Marketplace out there to threaten LL’s dominance (and it would take time for one to establish itself sufficiently to become a threat).

          In-world revenue generation will generate revenue for LL regardless of Viewer – it’ll come through tier and through cash-out commission.

          As such, it’s hard to see the Viewer being a major determiner of revenue for LL beyond the obvious – getting people in-world in the first place.

          Like

  3. I read this, and I’m still boggled by why they’re so hurt about the online status indicator.

    It’s such a big nothing, that nobody even thinks about, but they felt the need to make a vague, yet potentially broad-sweeping rule about it >_> It feels like they’re testing the water like they did with the Received Items beta – Push something out that they know we won’t like, let us RAEG all over it, and then come in for the knockout punch while we’re all tuckered out.

    Like

    1. The rule with regards on-line status was already there insofar as the Viewer was concerned long before the “on-line truth” status first appeared in a TPV (Emerald): people have the ability – and therefore the expectation – of being able to set some degree of privacy around their in-world time by broadly defining who can or cannot see when they are on-line.

      Since its introduction in Emerald the Viewer-end “on-line truth” capability has rendered this ability and expectation null and void without any real justification for doing so. In asking for its removal, all LL are doing is re-balancing the scales of expectation based on the capabilities they provide for users within the Viewer code.

      As to the Received Items beta, it is also clear that LL is actually listening to constructive feedback and seeking to improve the capability based on the feedback they have had to date. I can say this with confidence as I’m one of the people who supplied initial feedback and, as a result have been asked to review a further proposal on the capability to help determine if LL are understanding and addressing concerns correctly.

      Like

  4. “LL could conceivably achieve it simply by removing the majority of their Viewer development back behind the curtain, leaving TPVs forever in a catch-up situation.”

    That is exactly what they have been doing. Huge gaps between code drops. The most recent one followed weeks of silence and while large, contained only bug fixes and tinkering.

    Like

  5. I thought Oz did a very good job of laying out what LL is trying to do and what it is not trying to do. Despite comments to the contrary, I think there is a huge benefit that LL sees in having the most used viewer in world. Simply put, their job gets a lot easier if they don’t have to worry about bringing the third party viewer’s along. I wonder if perhaps the situation has, by no fault on anyone’s side, reached a point where the current method of allowing TPV’s is broken. Both sides seem so bogged down in meeting the other side’s needs, that neither is really developing much.

    Like

    1. I’m not sure that the TPV dev / Lab relationship is/was “broken” – as Oz states, the relationship has, if anything improved from a state of “cold war” confrontation to that of mutual co-operation. Rather, I think this is purely as Oz states: a way to put a stake in the ground as to how Viewer development should be handled between the to going forward in order to help LL manage its business.

      Demarcation like this way can usually be a good thing as relationship grow closer and more collaborative, simply because the dividing lines that were apparent during “cooler” times in a working relationship can get increasingly blurred and lead to direct misunderstandings – simply because things can be taken for granted or assumed on either side up to the point where someone says, “No.”, and real upset ensues.

      The only real problems here are how LL announced the changes to the broader community (they didn’t), and for not adding a couple of very brief lines to the Policy that could themselves has helped prevent a lot of the subsequent misunderstandings around the intention of clause 2.k.

      That said, I agree, Oz has done a really open job of sitting down and taking the time to address concerns and upset, and to provide insight into the Lab’s motives and thinking. Not just here, but in the forums and elsewhere.

      Like

      1. Very well put, and I hope you are right. It does seem as if LL is at least offering some opportunities for communication with TPV developers. Putting together a simple set of “rules for the road” for developers may bea good thing that will ultimately make development smoother for all parties. That would be my hope, as I worry about developers on both sides getting slowed down by having to jump through each others hoops. The clause 2.k, once understood, is relatively minor in my opinion. The problems, I think, began when users where having to get the info through their TPV developers instead of LL.

        Like

Comments are closed.