A scientific manuscript will carry in the majority of cases more than one author. In this post I want to describe some of the technical problems associated with multiple authors.  So nothing here about the sociological and psychological aspects of dealing with co-authors. The book, by the way, discusses these aspects in some detail.

Writing after the facts
If everything that had to be done, has been done, all research has been carried out,  all calculations have been performed and all results are available, writing up is a simple process. The first author – and only he – works on the manuscript (Latex-type, or in case of real emergency MS-Word) and after he has finished, the correction process can start. I have explained in my book in detail how to deal with this correction process. But here I want treat a new situation.

Writing in an earlier stage
The start of the writing of a manuscript can also take place much earlier. In such a case the writing is part of the scientific process. By having to write things up, authors shape and sharpen their ideas. They suddenly realize what new experiment has to be done. Co-authors suddenly find out that they fundamentally disagree. This constant exchange of opinions and of new evidence  is a fascinating collaborative process, but technically very difficult to implement. You do not want to end up in a situation where authors continuously mail around changed manuscripts and wait – or even worse do not wait and continue correcting. The problem is called version control, and  is the nightmare of every company developing software. Developers editing at the same time the same file. With disastrous results. Updates are missed. Bugs are surviving for ever or newly introduced .

Shared web pages
A solution could be that one is always working on the latest text and text collisions do not occur, because the changes are saved fast. In addition there should a good log of the changes. Wiki’s‘  work that way. But wiki’s have  lots of problems associated with them. When used for frequently updated source code (complicated like C++ or simple like Latex), external viewer programs are needed. These viewers can only be developed for simple source code. And indeed latex plug-ins for wikis exist, but they are not useful for real math. And they are also clumsy.

Google docs
In a next post I have lots of things to say about Google and Google Docs. But it suffices tomention here that it can only be used for flat text, MS-Excel-type spreadsheets, and MS-Word-type documents.

Version Control
In software industry one has found a number of solutions to version control. Subversion (free open-source software) is one of the most popular implementations. It is a sophisticated system that needs a (Subversion) web-server (usually a Linux/Apache combination) . Every developer has a computer program running on his computer, called a Subversion client – for instance TortoiseSVN (free open-source software). Developers work on local copies that can be updated to the web-server repository as often as they like. All changes are logged, and reversible. If two people have updated the same old file, Subversion does it best to merge the two changed copies. In case of conflict (people having worked on the same line of code) the server requests human intervention.
    I have decided to test whether or not it is helpful to use Subversion for Latex files for the collaborative writings in our group. For the amount of about 10$ a month hosting companies supply Subversion services. After having bought such a service and after having downloaded TortoiseSVN our group is now in business. I will report soon our experience. maybe we will buy our own server (a couple of hundred dollars)  in the future.

Follow