The Meta-Story: How Wired Published Its GitHub Story on GitHub

Earlier this week, Wired published a story about GitHub, the "version control" site that's taking the internet by storm. But it was more than just a story. It was an experiment in version control. In addition to publishing our GitHub story on Wired, we published our GitHub story on GitHub.
Image may contain Plush and Toy

Earlier this week, Wired published a story about GitHub, the "version control" site that's taking the internet by storm. But it was more than just a story. It was an experiment in version control. In addition to publishing our GitHub story on Wired, we published our GitHub story on GitHub

GitHub was originally designed for software developers. It lets programmers upload code and share it with other developers. It keeps track of who made what changes where. And it helps merge all those changes together. It "controls" the various versions of an open source software project.

But nowadays, it's also being used to oversee stuff outside the programming world, including DNA data and Senate bills that may turn into laws and all sorts of other stuff you can put into a text file, such as, well, a Wired article.

At Wired offices, you hear the question over and over again as we work on stories like the one you're reading now: "Are you out of the story? I want to go in." We have a version control problem. We publish Wired.com on WordPress. It's a decent publishing tool, but when two people change a story at the same time, one of them doesn't get her changes onto the final story.

We published our GitHub story on GitHub because it was meta-cool. But we also did it to see if GitHub might actually help us solve our problem.

When we uploaded the story to GitHub, we published it under a Creative Commons license, and this allowed GitHub's 1.3 million users to do what they do best: download their own version of the article -- called a fork in GitHub parlance -- mess around with it, and then offer the changes back to us via the website.

Within a few hours, the first change came in: a typo fix. With the push of a button, the error was gone. Then someone translated the article into Spanish. And we were elated. This was collaborative Nirvana.

More and more fixes started coming in. The story was published at 3:30 a.m. Pacific, and by 9 a.m., there were about a dozen changes. Soon we were nearing 20, and this is where things started to get complicated.

People were fixing the same problem over and over again. Some of their changes couldn't be merged automatically, but they included good additions that should be considered. GitHub lets users describe the changes they're making, but not everyone is precise when doing this. So you need to check closely to see what is really being changed.

Then we noticed a formatting issue. Because we'd used Windows encoding in the text file of the story, our GitHub forkers were accidentally turning apostrophes and smart quotes into strange new characters, and this was polluting our results, making it hard to see the real changes.

Finally, a troll popped up. He didn't really improve our article in any way, but he did add what appears to be -- well, we don't quite know what it is. This was starting to feel like collaborative hell.

But we have to cut GitHub some slack though. GitHub was built for software development, not collaborative article editing. Pretty much all of the problems we had -- even the troll -- were standard issues you'd expect when you're testing out something brand new.

"For published articles, we're not yet optimized for that," says GitHub founder and CTO Tom Preston-Werner. But he does want to add features that will make this work better.

And here's the thing. Just about all of the changes that were submitted were great. The readers were thorough in a way no single editor could ever be, uncovering missed spaces, substituting "an" for "a," pointing out that our description of Ruby on Rails as a language was incorrect, and digging up an embarrassing number of typos.

And the contributors were cool. They stuck with it when we screwed up or missed fixes, they were smart and good natured. In short, great people to work with. And we think that this issue of version control is going to be increasingly important to the future of collaboration as people work together not just on software and books, but on physical objects as well.

In all, the experience was the strangest mixture of excitement and tedium.

"Welcome to the world of collaborating," says Preston-Werner.