We are writing a manuscript with 7 people. I am not sure what is a good tool to write a paper collaboratively. Other than overleaf or sharelatex which cost money.

What do you do if you have technology inclined collaborators?

  • 7
    OverLeaf has a free subscription option and it includes collaboration.
    – buzjwa
    Nov 2 '17 at 11:44
  • This question might be more suitable for softwarerecommendations.stackexchange. Or it is not clear enough. What aspects of collaborative scientific writing specifically do you worry about?
    – Trilarion
    Nov 2 '17 at 13:38
  • 2
    @Trilarion I think that in many domain-specific use cases recommending softwarerecs.se is a horrible idea. It's like saying "if you need a book on linear algebra, do not ask on mathematics.se, ask on bookrecommendations.se, where experts on books can give you their opinions". Nov 2 '17 at 13:42
  • @FedericoPoloni I agree partly. It might be a border case although the argument also goes the other way around like "If you want to find out what formats are there for writing your new linear algebra book in, don't ask experts on linear algebra, ask the ones who produce the books." I think the biggest problem with the question is actually the missing context.
    – Trilarion
    Nov 2 '17 at 13:52

Git! Or more generally, version control systems, if your co-authors are technically inclined enough to know/learn how to use one.

If not, probably... write the text in google docs first and designate someone who will do the formatting in the latter stages, and decide what to cut to make the page limit.

  • 2
    The problem is not everyone is capable of using git. Think about the scenario of very senior PIs
    – 0x90
    Nov 2 '17 at 11:00
  • 2
    I don't think git is a good answer. What format would you be writing in? If the answer is Latex, then getting everyone's environments consistent is going to be a nightmare. Even if this works, there's no facility for commenting on text. Google Docs is a far better answer.
    – MJeffryes
    Nov 2 '17 at 11:04
  • 6
    @MJeffryes What do you mean by "getting everyone's environments consistent"? Latex is fairly well backward compatible, and unless you use bleeding-edge features in packages it is difficult to run into problems. In my experience this is a non-issue, in practice. Nov 2 '17 at 11:24
  • 2
    Also, there are several ways to include comments, ranging from \newcommand[1]{\comment}{\textcolor{blue}{#1}} to specific packages. Nov 2 '17 at 11:28
  • 1
    @nengel Sure, if everyone is already using git and Latex then this might work for you. But I think if someone is looking for suggestions for how to do this, then they're probably not in that position.
    – MJeffryes
    Nov 2 '17 at 12:12

Short answer: it is a pain, unless you can all agree to use a single way of working, which is unlikely. I will describe my own workflow below in case it gives you ideas.

In my experience, each author wants to use their own tools. Depending on the field this is usually Word or LaTeX. In biophysics, almost nobody uses version control and most of the people I worked with are not willing to learn it.

I am not saying you should do what I do, or claiming that this is the single best way, but my workflow is as follows:

  1. I write the paper as very basic LaTeX (almost plain text). I use version control.
  2. I paste it into libreoffice and do some basic formatting (otherwise some co-authors will start "correcting" the formatting). I email everybody the draft of the paper.
  3. Co-authors suggest changes, all at the same time. I ask them to highlight or track changes and, importantly, leave comments and tell me WHY they propose a change. You'd be surprised how many people make changes without letting you know why.
  4. I manually merge the changes of all authors into my version of the paper, and deal with conflicts (if necessary by discussing via email with the co-authors in question).
  5. Repeat from point 2 until done. For me, typically 2 or 3 iterations are enough but with difficult people this number can go up dramatically.
  6. Convert paper to final format (decided by journal requirements). Make sure you do this only once, at the very end.

If this sounds complicated you are right. But to me this is the least complicated way unless everybody agrees to use the same software and version control (which is rare). Especially if reference management software is involved it can become a terrible mess when co-authors start to add/mess with references.

The main advantages of this method:

  • There is a single current version of the paper and I (as first author) always have it.
  • I can use version control, even if nobody else does.
  • Everybody can use whatever tools they want.

I found that one person being in control of the writing and merging avoids endless discussions and ending up with multiple versions of the paper.

If people take too long to reply I send them an updated version with the others' corrections: this will show them that others have done their job and hopefully incite them to reply as well. Also, some of their potential comments may already have been addressed in the new version.

  • Great answer, but the following part I disagree with. "You'd be surprised how many people make changes without letting you know why." Some changes are just self-evident, assuming you're tracking the changes and you can see the diff. Nov 2 '17 at 16:14
  • 1
    Of course I am not talking about those changes. Many changes are indeed for obvious reasons, but other changes are opinion based or simply unclear. Without comments no discussion about the opinion or reason for the change is possible. Also, what is clear/obvious to you may not be obvious for everyone.
    – Louic
    Nov 2 '17 at 16:32

Use Google Docs or a Wiki (see http://www.wikimatrix.org/ )

Agree on a detailed style guide. Agree on one voice. Decide on who should have the final say over edits. Know the requirements from your desired publisher, or journal. And decide on who should format everything. It will be more consistent if only one person does that part too.

To use the wiki matrix, start with the choice wizard, then refine your choice based on special features you might need, like MathML, file uploading, and/or a markup language that can easily be exported to LaTeX.

To track changes, make the "Recent Changes" page of your wiki your home page, or turn on email notifications assuming you don't mind the deluge of emails.

Your manuscript may not look that great on a wiki, but that can be a benefit too. There is no point in obsessing over the formatting of the content until the content has mostly been finalized.


In case you are working with LaTeX, there are two very good (free!) sites offering collaboration functionality: Overleaf and ShareLaTeX. In fact, they are in the process of merging their services. Overleaf apparently does not restrict the number of collaborators. Additionally, it features git support!

Both offer online compiling (no need for local installation). You can simultaneously edit your document with several authors at once and even track their cursor and what they type. It has a chat, comments and version history. Which one of them you are using will most likely not matter, they have a very similar feature list and will eventually become one.

Downside: One of you might have to purchase a paid subscription to have a higher number of collaborators. But usually you get a better deal when you are from a university or similar institution. Referral links (at least on ShareLaTeX) can also get you to a higher number of collaborators without paying, but you will need to send referral links to your co-authors.

I recently used ShareLaTeX to work with one co-author and it was really pleasing. I even use it for myself, just because I dislike most Tex editors.

  • 1
    Overleaf allows you to access the project as a git repository, which is very useful if some authors like the on-line interface and others prefer to edit the files locally. Some see this as the single best feature of the platform...
    – zrnzvxxy
    Nov 2 '17 at 14:01
  • @chardmeier Thanks, I do not use Overleaf myself. I added some info about it to my answer.
    – Ian
    Nov 2 '17 at 14:15

From my experience and to elaborate on @buzjwa's comment:

I have used overleaf to collaboratively write papers multiple times. As mentioned above, the free version allows an unlimited number of collaborators and even contribution without an account is possible (more on that below). And while overleaf is far from perfect, I have not yet found a better option, especially when cooperating with researchers form other fields.

After you created a free overleaf project you get (long and cryptic) links to read-only and read-write version of the document that you can pass out to contributors. Please note that the free version does not support protected repositories, so everyone who gets his hand on that link can view/ edit your document.

Additionally each overleaf project has a git repo that you can check out and a rich text mode. This allows people with different preferences to work together. (I for myself prefer working offline and pushing my changes with git.) One downside of this is that git implementation used does not support branches and tags.


I routinely am a co-author on papers with 10-16 authors, as is the norm in my field (biology/molecular biology; I just counted, and in the past 12 months, about a dozen papers, I averaged 11.1 authors). The process I use is by no means ideal, but it is very much a standard in my fields.

With more than three or four authors, it's not expected that most will be heavily involved in the writing process. A "middle" author -- that is, one other than the last author (senior) and first author (who did the bulk of the work) -- typically gets a near-final draft and is asked for input on that. They'll often find a block in the Methods and the Results section commenting something like "JESSICA - please fill in details of mouse examinations" or something like that, and we expect a detailed couple paragraphs there, but the implication is that aside from their specialty, we're looking for typos and minor changes and not much more.

(If a middle author has serious concerns, of course we pay attention. But if the draft is accurate and reasonably well written, it's not expected that a middle author will offer major revisions.)

That means that you're really doing the bulk of the manuscript prep with two, or perhaps three, main writers, which makes life a lot easier; which is important, because what just about everyone does is pass Word documents back and forth and use "Track Changes". Sometimes we use shared folders (Dropbox equivalents); sometimes we use email. In either case we typically keep a list of drafts; one set of revisions come back, we save as "v3" and then "Accept revisions" and call that version "v4", and so on.

We never work simultaneously. One person makes all their comments, tells the next "Your turn", and waits until all those changes are made.

Eventually, usually after three or four passes, this turns into a draft that can go out to middle authors. Here, because we don't expect major changes, we typically do get simultaneous changes, and just incorporate them all together.

We often send to the couple of authors who we know are likely to make more changes first (Jessica is really good at identifying logical flow problems; James is British and has language eccentricities), incorporate changes from them, and after that send to the people who are likely to just catch typos.

Again, this is all using Word Track Changes, which I know has many problems, but it's a de facto lowest common denominator; everyone has it, everyone knows how to use it, it's easier than trying to teach one (or 11) people how to use Git or whatever. More computation-heavy fields probably use different approaches. When I'm a middle author on a paper, this is what I expect, and it's what I invariably get. It sounds like it should be a mess, but since it's what everyone is used to it generally goes pretty smoothly. It's been years since the logistics of working with co-authors has been an issue for me.

  • I can suggest a change: in my experience, this kind of workflow works better if you keep the same name for the most recent version of the main file (e.g., paper.tex and get into the habit of renaming old versions (e.g., paper_2017-11-02.tex), rather than renaming new ones (paper_v1.tex, paper_v2.tex...). It is counterintuitive, but it works. Nov 2 '17 at 13:40
  • 2
    From experience, I can confirm that this is a common way of doing things, and it “works”. But OP wants to know how to do this “effectively” and, sorry, this isn’t it. It’s an objectively terrible way of writing papers, and we only use it because people are too lazy/entrenched to put in even minimal effort in learning better tools. Of course this isn’t a commendable mindset, and it especially makes no sense from a time saving perspective. But here we are. Nov 2 '17 at 13:49
  • 1
    @FedericoPoloni If you already using latex, using git spares you of all that and easily deals with conflicts. I cringe everytime I get a new .docx with prefixes/suffixes on my dropbox. Nov 2 '17 at 14:05
  • @FábioDias Yes, I agree with you that this suggestion is a "poor man's git" (a "git's git"?). But, in a workflow where people do not use git and rename their files manually (and for many reasons they do not wish to change), I think it's good to suggest to switch from 'rename new files' to 'rename old files'. Nov 2 '17 at 16:08
  • @konrad-rudolph I absolutely agree that this is not an efficient approach. But if you factor in the time it would take to teach 11 people to use Git -- or even Google Docs! -- and then repeat that with a new group of co-authors a dozen times in a year ... sticking with what works is the best use of my time.
    – iayork
    Nov 2 '17 at 17:54

Not the answer you're looking for? Browse other questions tagged or ask your own question.