Category: Transcripts

Meet the Lindens is a series of conversations / Q&A sessions with staff from Linden Lab, held as a part of the SL Birthday celebrations in-world. They provide opportunities for Second Life users to get to know something about the staff at the Lab: who they are, what they do, what drew them to Second Life and the company, what they find interesting / inspirational about the platform, and so on.

Tuesday, June 20th saw Landon Linden sit down with Saffia Widdershins, and this article hopefully presents some “selected highlights” of the chat, complete with audio extracts from my recording of the event. The official video of the event is embedded at the end of this article.

About Oz and Grumpity Linden

Oz Linden is the Technical Director for Second Life. He joined the company in 2010 specifically to take on the role of managing the open-source aspects of the Second Life viewer and managing the relationship with third-party viewers – in his previous role, he had been responsible for leading the company his was working for in taking their product from closed-source to open-source and then managing the technical side of the product as a open-source project for a number of years.

Over the first two years of his time at the Lab, he was primarily focused on the open-source viewer work and in refining the overall viewer maintenance process, before his role started expanding to encompass more and more of the engineering side of Second Life. When Work on Sansar started in earnest, he pro-actively campaigned within the Lab for the role he has now, with responsibility for managing all of the engineering side of the platform.

He came to Linden Lab out of a desire to do something “fun” after working in the telecommunication arena, notably with voice over IP systems (VOIP), which he defines as being “really interesting technology with some really fascinating challenge”, but in terms of it being fun, it really didn’t do what I wanted it to do.”

He classifies the attraction to working with Second Life as perhaps falling into three core areas: through the open-source nature of the viewer, he is directly involved with how SL users are using the viewer and what they do with it – which can often times take the Lab entirely by surprise; through the fact that the Second Life offers the challenge of trying to implement new technologies alongside of (rather than simply replacing) older technologies; and working with the operations team and others to ensure SL constantly evolves without (as far as is possible) breaking anything – a process he refers to and rebuilding the railway from a moving train.

Grumpity Linden is the Director of Product for Second Life, enjoying what she and Oz jokingly refer to as a “symbiotic relationship”. She actually started at Linden Lab in 2009 as a contractor working for The Product Engine, a company providing end-to-end consulting and software development services, and which support the SL viewer development. She became a “full-time Linden” almost three years ago.

As Director of Product she manages the product team, which oversees a wide range of SL-related activities alongside of Oz’s team. This can involve coordinating the various teams involved in bringing features and updates to Second Life (e.g. coordinating the engineering teams and the QA teams, liaising with legal, financial and compliance to ensure features and capabilities meet any specific requirements in those areas, etc.). This work can also involve looking at specifics within various elements of the overall SL product, such as UI design and layout, etc.

Grumpity has a background in psychology and computer science, but has worked in the oil and gas industry. On moving to the San Francisco area, she crossed over into working within the tech industry, eventually settling at Linden Lab as a contractor, working on the Viewer 2.0 project. She enjoyed working at the Lab so much, she resisted all attempts by her employers to move her elsewhere, finally joining the Lab full-time in 2015.

Like Oz, Grumpity is passionately committed to seeing Second Life continue.

Q&A Session

How much control and input do you have over the direction of second life?

Grumpity: I will let Oz speak more to that, but Bento was conceived and reared and launched all through the efforts of Oz’s team and of Engineering. Certainly, Product took a part in defining that, but this is a great an example of one of the long-time Lindens [Vir Linden]  suggesting this as a possibility and then this feature getting worked on.

There was a tonne of time spent defining that work with residents, which I’m also very proud of, I think we absolutely took the right path there, but as to the development of that project – Oz, do you want to speak to it?

Oz: Just to comment to that one point about Bento. The general direction of the project we started out with changed very significantly, once we got residence involved. The essential concept of extending the avatar skeleton and adding capabilities, that was the concept we began with, [but] the specific additions we made to the skeleton  changed very dramatically after we got resident designers involved.

We were planning on doing a quite simplified hand, for example, and the designers came back to us and said, “look, we really need every joint in every finger”, and ultimately they convinced us that was the right thing to do, and in retrospect, it’s obviously worked out really well.

The broad question of who or how we set that direction; it’s one of the things that’s really great about working at the Lab … We have an incredibly collaborative process. Pretty much everyone involved, up to and including the residents – emphatically including the residents, I should say – is empowered to put forward ideas. And so our job isn’t so much thinking up what’s going to happen to Second Life, as it is from just picking from among a myriad of possibilities. We could have a staff of 500, and we wouldn’t have enough to do all of the really cool things that we might in theory be able to do.

So it’s picking and choosing, and we try to shift who we’re making happy at any given time, so we’re spreading it around a little bit … My job is to think about what the technology impact of anything is going to be, how difficult it’s going to be to do, and how long it’s going to take to do it; although even more so that most engineering groups, I think we’re really challenged in figuring out how long it’s going to take for things to happen.

And the Product team, headed by Grumpity, thinks about what the implications are for the way that affects the business, affects the activities people are already doing in Second Life – to the extent that we know! And we work together to pick from the things that are possible and can be done in a time frame that’s good. We try to make sure that we’re doing something new fairly regularly; so we can’t pile on everybody to a project that’s going to take two years, because then for two years, nothing would happen.  Well, the company did that once, and we all know how that went…

But yeah, between us, we have a lot to say about it. There are aspects of the way that Second Life evolves that are not really our space. For example, we’re not heavily involved in Governance issues; we’re not heavily involved in thinking how much things may cost. That’s mostly other people. But how it works and what it can do – that’s what we spend our time on!

Grumpity: And to mention, we’re not necessarily heavily involved in compliance issues … but we do spend a lot of time trying to figure out how to minimise the impact of compliance while actually adhering to the needs.

As inventory in the viewer is just pointers to assets on the Lab’s servers, could Linden Lab provide a means for redelivering lost inventory items?

Oz:  We have recently put out some changes that are intended to reduce some of the ways we think people were unintentionally deleting things, and we’ve fixed some bugs that may have been responsible for things going astray that shouldn’t [updates reviewed here & now in the release viewer] … She’s right, your inventory is a set of pointers to assets; we have the assets, we don’t have a record of what those pointers were. The pointers are ephemeral; they change dynamically, and we don’t today have a journal of what all the changes were that went through.

That’s an area of concern;  unfortunately, solving that problem very likely falls into that project that would take at least two years category that I talked about before, that’s difficult to tackle on the whole. So we’re trying to find aspects of it that we can attack and improve … So we’re trying to find ways to do incremental steps that make inventory more and more robust. If I were to go to Grumpity and say, “this is what it would take to completely solve the inventory problem,” she would end-up saying we can’t commit that large a fraction of our resources for that long to that problem. So we have to find ways to break it down into small pieces, and that’s what we’re doing.

Unfortunately, that means we can’t say all the inventory problems will be solved by the middle of next week or even next year, necessarily.

Grumpity: We spent a lot of time investigating this recent uptick in reports of inventory going to Trash accidentally and getting deleted, and we’ve put  in a bunch of viewer-side changes to prevent that, and Firestorm has merged those in. so please make sure your viewer is updated. The new Firestorm release [reviewed here] has all of them, and even some that we haven’t released but are in the latest Maintenance RC viewer [version 5.0.7.327250 at the time of writing this transcript].

I would also like to use this platform to say that we absolutely need viewer logs from the session where the deletion or the disappearance of inventory happened, to continue to diagnose this problem. So if you’re in a position to provide those logs from the session where the inventory  loss happened, please, please do. There are multiple JIRA already open – file a new one, reply on the forum, we’ll see all of them, and I will be thrilled to take up the cause and find out what has been going on.

Oz: That’s a point worth emphasising. We don’t keep all the logs for a long time; we couldn’t, they’re just too big.  Id you report that three weeks ago, you lost 100,000 things, there is no hope whatsoever that we’re going to learn anything from that report. Those those logs are long gone; we cannot tell what you did or what happened to what you lost.

If you report it the day that you lose something, and we see that report – and we’re watching those reports, we have people who watch those reports all the time –  and you attach a viewer log, and there’s a page on the wiki about how to find the logs. And you tell us “I was in this region, at this time, and the following stuff disappeared”, or even: “I was in this region at this time, and I knew that I had it then, but two hours later I noticed that it was all gone.” That gives a window where there’s some hope of us finding  information about it. And we can use that information to figure out what happened.

We often will not be able to recover your lost items; occasionally it happens, but unfortunately it’s not the normal.  But it would be an enormous help to us to get reports that have that kind of information on them promptly, so we can dig out and try to learn what happened and what went wrong, and then those cases at least, we can fix.

Grumpity: So, for the record. In all of the reported cases where we were able to get logs from the server-side for this inventory loss and actually find the log records for when the deletions happened; from our end it looks like it was a regular  case of the user deleting inventory. So in order to figure out what’s going on, we absolutely need viewer logs so that we know what the viewer was doing and why those messages were sent to delete inventory, if you did not intentionally do it.

… Again, I’m going to use this soapbox to say we triage incoming bugs pretty much every [working] day, sometimes we skip a day when there are other things that get in the way. We triage incoming feature requests on a regular basis as well, not quite as frequently, and we pay attention to what’s going on. It is our hand on the pulse, and it is also your best bet for getting bugs addressed. If you write about a bug on the forum, maybe somebody else will file it, but may not, and maybe it will never get to us. If you are sure it’s a but – write a JIRA, and then we’ll see it.

Continue reading “SL14B Meet the Lindens: Oz and Grumpity Linden” →