Erik Möller won the board election. (He's supremely qualified and seems like a good guy.)
Saturday, September 23, 2006
Friday, September 22, 2006
Thursday, September 21, 2006
The Tree of Ténéré was a solitary acacia that was once considered the most isolated tree on Earth — the only one within more than 400 km. It was knocked down by an allegedly drunk Libyan truck driver in 1973. On November 8, 1973 the dead tree was relocated to the Niger National Museum in the capital Niamey. It has been replaced by a simple metal sculpture representing a tree.
List of famous trees
Clay Shirky on why Citizendium won't work. I'm inclined to think these problems might be solvable (not least because Citizendium content can be recycled to wikipedia -- Citizendium just needs to be a tide pool, a set of nooks and crannies where an alternate rulebook elides problems that crop up in some corners of wikipedia), but the snippiness of Sanger's response is a bit concerning.
Monday, September 18, 2006
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.
From Making more Wikipedias:
Wikipedia's real innovation was much more than simply starting a community to build an encyclopedia or using wiki software to do it. Wikipedia's real innovation was the idea of radical collaboration. Instead of having a small group of people work together, it invited the entire world to take part. Instead of assigning tasks, it let anyone work on whatever they wanted, whenever they felt like it. Instead of having someone be in charge, it let people sort things out for themselves. And yet it did all this towards creating a very specific product.
Even now, it's hard to think of anything else quite like it. Books have been co-authored, but usually only by two people. Large groups have written encyclopedias, but usually only by being assigned tasks. Software has been written by communities, but typically someone is in charge.
But if we take this definition, rather than wiki software, as the core of Wikipedia, then we see that other types of software are also forms of radical collaboration. Reddit, for example, is radical collaboration to build a news site: anyone can add or edit, nobody is in charge, and yet an interesting news site results. Freed from the notion that Wikipedia is simply about wiki software, one can even imagine new kinds of sites. What about a "debate wiki", where people argue about a question, but the outcome is a carefully-constructed discussion for others to read later, rather than a morass of bickering messages.
If we take radical collaboration as our core, then it becomes clear that extending Wikipedia's success doesn't simply mean installing more copies of wiki software for different tasks. It means figuring out the key principles that make radical collaboration work. What kinds of projects is it good for? How do you get them started? How do you keep them growing? What rules do you put in place? What software do you use?
These questions can't be answered from the armchair, of course. They require experimentation and study. And that, in turn, requires building a community around strong collaboration itself. It doesn't help us much if each person goes off and tries to start a wiki on their own. To learn what works and what doesn't, we need to share our experiences and be willing to test new things -- new goals, new social structures, new software.