version control: writers vs programmers

TidBITs 839 leads with Adam Engst's article, Calling Mac Developers: Request for a Collaborative Editor, in which it notes that he and Jason Snell (director of Mac Publishing and editorial director of Macworld):

sat down and created an RFP -- a request for proposal -- that outlines exactly what we're looking for. It's not as detailed as a specification, of course, but it describes in broad strokes the kinds of features that organizations like TidBITS and Mac Publishing need.

This RFP -- for a proposed application called GroupEdit -- came about because neither Snell nor Engst were entirely happy with extant collaborative writing tools. (A web-hosted tool called Flow, from Near-Time came close, as Engst noted in an earlier article on this topic, but Flow doesn't appear to exist any more.)

Having recently spent more time than I'd like trying to find collaborative tools that half-way work, let alone work elegantly, I'm all for the idea.

The devil, of course, is always in the details. The RFC, for example, argues that GroupEdit

should provide its own interface to the files rather than relying on the Finder, since the link between the Finder and independent applications is too weak for actions other than opening.

Which instantly sets me to wary. My beloved Spatial Finder may be a pale shadow of its Mac OS 9 self, but it's still my preferred way of organising, finding and dealing with the 37.26 gigabytes worth of files I have in ~/.

I'm not going to fall in love with any tool that acts as if it knows better than me how to organise my files.

(And yes, this means I've never fallen in love with iTunes or iPhoto: I tolerate and use them but have never fallen in love with them. Dammit, I still miss the multi-window friendly UI encouraged by SoundJam MP, banished from its iTunes progeny for no apparently good reason.)

More generally, the GroupEdit RFP and the associated comments read like an effort to make version control tools (such as Subversion) deal with the specific concerns of editors and writers as well as they deal with the concerns of programmers.

Which has always struck me as the nub of the problem. As Snell himself notes in the comments:

the problem with source code version control is that it's often implemented line-by-line, which does editors no good.

More generally, the units of meaning that programmers are seeking control over with tools like Subversion aren't the same as the units of meaning writers and editors are seeking control over.

A paragraph isn't the same as a function call, even if both are delimited by line-ending characters.

And a better goal for GroupEdit is to be a collaborative tool built, from the ground up, to deal with the specific concerns of editors and writers. Even if this means setting aside the concerns of programmers (and others) whose structured text files have different purposes and (consequently) different structures.

Of course, that's a bigger, more expensive task. And, given the background of folks like Snell and Engst, even if the challenge is taken up with alacrity, the end result will likely have novelists and screenwriters kvetching that GroupEdit is obviously aimed at technical and documentation writers and doesn't pay any attention to their specific concerns.