The Dark Ages
Things have been dark here for a little too long because I've been busy living it up on Jyte and Pibb, two sites from JanRain. Jyte is a site that lets you make claims and have people either agree or disagree and discuss. In reality it's a bit more interesting than just that. The thing I like about Jyte is it is very effortless blogging. I can throw out a quick idea and get some feedback and discussion going.
Not so with this blog. I usually try to put a little more effort into the entries which result in somewhere near zero discussion. It's still useful for not only letting people know what I'm working on, but also for keeping notes on things I've found. It's not unusual for me to search my own blog to remember how I did something at some point. My memory leaks too much. Plus, I get to say I have a blog like all those cool kids.
Pibb is a web based messaging / chat application. It's just getting started but is good if for no other reason than it gives the people on Jyte a more direct way to communicate. Both of these use OpenID for authentication which is a very nice idea for a public web site. Those of you that watch my bookmarks (or this blog's feed) probably saw the quick bookmark on Acegi's possible inclusion of OpenID as an authentication provider (along with a couple of other Java OpenID libraries). Muy sexy.
That's Not How We Do Things Around Here
Both Jyte and Pibb, being community oriented sites, have felt some recent growing pains in terms of popularity and new members that immediately try to buck the de facto way of doing things. Tagging on Jyte is a good recent example. You can tag claims on Jyte to make them easier to find. New people inevitably either don't tag their claims or tag them with tags that have nothing at all to do with the claim. The tag centric portion of the community immediately tries to get the author to remedy the situation. Most of the time it ends peacefully, but occasionally people rebel against the very idea of someone trying to tell them what to do.
That's the way the community works. The users of the site give the site an identity. New people that don't agree cause friction. The more interesting thing is to see how the developers of the site try to make the community's customs more formalized in the inherent functionality of the site.
In our tag example, there used to be a "top tags" sidebar. Once a group started regularly abusing tags, their ill fitting tag became prominently placed on the top list. After the group refused to change their behavior the top tags list disappeared and was replaced by a set of commonly used tags. This is interesting in that it tries to provide some sort of structure to an otherwise unstructured mechanism–tagging. The short term solution of dealing with this minor abuse was to change the site's functionality to preserve the way the bulk of the community thought things should work.
The original motivation of the group was to use tags to easily find the claims made by members of the group. The JanRain developers eventually added a "find group's claims" link from the group membership page. Again, the functionality of the site changed based on community feedback. It was all very interesting to see how community (mis)behavior caused features to be added/removed to a public web site.
Have You Seen Goatse?
Our next example, and the subject of our subject, is what transpired on Pibb. Pibb got Dugg. This caused the barely opened site to receive an instant spike in traffic. The result was feedback from the new users ranging anywhere from the positive "this place sucks" to greater levels of naughtiness.
Public web site developers often think about what features would be cool for the community. Wouldn't it be great to be able to easily embed images into a chat using HTML? Wouldn't it be cool if users could create their own threads within a channel so that conversations about very specific topics could easily branch off from the original discussion? Gee, you bet it would.
But, that's where troll scalability (also referred to as cultural scaling) comes into play. When you're building a feature rich site for a well behaved community you don't have a lot to worry about in terms of abuse of features. As a site becomes more popular the number of misbehaving users (we'll use the term troll) increases. They may still be a constant percentage of the community, there are just more of them now.
Admittedly, this isn't a problem I routinely deal with since I develop corporate intranet web based applications. I can pretty much guarantee that the hosting corporation can control its own people. This is a luxury the public web site developer doesn't have.
What happens if users start putting images of goatse or tubgirl (links omitted to protect the innocent) in every place you allow the display of images? You let users create new channels? Great. What if I write a script to create a million channels? I'm not talking about the performance impact. Performance is another issue and is one that most people understand and plan for. The troll problem is one for which very few, if any, public web site developers plan.
Troll control is typically handled after you've gone public and gained some popularity. The solution is usually adding punitive measures to misbehavior and the elimination of features. Your community both wins and loses in this situation. It's great to get rid of the trolls, but where did my much beloved features go? If you're lucky, you lose very few of your treasured community contributors. Some will inevitably leave because they think your site is overrun by undesirables. Some will leave because the loss of functionality is unbearable (spoiled bastards).
So What?
The "so what" moment here is that, as a public web site, you may get one shot at getting popularity escape velocity. Your first large scale public exposure is important. You should work hard to ensure that it isn't a negative experience either to your potential new users or to your existing community.
You designed a site to perform well under load and to work in all the major browsers on all the major operating systems. You spent time tweaking your CSS to make it easy on the eyes. Why didn't you spend time thinking how every one of your cool features could be abused? You need to design your features around the "asshole" user. Don't assume everyone on your site wants to place nice nice. Are you safe from inputing script tags in form fields, SQL injection, omnipresent goatse images, animated GIFs, user created content spam, new user creation scripts, etc?
If any of these successful trolls were smart (I doubt that they are) they would open a business offering their devious skills to public web sites currently under development. If they ever do, I recommend hiring them. You'll save yourself and your community a lot of grief.
