Friday, May 10, 2013

Text Collaboration

Version Control Systems (VCS — think Git, Mercurial, CVS, SVN) have been an essential part of software development since… well, since groups have been developing software ;)

Yet, in writing non-code (fiction, essays, blog posts, legal docs, manuals, etc…), VCS is a foreign concept.  Collaborating on writing is still unnecessarily difficult.  

Geeks think Git (or specifically Github) is the answer.  I’m bearish on that approach.  I think the learning curve on all existing VCS (especially distributed VCS like Git/Mercurial) is simply too steep.  Unless Github masks 90% of its features and drops much of its esoteric VCS-based lexicon, I think it’s going to be hard to get poets to collaborate using Git.

On the other end of the spectrum of existing solutions, Microsoft Word supports “Tracked Changes” today, and you can make newer versions of Word spit out a redline diff between two docs. But to call these features ”collaboration” would expose a lack of appreciation for what VCS makes possible.  Tracked Changes and redlines help people pass a doc back and forth with mildly improved efficiency, but it falls down hard when people are simultaneously editing and then later merging.

It’s going to take a special entrepreneur to crack this nut. One that has a geeky appreciation for the productive power of VCS and also a maniacal obsession for simplicity and approachability in software design. 

One feature of text collaboration that I think will be important in solving this problem is creating a clean layer of abstraction between editing and merging.  I shouldn’t have to give up my favorite text editor of choice just so I can write collaboratively with others.  VCS for code get this layer of abstraction.  None of the user-friendly solutions to collaborative text I’ve seen appreciate this nuance.  They are all vertically integrated solutions which require switching text editors.

If I had to guess where a great solution will emerge, I think it’s going to come from a startup focused on the legal market.  Legal docs are kind of like code, but written in English. The pain of collaboration is more acute in the legal field where teams of people work together on one document (in contrast to say a novel, collaborated on by no more than a handful of people). The legal field has plenty of tech-geek early adopters, but it also has mountains of trailing-edge late adopters so anyone successful in this market will have to serve both audiences well.  I’m curious… what is the state-of-the-art for text collaboration in the legal field today?

Notes

  1. thegongshow posted this