Raw Thought

by Aaron Swartz

Code, and Other Laws of Wikipedia

Wikimedia 2006 Elections

Part 1: Wikimedia at the Crossroads
Part 2: Who Writes Wikipedia?
Part 3: Who Runs Wikipedia?
Part 4: Making More Wikipedians
Part 5: Making More Wikipedias
Part 6: Code, and Other Laws

If you translate this essay, please contact me.

Vote for me in the election for the Wikimedia Foundation’s Board of Directors.

Code is law, Lawrence Lessig famously said years ago, and time has not robbed the idea of any of its force. The point, so eloquently defended in his book Code, and Other Laws of Cyberspace, is that in the worlds created by software, the design of the software regulates behavior just as strongly as any formal law does; more effectively, in fact.

The point is obvious in some contexts. In the online 3D universe of Second Life, if the software prevents you from typing a certain word, that’s a far more effective restraint on speech in that world than any US law could ever be in ours. But the point is far more subtle than that; it applies with equal force to the world of Wikipedia, the thriving community and culture that our wiki software creates.

For one thing, the software decides who gets to be part of the community. If using it is clear and simple, then lots of people can use it. But, if it’s complicated, then only those who take the time to learn it are able to take part. And, as we’ve seen, lots of intelligent people don’t even understand how to edit Wikipedia, let alone do any of the other things on the site.

For another, the software decides how the community operates. Features like administrative controls privilege some users over others. Support for things like stable revisions decide what sorts of things get published. The structure of talk pages help decide what and how things get discussed.

The page design the site uses encourages specific actions by making some links clear and prominent. Software functions like categories make certain kinds of features possible. The formatting codes used for things like infoboxes and links determine how easy it is for newcomers to edit those pieces of the site.

All of these things are political choices, not technical ones. It’s not like there’s a right answer that’s obvious to any intelligent programmer. And these choices can have huge effects on the community. That’s why it’s essential the community be involved in making these decisions.

The current team of Wikipedia programmers is a volunteer group (although a couple of them were recently hired by the Wikimedia Foundation so they could live a little more comfortably) working much like a standard free software community, discussing things on mailing lists and IRC channels. They got together in person in the days before Wikimania to discuss some of the current hot topics in the software.

One presentation was by a usability expert who told us about a study done on how hard people found it to add a photo to a Wikipedia page. The discussion after the presentation turned into a debate over whether Wikipedia should be easy to to use. Some suggested that confused users should just add their contributions in the wrong way and a more experienced users would come along to clean their contributions up. Others questioned whether confused users should be allowed to edit the site at all — were their contributions even valuable?

As a programmer, I have a great deal of respect for the members of my trade. But with all due respect, are these really decisions that the programmers should be making?

Meanwhile, Jimbo Wales also has a for-profit company, Wikia, which recently received $4 million in venture capital funding. Wales has said, including in his keynote speech at Wikimania, that one of the things he hopes to spend it on is hiring programmers to improve the Wikipedia software.

This is the kind of thing that seems like a thoughtful gesture if you think of the software as neutral — after all, improvements are improvements — but becomes rather more problematic if technical choices have political effects. Should executives and venture capitalists be calling the shots on some of these issues?

The Wikipedia community is enormously vibrant and I have no doubt that the site will manage to survive many software changes. But if we’re concerned about more than mere survival, about how to make Wikipedia the best that it can be, we need to start thinking about software design as much as we think about the rest of our policy choices.

You should follow me on twitter here.

September 18, 2006

Comments

Good series of posts about Wikipedia. I would just like to add a recommendation for some “essential” reading for people interested in the sort of issues you are discussing. Check out the transcript of Clay Shirky’s 2003 ETech speech “A Group Is Its Own Worst Enemy”:

http://shirky.com/writings/group_enemy.html

Ian

posted by Ian Gregory on September 18, 2006 #

Looking forward to “Do we need new software?” :)

How about: We rewrite the entire wiki in JAVASCRIPT. That way, each member of the community can make their own rules.

posted by David McCabe on September 19, 2006 #

By the way, I don’t mean to mock you or anything. I think you bring up a very interesting point. I just don’t have anything earnest to say about it right now and happened to think of the joke.

posted by David on September 19, 2006 #

“The discussion after the presentation turned into a debate over whether Wikipedia should be easy to to use.” So, “wiki, wiki” is now Hawaiian for “quick and difficult”? Yikes - talking about removing the priori from a priori. Huh. Maybe they could rename it SoftwareAsUsualPedia - wherein we follow the strong industry tradition of doing all we can to alienate the user. Sorry to be so snarky, but I just see red after 30 years in the software industry, and it always comes down to the conclusion that the product is the next best thing to creation itself, if only it weren’t for the verdammt users!

posted by Reg on September 19, 2006 #

Of course, your general point about the social/political ramification of software decisions is correct (that perspective is one of the reasons I voted for you), but you haven’t really said anything specifically relevant to the Wikimedia projects. What software changes do you see as potential solutions to Wikipedia social problems?

I’m not sure how, specifically, the input/influence of venture capitalists on MediaWiki development poses a threat. Certainly it’s something to watch for, but I don’t think it’s problematic in and of itself. It seems like, from a software perspective, what’s good for Wikia is good for Wikipedia, et. al. Issues of control vs. accessibility will vary from project to project within Wikia. For some wikis I would expect a desire for more openness and anonymity than Wikipedia; for others, more editorial control. It seems like it will be in the interest of Wikia to make the software more flexible, and Wikimedia projects would be able to pick and choose which software changes to utilize.

posted by Sage Ross on September 19, 2006 #

“I’m not sure how, specifically, the input/influence of venture capitalists on MediaWiki development poses a threat.”

<

p>Or who to. Anyway, no-one’s managed to get anything past Brion he didn’t think was a good idea.

<

p>If Wikipedia sucks, what stops people from getting up and going elsewhere? Note that this has already happened.

posted by David Gerard on September 22, 2006 #

“I’m not sure how, specifically, the input/influence of venture capitalists on MediaWiki development poses a threat.”

<

p>Or who to. Anyway, no-one’s managed to get anything past Brion he didn’t think was a good idea.

<

p>If Wikipedia sucks, what stops people from getting up and going elsewhere? Note that this has already happened.

posted by David Gerard on September 22, 2006 #

What about russian translation?

posted by personal finance estate planning on July 14, 2007 #

This article is very interesting and written by some clever guy.:) Thank you!

posted by Gry on September 20, 2007 #

You can also send comments by email.

Name
Site
Email (only used for direct replies)
Comments may be edited for length and content.

Powered by theinfo.org.