See the first part of Reimagining Work: Collaborative Authorship, Coordination, and Version Control I
New Tools, New Capabilities
Tools like google docs and wikis do these tasks relatively well for distributed and synchronous tasks where the goal is to have a single resulting document. But how do you collaborate and coordinate around a document to emphasize and highlight different alternatives? How can big, asynchronous changes be incorporated? Sure, it’s possible to use “track changes” in MS Word and have multiple people add their comments and edits, but would that really be LESS painful?
Instead I’m imagining what it would be like to use a platform like GitHub to apply the capabilities and experience of collaborative coding to other endeavors like proposal development, poetry, graphic design, or really any collaborative document. If you ever visit a hackathon or take a look at an open source programming project, you’ll likely run across GitHub. It’s one of the major platforms supporting the collaborative computing around the world. It’s based on Git, which was developed to support the maintenance and development of the Linux OS kernel. It’s a control system that manages tiny information differences between document versions, and while programmers have embraced it for a variety of projects, there’s no reason it couldn’t be implemented with a spiffy graphical user interface and designed to support the version control and coordination needs of collaborative document authoring in other domains like comparative literature, science manuscript development, or foundation grant proposals.
I’m not the first to see the opportunity here. Julie Meloni in the ProfHacker column at the Chronicle of Higher Education offers this nice, gentle introduction to version control for academics aptly titled, A Gentle Introduction to Version Control.
One insight from her description is that the command line interface definitely has to be replaced with an intuitive graphical user control system for the document, revision histories, author community, and changes. I can barely remember my phone number; I’m not sure why everyday computer programmers think that everyone else has an easy time remembering all those minute task commands.
Another is this great comment to Meloni’s article from Sean Gillies:
“After reading a tweet from Dan Cohen yesterday that scholarship might emulate software development, I wonder if distributed version control doesn’t point to a future of scholarship that’s less about editions and more about “diffs” or edits.”
Science Fiction author and journalist Cory Doctorow discusses the process of archiving and version control using Git in his book, Context: Further Selected Essays on Productivity, Creativity, Parenting, and Politics in the 21st Century. He describes his desire for a tool that can capture what’s happening as he writes, what his influences are, and bind that to the document itself–all while managing the different versions of his manuscripts.
But in the digital era, many authors work from a single file, modifying it incrementally for each revision. There are no distinct, individual drafts, merely an eternally changing scroll that is forever in flux. When the book is finished, all the intermediate steps that the manuscript went through disappear.
It occurred to me that there was no reason that this had to be so. Computers can remember an insane amount of information about the modification history of files—indeed, that’s the norm in software development, where code repositories are used to keep track of each change to the codebase, noting who made the changes, what s/he changed, and any notes s/he made about the reason for the change.
So I wrote to a programmer friend of mine, Thomas Gideon, who hosts the excellent Command Line podcast (http://thecommandline.net), and asked him which version control system he’d recommend for my fiction projects—which one would be easiest to automate so that every couple of minutes, it checked to see if any of the master files for my novels had been updated, and then check the updated ones in.
Thomas loved the idea and ran with it, creating a script that made use of the free and open-source control system “Git” (the system used to maintain the Linux kernel), checking in my prose at 15-minute intervals, noting, with each check-in, the current time-zone on my system clock (where am I?), the weather there, as fetched from Google (what’s it like?), and the headlines from my last three Boing Boing posts (what am I thinking?). Future versions will support plug-ins to capture even richer metadata—say, the last three tweets I twittered, and the last three songs my music player played for me.
There’s a GitHub release of Flashbake, the code for the Git-based tool, that can be downloaded, tinkered with, and added to. The thing that Flashbake does well is adding meta-info to the writing flow, capturing a small snapshot of what’s happening. [here’s the original project page]
Gina Trapani, has a fantastic getting started guide to Flashbake at Lifehacker, along with a whole bunch of little bits to help you decide if it’s worth the learning curve. Like she says, you have to be a little adventurous and not mind running a script or two.
Organizational Design 1.0
Expect more tools like Flashbake–ones that make it easy to cache fine-grained changes to docs and select from multiple threads of that work. My guess is they will be the basis for more user-friendly text authoring collaboration platforms in the very near future, once collaborative authoring and distributed work starts to be more widely utilized.
The important thing about Git and similar tools is that they support a wide range of organizational structures for getting work done. I’m a little out of my expertise here–in understanding how the technical specifics support different org styles–but it’s apparent that Git and some other versioning tools support centralized, decentralized, hierarchical, heterarchical, and everything in-between forms of coordination. What matters is the document, the changes that get made, and how those changed get committed or accepted to the latest version. Pull, the ability to draw from a master repository, and push, the ability to add to a master repository, are two of the most important permissions.
It’s not difficult to imagine scenarios where a team is working on the same document, starting with content, editing, revising, developmentally editing, and copy editing all at different times in different places. Obviously, there needs to be the basic content before the latter stages of editing can begin. But it supports is simultaneous editing by multiple people where some changes can be accepted and others rejected, not wholesale edits or versions. These fine-tuned edits are important because they can mean that a host of authors can contribute and that no contribution is too miniscule. What’s kind of cool is that six different people can be adding a sentence, and then when it comes time to merge versions, one can select which of the versions of those sentences to accept into the final.
To wrap up here’s some final characteristics of distribted version control systems:
- A Distributed Source Control System (like Git) means that it’s easy to access a central repository.
- It’s possible recreate a project from any copy, and branching a repository means that duplicates of work can be built upon and modified without affecting the original. A difference command (diff) allows one to compare changes made between file versions.
- One can work totally offline on their local repository and push changes to the central repository later.
- Permissions are suited to the tasks and can be shaped around different organizations, teams, and roles.
- The contributions that individuals form another “social” layer–like following people or keeping track of their history.
- The history of changes made to the repository is one measure of productivity. Plus, using centralized file organization tends to increase productivity by minimizing the transaction costs of exchanging files and notifying others of changes. The transparency (who made what commits) is also a big motivator for participation and productivity.
It takes some effort to get something like this up and running. To actually start doing collaborative coordination around documents then involves getting others onboard, and that means building the cultural tools to support ongoing practice. I have no doubt that a small group of dedicated individuals could do it; many probably already have. My hope is that by writing this article, people share more examples of how Git and other versioning systems are developing as models for reimagining collaborative authorship, coordination, and work in domains other than computing.
Comments on this publication