My documentary on the evolution of Wikipedia’s heavy metal umlaut page has been the most popular screencast I’ve made. It investigates the sociology of Wikipedia-style collaboration, but it also explores the dynamics of the underlying version control system.
To make the screencast, I first recorded a frame-by-frame walkthrough of all the revisions of the page. Then I loaded that movie into QuickTime and captured the raw footage, which I ultimately edited and narrated. The purpose of this two-step dance was to gain control of the time line. When I made the second recording, QuickTime’s scroll bar gave me random access to individual revisions and enabled me to animate their flow both forward and backward in time.
As you watch the page morph, you can’t help but wish that every Wikipedia page — and indeed, every living document — worked in a similar way. I mentioned that wish on my blog last week, and Andy Baio, who runs a popular link site as well as a collaborative event database, amplified it. He sponsored a contest that offered $150 for a script that would animate Wikipedia revision flow.
A week later there were four implementations to choose from, with three based on Greasemonkey, the wildly useful framework for writing Firefox extensions. My favorite of the entries, from Dan Phiffer, is a tour de force that seamlessly extends Wikipedia.
Many factors conspire to produce this astonishing and delightful outcome. One is Wikipedia itself, with its deep memory. Another is the blog culture, which enables ideas to flow without friction. And of course there’s the open source culture, which provides shared frameworks such as Firefox and Greasemonkey, and inspires people to share what they create using these frameworks.
It’s a highly productive ecosystem. And yet critics are right to ask whether that productivity is healthy or sustainable. Greasemonkey scripts are basically screen-scrapers that depend on undocumented HTML idioms. Those idioms can change at any time, as happened recently when Google tweaked Gmail and broke several scripts.
“Greasemonkey is a cool idea,” writes developer/blogger Bill de hÓra, “but these scripts are so fragile, it’s not funny.” He likens Greasemonkey to a house of cards. Analyst Stephen O’Grady responds that while card houses are easy to knock over, they’re also easy to rebuild. And he noted that the broken Gmail scripts were, in fact, quickly repaired.
I see both sides of this debate. Interfaces that are XML-based and schema-backed can lay a kind of contractual foundation for layered extensions. This idea applies equally to Web applications and to smart documents that use the Microsoft or OpenOffice XML formats.
Formal contracts aren’t just stabilizers, they’re enablers. If documents were predictably structured, for example, we could visualize their change histories in even more compelling ways. Yet there’s a reason why Wikis and Greasemonkey are gaining traction, along with the RESTful approach to Web services.
Contracts are awkward beasts, and they generate a lot of friction. Of course, some friction is a good and necessary thing, but if we can’t make contracts easier to use, the grassroots ecosystem will continue to route around them. And that’s not in anyone’s best interest.