A collaborative editor is a form of collaborative software application that
allows several people to edit a computer file using different computers, a
practice called collaborative editing. There are two types of collaborative
editing: real-time and non-real-time. In real-time collaborative editing, users
can edit the same file simultaneously, whereas in Non-real-time collaborative
editing, the users do not edit the same file at the same time. Collaborative
real-time editors generally permit both the above modes of editing in any given
instance. History of key products
The first instance of a collaborative real-time editor was demonstrated by
Douglas Engelbart in 1968, in The Mother of All Demos. Widely available
implementations of the concept took decades to appear.
Instant Update was released for Mac OS in 1991 from ON Technology. Later, a
version for Microsoft Windows was released as well, allowing real-time
collaboration across these two operating systems. Instant Update relied on a work
group server to coordinate documents updated in real time on multiple
clients. The Web 2.0 phenomenon has caused an
explosion of interest in browser-based document editing tools. In particular, a
product called Writely saw explosive user growth and was bought by Google in
March 2006. It provided simultaneous edits on the entirety of a document,
though changes from other users were only reflected after the client program
polling the server. Another early web-based solution was JotSpotLive, in
which line-by-line simultaneous editing was available in near-realtime. However,
after Google's purchase of parent company JotSpot in November 2006, the
site was closed. Google Sites was launched in February 2007 as a
refactoring of JotSpot, but it lacks the multi-user real-time abilities of
JotLive. The Synchroedit and MobWrite projects are two, more recent, open
source attempts to fill the in gap real-time browser-based collaborative
editing, though still unable to achieve true real-time performance, especially
on a large scale architecture. In 2009, Google started beta testing
Google Wave, a real-time collaboration environment which Google hoped would
eventually displace email and instant messaging. EtherPad was acquired by
Google, which allocated the EtherPad team to work within the Wave project.
However, Google announced in August 2010 on its blog that it had decided to stop
developing Wave as a standalone project, due to insufficient user adoption. After
Google released the abandoned EtherPad source code as open source in December
2009, the community took over its development and produced a complete
rewrite named Etherpad lite, which is written in JavaScript entirely and built
on top of node.js. Technical challenges
The complexity of real-time collaborative editing solutions stems
from communication latency. In theory, if communication were instantaneous,
then creating a real-time collaborative editor would be no more difficult than
creating a single-user editor, because a document could be edited using an
algorithm similar to the following: Request an 'edit document' token from
the server Wait until the server says it's our turn
to edit the document Tell the server how to edit the document
Release the 'edit document' token However, the speed of communication is
limited by network latency. This creates a fundamental dilemma: users need their
own edits incorporated into the document instantly, but if they are incorporated
instantly, then because of communication latency, their edits must necessarily be
inserted into different versions of the document.
An example illustrates this problem. Suppose Bob and Alice start with a
document containing the word Mary. Bob deletes 'M', then inserts 'H', to change
the word into Hary. Alice, before she receives either edit from Bob, deletes
'r', then deletes 'a', to change it into My. Both Bob and Alice will then receive
edits that were applied to versions of the document that never existed on their
own machines. Thus, the challenge of real-time
collaborative editing is to figure out exactly how to apply edits from remote
users, which were originally created in versions of the document that never
existed locally, and which may conflict with the user's own local edits.
The most sophisticated solutions solve this problem in a way that does not
require a server, does not use locking, and supports any number of users. UNA
and SubEthaEdit are examples of two programs that take this approach.
While these sophisticated approaches enable the best user experience, a basic
collaborative editor can also be created in a client–server model. In a
client–server scenario, one of the editor instances is assigned the role of
collaboration server when the document is opened. This server ensures that
other editors are kept in sync by determining network latency and acting
as a time synchronization server. The server receives timestamped
notifications of changes made to the document by other users. It determines
how those changes should affect its local copy, and broadcasts its changes
to the collaboration pool. In some models, the changes are not reflected on
a client until an official response is returned from the server, even if those
changes were made locally. This approach, while significantly less
powerful, allows for basic collaboration at a relatively low cost. This makes it
preferable in situations where processing resources are limited, such
as on Apple's iPhone platform. NetSketch is an example of a program that uses
this model. In the past, Microsoft and IBM have
worked to add collaboration facilities to their existing architectures.
Although marketed as real-time collaboration, these 'workspace'
approaches require either document locking, or 'reconciliation' of
conflicting changes, which is generally found by users to be unsatisfactory.
See also Collaborative document review
List of collaborative software Distributed computing
Operational transformation Conflict-free replicated data type
Distributed revision control Paint chat
Oekaki Real-time text
References