(56:56) LL worked in secret on Viewer 2.0, more recently LL has worked on FUI, simplified inventory, etc., behind closed doors. TPV developers have an issue in that they cannot quickly adopt new code when they have no idea it is coming. So while LL state they want to work with TPVs on new features, they continue to work behind-the-curtains – why?
some work may continue behind-the-curtains, some not so. Simplified Inventory is a good example, as it is something original developed for the Basic mode of the Viewer that never made it into that mode, and was released as a test case. It has not been integrated into the Viewer as LL learned a lot from it. Received Items has been handled the same way, and people are trying to integrate feedback into the work.
Some things will get developed and put out in public where people can see them, and it is part of Oz’s job to help ensure that TPVs remain at, or near feature-parity with LL whenever LL introduce a new feature. The caveat to this process is that as a normal part of software development, when working on something, goals change. Depending on how development goes, there are trade-offs and compromises – not doing a deformer with the mesh roll-out was one such compromise.
The process of making such trade-offs can benefit from being in the open. Sometimes it doesn’t. LL frequently faces a lot of distress around any change they make, and that distress can be distracting. It also means that LL can’t always troll-out a feature and present it in the manner they want to present it. So some significant features are going to be developed in private. When they are made available, LL will do everything they can to make it possible for TPVs to catch up.
(1:01:48) It is not in LL’s interest for TPVs not to catch up; if TPVs aren’t keeping up, it is LL’s business that suffers as TPVs have the majority of the users at this point, and for the foreseeable future that will probably remain true. Development will be balanced against the needs of the business.
(1:04:00) What about putting TPV developers under an NDA and allowing them access to new code or place new code in hidden repositories where it can be worked on alongside of LL, so that when the code is ready for release, TPVs can release it alongside LL?
Over the past two years, the TPV / LL relationships has evolved from a somewhat “heavily armed truce, almost cold war mentality” to something far more collaborative which is fast approaching collaborative approach to dealing with one another. As a personal view, Oz sees that trend continuing and that at some point in the future where something along the lines Jessica described could happen.
While the changes to the TPVP have created concern, as people see it work in practice and proposals are brought to LL which are either for shared experience features or for which clarification is being sought, then trust will continue to be built.
An issue with NDAs is does LL want to get into a lawsuit if information gets leaked. While LL have the ability to lock developers out of SL, they “don’t want to get there”. The company doesn’t want to be forced into doing something that places them back in an “oppositional” rather than collaborative relationship with TPVs.
(1:07:50) “I’ll just give you my personal take on it. I think that Linden Lab has, as a whole, evolved significantly in its understanding of the value of open-source over the last couple of years. And … I feel more than adequately supported by my management for what we’re doing together, and I see a lot of optimism that we’re going to be able to develop things together, support each other in what we’re doing and work collaboratively to improve Second Life as a whole.”
(1:09:00) What, if any TPV features need to be removed as a result of these policy revisions?
The on-line status indicator.
In terms of Viewers being defined in Group chats, it is acceptable to have a pop-up asking people if they are happy to have their Viewer displayed alongside their name, so long as the default answer is “No” (currently applies to Phoenix / Firestorm support groups).
(1:10:51) What is the time-frame you are giving TPVs to comply with the policy?
There isn’t a fixed time-frame.
(1:11:00) Should users on older versions of TPVs which haven’t been / cannot be brought into compliance be concerned that their accounts are at risk?
No.
(1:13: 00): can the process of code development and submission be simplified?
It can be as simple as it needs to be, but not simpler. Code development is a discipline and requires proper reviews and feedback. Some in LL would like to shorten the process, but it is not allowed. A certain amount of process is unavoidable. Maybe this can be improved, but there is an irreducible minimum. However, specific suggestions as to how things can be improved are welcome
(1:15:50) is it possible to give more of an indication of what LL is working, Viewer-wise?
That happens in part: proposals are offered and checks are carried out to see what, if any work is going on around the proposal area and the feedback might be that it would be better to hold-off on things.
(1:16:45) how many at LL use the Viewer / platform and how are decisions as to what to work on (bug fixes, etc.) arrived at as it often seems LL priorities are out-of-step with the users?
“A significant number” at the Lab use SL recreationally. When there is discussion as to what might / might not be changed, input from within the company is very common and is not ignored. As to which problems are worked on, the sheer number and diversity of SL users means that no matter what problem LL are working on, it’s not going to be someone’s problem. When region Windlight was rolled out, user response was both praise and accusation (“why are you wasting time on this?!”) in equal measure.
Inara Pey: Living in a Modemworld 
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.
LikeLike
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.
LikeLike
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.
LikeLike
Precisely – and hence again why increasing the market-share wasn’t a motivator for the TPVP changes.
LikeLike
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).
LikeLike
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.
LikeLike
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.
LikeLike
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.
LikeLike
“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.
LikeLike
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.
LikeLike
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.
LikeLike
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.
LikeLike
Very well said, and I agree with 98.2% of everything you have stated.
LikeLike