Scott: Troy, do you want to start us off by talking about how user content has been working in Pirates?
Troy: Sure. As some of you may know, we just launched PotBS earlier this year. We have a system in the game where players can create flags and sails for their ships. There's a mechanism to distribute your work and they can actually create and sell their designs as well. Players can also create and model their own ships, and other people in game will be able to use those ships. We have 30 ships now in the game made by players, and these were actually done by only 13 people; so it's a small group of dedicated people creating these ships. With the flags and sails, about 20% of our player base is creating them and a much larger percentage actually use them.
Scott: So is this stuff actually created inside the game, or how are users making it?
Troy: UGC to us means items created outside the game (using Photoshop, e.g.) that you bring in to the game.
Scott: Rob, do you want to talk about how UGC works in Second Life?
Rob: Linden Lab and SL is almost exclusively "resident-created content." We have hundreds of square kilometers of resident owned land where the vast majority of stuff is created by users. We have millions of account holders, about 800,000 of which have logged in in the past 30 days, all with complicated avatars that reflect their individual identities. We're now up to about 100 TB of uploaded data in our asset database and on disk, with 2.5 billion lines of scripted content associated with objects created in-world. In other words, an extremely large amount of content that is UGC!
My role is managing our open source code initiative around the viewer software, available on Windows, Mac and Linux under the GNU content license. Close to 100 contributers have contributed patches to the SL viewer that have been incorporated. So, both our code as well as most objects in the game are all user generated.
Scott: In the context of code vs. in-game content, do you deal with those in different ways?
Rob: Absolutely. With respect to content in world, ownership of that content rests with the residents. We went with a long evolutionary process with respect to that, and to add a disclaimer, I came on in 2006 so wasn't a part of all of it. But originally, people could create content but ultimately it was contributed back to us and we owned it. In a watershed moment for the company in 2004, we changed the rules and made it so that residents owned their own creations and retained copyright in their own creations. This resulted in an explosion of creativity and led to a more mainstream adoption and visibility for SL. The tools in world help enforce this. At the end of the day, the content is theirs. To the extent that there is any copyright violation, it's up to them to decide what to do about it.
But with respect to the code, we have a different take. Because it's something we need to distribute, there has to be a lot more unity than the cacaphony of what's going on in world. We have people sign a contributer agreement when they submit code. They keep joint copyright in their work, so there's still a pretty equitable deal going on there. But we receive full ownership too, and in turn we grant out pretty broad rights under GNU so everyone can have access to those changes.
Scott: When you shifted over from the old to the new model, were there issues with that with people who had contributed prior to that? Were there other complaints you had to address?
Rob: That's part of why I added my earlier disclaimer! I'm not sure exactly what the delta was but disputes did come up between residents and they do have the power to report abuse, and the way we handle that is through the DMCA like a lot of other companies do. It can create tension whenever there are times when people feel there's flagrant abuse going on, and we do end up getting involved when someone is a repeat offender and we sometimes take action there.
Scott: The way your business was designed, it sounds like you had to think about these things as you went along. I'm interested to find out if that worked differently for Flying Lab.
Troy: I've been managing there for about 3 years. Players had approached Taylor Danes, the original lead designer, with the idea to build their own ships. We approached it like mission impossible and made it happen -- the program was born and it evolved over time. We get more involved in the mediation of these things. SL is a very different world than our MMO, and there are things you might find there you would never find on a flag or sail in our game (laughter). It continues to evolve, and we just introduced User Content 2.0 where we went from a peer review system where people ranked things from 1-5 and had the ability to add a comment to a "kitten war" model, where you just pick the one you like the best. When you have 2 flags that are heinous you have to choose the least of the worst of the bunch, and there's been some difficulty in the training surrounding how that model works -- i.e. if you have to pick the best of the worst it doesn't mean that "bad" flag necessarily gets adopted to offend everyone and their mother.
Scott: These things obviously create legal issues which is why Eric is here. Want to comment?
Eric: I think about how the law can facilitate or hinder a content generation engine. A lot of you are thinking, "how can I get users to create more content or the right kind of content?" and all that's governed by legal rules and procedures. My high level takeaway is there is a lot of good news for you. You figure out the best way to manage your content generation engine and you have a range of choices that are permissible under the law. When I talk to audiences like this I find a lot of bad lore and myths, carry overs from other analogous spaces or people reading the tea leaves in odd ways. One big myth is that there's a continuum between being a passive provider of tools that allow UGC and being an active facilitator of an engine or publishing UGC through an editorial process. Mostly it doesn't actually matter. The contract you establish with your users is what's important. The starting point for any arbitration is: what is the deal you struck with your users?
I want to talk a little bit about 47USC230 because this law is the best news I'll give you. It passed in 1996 at the height of "cyberspace exceptionalism" where the prevailing discussion was "we need unique and special rules in this environment," so Congress crafted them. It essentially says "websites aren't liable for what their users do." We think that's good news; it's what we want to hear. If I take ownership or edit the material, does that change my relationship to the content? If I screen it or filter it, surely I must be liable for it? The answer is NO, none of this is the case. Embrace 47USC230, it's your friend! You can build any kind of engine you want and you're not liable for what your users do. Knock yourself out. Throw up a bunch of tools and let them go hog wild -- the answer is the same in both cases.
There are some caveats: this doesn't apply to copyright. If you have users who provide copyright infringing materials, it's governed by a different statute. In 17USC512 Congress said there's a series of rules about dealing with copyright infringing material supplied by users. With this you see a "notice of takedown scheme" -- that's the most common type of approach you deal with. How do you really get all the benefits of 512? That's a bit beyond scope of this panel.
Back to USC230 -- when we're not talking about copyright, websites aren't liable. But then, you can't blame the lawyers for how you set up your content generating engine. You can't say "the lawyers made me do it!" You have your CSR or community care people -- you need to designate these people to make judgments about what users can do. They're developing a sort of "common law" of precedent-based judgments. You have people who develop laws for you but you don't traditionally train them as adjudicatory experts and you should. They need to be taught how to develop private law that facilitates the creation of your content engine. Troy mentioned the "kitten war" system where you have a set of user reporting tools that say "this content is good/bad" -- you've outsourced it to your users. Or look at eBay for example, who overlays their own set of takedown procedures to the process that's more robust than what Congress actually requires.
Scott: You have to do things that make sense for your communities. We have two examples of different communities with different rules. What kind of rules help encourage users to contribute? And how do you deal with inappropriate content?
Troy: We have lots of filters in place to label content appropriate or not. What's rejected is usually just poor quality, not offensive stuff -- we don't get a lot of that coming in. We have a committee of volunteers that help people learn Photoshop skills, the tattering and weathering of sails and so forth. We want flags and sails in the 1720s Age of Sail era, so a robot dog is not appropriate. We don't just reject it, though; we reject it with hints and tips. The new system encourages people to start their submission in the forums to get initial feedback before they actually submit inside the tool, and we step in if feedback from the community gets abusive.
One problem we do see is that people like to haze our staff through user content submissions. I've seen images of my face on a flag -- it's amusing. They may have gone as far as hiding my face in a strategic texture or something so sometimes those things actually make it past the filters, so we had to develop yet another layer to go in and take out those things. People stealing other people's designs and resubmitting as their own is actually a larger problem. Our mechanism had to be built with that in mind. There's a reporting system and users can click the "panic button" if there's content violation, either copyright or inappropriate stuff. I like to say that community management is like running a summer camp and this is the arts and crafts part. It really helps with long-term retention because it helps keep user interest.
Rob: When someone buys a plot of land in world, that's their plot to do whatever they want with. We're not going to make the same calls on quality that Troy's team would. It boils down to: is this within our Terms of Service? We don't do any pre-vetting at all, and we rely on abuse reporting to get feedback from the community when they see things run afoul. Within Linden Lab if we see it we flag it ourselves too. But with such a large space it would be impossible to do that type of vetting on that many terabytes of content.
The part I manage more closely is the source code where it's more similar to that vetted process. We haven't established kitten wars for patches or but we are very particular about what code we accept in. We have mailing lists and bug tracking systems that serve as discussion places to talk about these things.
Eric: Back to what works/what doesn't -- I was at epinions previously. We discovered there that it's about providing the right incentives and disincentives to users. We gave cash, credit, reputation -- we paid them for their contributions. Don't underestimate the power of cash to get people to do what you want (laughter). We also used disincentives like public shaming. We used a tool called "tickets" -- for out of bounds behavior the user would get a ticket on their profile page. Particularly to power users, this can be a powerful disincentive.
One other thing I want to mention: the meta-community. People want to talk to each other about the assets the site has and make it their own. They want to do it with your tools but they also want to do it offsite. Think about: what kind of tools can you give them to enable that? How can you spur that kind of behavior? In your power law these are your users at the top, and you want to encourage them to go off and form their own communities with your sponsorship and support. They become more invested in your community.
Troy: We try not to call it "incentives" per se, but these ships are stunning and people put in a lot of time so we want to value that. The impact these 13 people and 30 ships have is exponential. They're creating vehicles anyone can use, and ships are crucial to this game, obviously. People do it for recognition -- that's one way to pay them back. In our ship guide booklet that shipped with the box we actually featured the user created ships and the players that created them. We've celebrated them in our newsletters. We let them play the game for free. It's interesting though -- 3 of those 13 people don't actually play the game and just want to build ships!
When people talk about UGC they tend to worry a lot about quality -- these people are artists. They're taking actual plans from nautical museums and using plans to build ships to scale -- it's phenomenal. The vast amounts of effort they put in -- why they do it is not even something I necessarily understand (laughter) but I encourage it. These people are ardently historical -- they're appreciative when we stick to the lore and cranky when we deviate from it. These people have been a real asset to us.
Scott: I remember you telling me an anecdote about some sound effects?
Troy: Ah yes. So, pirates are dirty folk. Someone recorded water pouring into a toilet to be a "urination" sound -- and the community got upset because they didn't have toilets back then so you wouldn't have actually heard that sound. Users got upset because it wasn't accurate. We also had people complain that we didn't have slavery in the game and that women were allowed to be captains -- they say "that's not historically accurate!" We ended up having to say "duh" -- on some level you have to get over it.
Eric: I'm shocked to see how much work people will contribute that defy my definition of rationality. If you don't ask for something big you won't get it. But if you do ask, you might get it. There's a tremendous opportunity to engage with your power users to find out what users are willing to do, even if it seems completely illogical.
In the late 1990s there was a lawsuit against AOL for activities of power users who had been given the opportunity to do something on a volunteer basis. From the standpoint of employment law, there is no such thing as a "corporate volunteer." So that's a real challenge. At epinions we set up a contractor relationship with our power users and we did pay them. It's better than going with nothing because you might be open to class action suits.
Scott: How does Linden Lab encourage users to contribute?
Rob: The type of compensation people expect is usually resident to resident transactions. If you look at our website we publish the economic activity; in the last month there were 173 residents who made over $5000 that month on resident to resident transactions of some sort. We don't have that broken down by content creation, land sales, etc. but a lot of that we know is content creation. Other folks will do it for the same reasons people have free websites. The motivations are extremely broad.
Scott: You need to sit down and think about what in the experience actually motivates them. Have you seen that?
Troy: The actual creation of the art is why they're doing it -- it's amazing. There's a lot of strange hobbies out there and creating a digital flag certainly isn't one of the strangest. They can be quite gorgeous with the tattering and texturing.
Rob: It's sort of the digital equivalent of knitting -- there is a productive outcome. Almost no one has a career in knitting but it's something to do.
Scott: On the topic of contributing code or things that break the game -- how do you deal with bad code?
Troy: That's actually happened. It's sort of par for the course in MMOs that something breaks and you have to fix it. We find it and fix it and that's standard daily business practice. The real issue is how that impacts the upward trajectory of the program -- if the user content submission engine goes down for 2 weeks, it impacts people's confidence in the program and brings down their inspiration. The community spends more time complaining about how it's not working and they don't continue to create content. We have to make sure it's on 24/7 without a lot of impediment.
Scott: Are your users involved with identifying problems or not?
Troy: They do let us know but they're not in charge of repairing or fixing; we do that.
Scott: Rob, do you vet contributed code?
Rob: For code, absolutely. There's been a case or two where we didn't vet closely enough and it was a problem we had to go back and fix. It wasn't malice, it was just something not QA'd enough. In world, some objects are created that cause problems too. We've taken a tack that's controversial -- we allow some things that cause technical problems. We try to avoid that of course but there are some things where we have a hard tradeoff to make: we can impose technical limitations but it might impose on a lot of legitimate uses of our technology. Or we can just say "don't do that" and we've decided to do that in a lot of cases instead of putting in stringent technological measures.
Scott: Eric talked about common law and how that's developed -- how do you deal with disputes between users?
Troy: The reporting tools help flag submissions. We get notification there's a violation with a direct link to that asset, so we check it out and can reject it based on what we find. The proof's in the pudding; if it's violation we send a notice and reject it until they can prove they have the creator's permission.
Rob: We follow the DMCA.
Eric: Common law within a company proliferates over time. You usually have a test case, then corporate freakout, then banning. If there's only one freakout per month, you get 12 new laws per year (and that's generous, there's usually more freakouts than that!). You end up with this body of inconsistently enforced rules that no one understands -- so think about the challenge of code proliferation. Sometimes the best solution is to let it go instead of coming up with new law.
Scott: What are your agreements like with users?
Troy: For ship submissions, they fill out a document that gives us the right to use the ship but also gives them rights to use it on their website and so on as long as it's not a competitive usage.
Rob: With code we have a written document that's a joint copyright assignment.
Scott: We're getting close to time -- can you give 2 or 3 nuggets about how to make UGC work?
Troy: Our approach differs from Linden Lab -- the bottleneck is our administrative process. Every item of UGC in the game is approved by someone, and that's 3-500 flags and sails to look at per day. But each individual approval process is now really quite quick. The real challenge is for people whose flags are rejected -- how do we keep them invested in the process and to encourage them to try again? We give constructive feedback and tips and tricks when we reject someone's submission. People will submit more than one flag even if they're rejected, and as they refine their skills more of their work is accepted. Minimizing barriers to entry is important.
If you have a committee of volunteers/high level contributers, you want them to have a certain temperament, because they can make or break the program for you. Help them understand the fundamentals of community management: "walk softly and carry a big eraser." You can't do it on your own -- you can't do it with just one staff member; you need a team to handle this. We have ESRB concerns as well as a T for Teen title too, so if things are too gory/explicit etc., we have to be careful of that stuff.
Rob: People don't like to be taken for suckers. Companies will set up incredibly lopsided agreements and wonder why they have trouble setting up communities. A lot of folks want to see more and broader rights. Look at Wikipedia and the open content movement. People are expecting a lot more out of companies in terms of an acceptible tradeoff for contributing their work. For SL the ownership was a key tradeoff to make. As time goes on you'll see a lot more tradeoffs go in favor of content creators.
Eric: Most users want to do the right thing. Build systems that help them do that. Low barriers to participation are good. Guaranteed though, there will always be vandals and bad apples, so you need robust processes to squash the bad actors. It's a balancing act -- keep it easy for people doing the right things, but you can't let bad actors take control of your site.
Q&A
Q: Regarding 47USC230, the language isn't clear that legislation surrounding websites necessarily applies to online games. Also, don't we still have concerns for liability if I'm aggregating content someone has submitted that isn't originally theirs?
Eric: First, the implicit assumption that virtual worlds are unique and special snowflakes and somehow different from other cyberspace -- I cannot reject that argument enough. Anchor yourself in the broader context of cyberlaw more generally -- a lot of these issues have actually been solved. Second, let's look at a test case: I as website owner aggregate content and even sell it and some of it turns out to be copyrighted. That is covered by 47USC230 and I am protected. It doesn't matter if I filter it or not -- the rules apply in either case. It is as good a law as you might hope for, and that's a good reason not to seek out virtual world exceptionalism.
Q (Victor Wachter, Cryptic CM): Do you have filters that recognize and promote viral growth within the community? Do you promote individual submissions that become popular?
Troy: Absolutely. For example one design people love is a hedgehog. The group called "The cult of ether" has this hedgehog and it's really popular. There are images that catch like wildfire and users share them.
Victor: So you're growing by 200 flags per day. How do I as someone submitting content still feel valuable when there's so much UGC going on?
Troy: Good question. We haven't run into that problem yet. The reward is participation in the process and validation from us. There's a collection mentality too that people have, and this creates opportunity to feed that need to collect all the different flags.
Q: If you're paying someone to contribute (a la PotBS users who play for free for contributing ships), does that become contractual and no longer UGC?
Eric: Your friend 47USC230 is going to help you here. Even if you asked for it, you're still protected. But if you asked for it and paid for it, it becomes harder in terms of copyright to say "I'm just hosting this" if it turns out to be copyright theft. But in all other ways, you're still protected under this law.
