A short (and slightly biased) history of collaborative editing
Reading this piece by John Gruber, I did came across this quote by Josh Topolsky, which made me scratch my head a bit:
There is no native application for the Mac or iOS that replicates the shared document editing of Google Docs; there’s no mail application that exists for the Mac which will allow me to access my important information from anywhere in the world with or without a device in hand; there is no photo sharing service for iOS or the Mac which is as flexible or accessible as Flickr.
This sounds a little bit backwards and revisionist to me. Here’s my (by no means complete) take on what Josh calls “shared document editing”:
Like most of the shiny things we take for granted today, (non-naive, i.e. lock-free) collaborative editing originated at - wait for it - Xerox Parc, as part of the collaborative work enviroment project “Jupiter”, headed by Pavel Curtis. Besides collaborative whiteboarding and other stuff, Jupiter included concurrent (text) editing based on Operational Transforms, as documented in the paper “High-Latency, Low-Bandwidth Windowing in the Jupiter Collaboration System”.
Then - as far as I know - a lot of nothing happened. Collaborative editing was a big research topic for a while, but never really blossomed into a product, beyond academic prototypes.
In December 2002, around christmas, Domink Wagner, Martin Ott, Ulrich Bauer and me (Martin Pittenauer), decided we wanted to write code people want to use for a change (having written a lot of code people won’t use at university at that time) and that we wanted to really dive into Cocoa development. Dominik inspired us to aim high - for motivation and a deadline - and that we should try to win an Apple Design Award. After brainstorming the idea, we settled on writing a text editor. Basically because there wasn’t a code editor at the time that was written in Cocoa, apart from Project Builder (now called Xcode).
We also wanted to include Rendezvous networking (now called Bonjour), because I had seen that at WWDC 2002 and we were all really excited by it. I like to think I had the idea to marry those two objectives by creating a networked editor with shared editing features - but I might remember that wrong. The folklore at this point however is, that I was weary of circling our small desk-filled room at university, every time I wanted to ask or point out something about code. And so - out of laziness - thought networking should solve that problem.
Martin did research into if that was actually possible and found - beside other research - Xerox Parc’s Jupiter paper. I remember that we were all amazed by the simplicity and elegance of the approach. From that we started work in early 2003, finishing 1.0 of Hydra (now called SubEthaEdit) just 8 weeks later, eventually winning the ADA later that year.
To the best of my knowledge, Hydra - at that point - was the first commercial grade software that allowed collaborative editing. Most certainly the first to make it easy for mere mortals, thanks to Bonjour.
As far as I’m aware and having talked to some of the people in charge of those other projects, it is a contributing - if not the main - inspiration for the generation of collaborative editing software that followed: From “Cola” - a plugin for Eclipse written by a fellow student at TU Munich - to Gobby, to EtherPad and Google Wave. And if I’m not mistaken, the current implementation of Google Docs is powered by collaborative algorithms written by the EtherPad team, that was eventually bought by Google.
What I’m trying to say: If one would draw a family tree of collaborative editing, Jupiter would be pretty much on the top, and SubEthaEdit would follow in line as the first of a thriving eco system of collaborative text editors that we enjoy nowadays as native applications or as web applications. It’s okay to think browsers are the future - even if I think things aren’t that simple - but it’s not okay to change history to prove your point.
