Writing a math paper on a wiki

Combining a couple of previous topics, I was wondering: is there a good platform for writing a math paper on a wiki? This seems like a desirable goal, both for small groups of collaborators and for any MMORPG’s (massively multiplayer online research project groups), and I’ve never seen such a thing, but I’ll hold off on crankily complaining about its absence until the blog readership has had a chance to tell me whether it’s out there.

Here’s what such a thing would have to include:

  • The ability to take in proper TeX code, including packages, bibtex, anything else people use in arXiv papers, and produce some kind of reasonable preview. Obviously, it wouldn’t have to be precisely what LaTeX would produce, but it would have to be readable. Clearly this is somewhat possible, since WordPress and Wikipedia do a decent job with it.
  • The ability to sync with a local copy quickly and easily (hopefully with something roughly approximating svn).
  • All the usual wiki features (user control, full history, etc.)

I feel like this is not a lot to ask, since all aspects of it seem to be in wide use in different programs, but I’ve never seen the whole package brought together. Am I just missing out?

38 thoughts on “Writing a math paper on a wiki

  1. Boris-

    Of course, that’s what I end up doing, and it works fairly well, but I think having an interface where one can edit and preview on the web would also be very useful, and would be more and more so as you try to incorporate more people into your projects.

  2. Steve-

    That is cool and I’m gald you pointed it out, but it’s missing the syncing features that are crucial to something like this actually functioning. This definitely makes me inclined to believe we are very close to this all coming together and being amazing, but we aren’t quite there yet.

  3. Yeah, ScribTeX is missing a few crucial features. (But it’s new, it only started in 2009, and run by just one guy, James Allen. Its source is available, BTW, if someone wants to chip in.) There’s also MonkeyTeX but last I checked it wasn’t very useful either.
    As you said, we aren’t quite there yet.

  4. Ben,

    Have you looked at DropBox? (https://www.getdropbox.com). It’s a sort of version control/synchronization program that includes a web interface. The screen cast makes it look really quite slick, and while I haven’t actually used it I know other mathematicians who use if for their collaborations. I think its free to use for less that 2Gb of stuff.

  5. I’d like to know something closely related, which there should be an easy answer to- how do you include in-text graphics in wikipedia? Say I want to put a Skein relation in the middle of a sentence- how do I do that with Wikipedia? What about a longish list of local moves in graphical form?
    I want to write an entry on claspers, for instance, and without the ability to include graphics in a sensible way, it’s just not going to work…

  6. Steve,

    For Macs there’s SubEthEdit, a real-time collaborative text editor which supports LaTeX. I’ve never tried it, but it’s gotten some good reviews, and while not free isn’t very expensive (29 euros).

  7. My instantaneous reaction is: why would you want this? I think that the software model, represented by version control systems, is much closer to how one would actually go about writing a collaborative paper. What would be the advantages of having a Wiki-like system?

    When Boris suggested git or svn (incidentally, I recommand bazaar), Ben replied:

    “Of course, that’s what I end up doing, and it works fairly well, but I think having an interface where one can edit and preview on the web would also be very useful, and would be more and more so as you try to incorporate more people into your projects.”

    Why? How could this be better than downloading a local copy and runing it through LaTeX and then viewing it with your own previewer?

    As I can’t think of any advantages of the online system, let me outline why I think that version control is the best system. Firstly, for anyone not clear on what I mean then the system is as follows. You have a central repository containing all the files and all the history. Authors can “check out” a copy of this and work on it on their own local machine. When they are happy with what they’ve done, they can “commit” their changes to the central branch. Others can also work on the documents at the same time and there are systems in place to ensure that the commits work properly.

    The main advantage of this system for me is that when you are working on the paper, you are using your local machine. This means a significant increase in speed, you can use whatever local system you like for editing your document with whatever shortcuts and macros to make life easier for yourself, you can work offline and it doesn’t matter if your connection dies in the middle of a session.

    Papers tend to be longer than Wiki articles and tend to take a little more thought (at least, they ought to). I would suspect that the average “editting session” for an article is significantly longer than for a Wiki-article.

    Of course, one should divide a document up so that collaborators can work on sections without disturbing what other people are working on, but you’d have to do this for a Wiki anyway.

    There’s a big push to send everything “onto the cloud” and work completely online. I frequently switch between about four different computers for work depending on where I am so I need to be sure that I can easily transfer all my documents from one to another. With version control, this is no problem whatsoever. One of the machines is permanently on and permanently connected to the internet so that is my central repository. Then whenever I use one of the others, I simply update it from the central machine and once I’ve done that then I’m ready to work, even if my internet connection goes down (as it often does).

    The documentation for bazaar outlines several models for version control. There’s a lot of possibilities and someone not used to the ideas might not realise all that can be done.

    Just about everything that I do on computers these days is version controlled. It makes life so much easier.

  8. Thanks dunfield for pointing out Dropbox! It works really well. It doesn’t support real-time collaborative editing like etherpad or SubEthaEdit, but it’s so smooth and well integrated that immediately loved it. My friend Nick pointed out to me that one can use Dropbox and SubEthaEdit together (in a bit of a kludge) to allow real-time collaborative editing with latex support. Now we just need to get these things seamlessly integrated…

  9. @Andrew Stacey:

    The advantage of having an online collaboration tool is that you don’t need to install software locally. Instead, you just “start” the application by going to a certain URL in your browser.

    Installing software locally is easier on some systems than on others. It is never hard, really. Still, from what I see, people are much more likely to try a new application if it doesn’t require installation. Perhaps an online collaboration tool for LaTeX would contribute to make it popular.

    Personally, I agree with you and I’d hate to give up my local customized environment.

  10. Andrew-
    I feel like this is like asking “why would anyone use gmail when they could just have a POP client on their home computer.”. Which is how some people feel, but I think most of us have found gmail pretty useful.

    Obviously, I’m not willing to give up the convenience of having an svn-type version control on my own computer. But sometimes I’m not on my own computer; sometimes on my phone, sometimes I’m traveling, sometimes I’m on a public computer for whatever reason. It would be rather nice to be able to use a web interface then.

    I think a more important point us that “tech savvy enough to correctly use svn” turns out to be a surprisingly high level of tech savvy. If you were going to have a massive online collaboration, telling everyone they had to install and set up svn first would pour a big bucket of cold water all over it.

  11. @Ben (since that seems to be the syntax for replying)

    gmail? What’s that? Never heard of it.

    I have webmail for each of my email accounts and I occaisionally use it, but it’s extremely irritating to have to be working over an internet connection and without access to all the nice utilities that I have on my actual machines. If I have an internet connection then I’d much rather ssh in to my work computer and read email from that. Much easier, much more robust, much more secure.

    SVN is not the only kid on the block when it comes to version control. There are other systems out there. I agree that some are more demanding in tech-savvy-ness than others (anyone here ever tried tla?) but SVN is fairly high on the savvy-ness list. Bazaar is much simpler (I tried SVN first but hated it for all of 20 minutes before switching to BZR. Much simpler).

    I also agree that some sort of centralised system would be of some benefit here to lower the entry requirements. I’ve some thoughts on that, but they’re not coherent enough to write down yet.

    But there’s a danger that two useful things are getting confused here. Online collaboration tools sounds like a fantastic idea. The combination of a graphics tablet, a real-time collaboration system, and a decent connection sounds amazing – and quite frankly I’d ditch LaTeX from this part. For that, then I’d recommend a look at jarnal. I haven’t tried it yet, but if anyone wants to experiment I’d be happy to be the “other party”. However, this isn’t writing papers. This is doing the maths in the first place. Writing the papers comes later and very rarely needs real-time collaboration. Version control is much more important here.

    By the way, version control is exactly what you need when you’re often changing computers. Keeping all the different systems in step is so much easier. I even have all my rc files version controlled so if I discover a new feature in emacs or zsh then I can easily propogate it to all the machines that I use. And if I can’t get a signal, then I can just work with the local copy and upload my changes later.

  12. andrew-
    I think you’re not taking into account how different a computer user you are from the average mathematician. I recognize that this is not something of much use to you, and you make good points about why this is so. But I think it would be useful to many other people, roughly the set of people who’ve found gmail useful, which is 90% or so of the people I know, me included.

    These tools don’t have to be one-size fits all. That’s exactly what I’d like to avoid. Rather I want a system where you can just use the version control side of things and somebody else can just use the web interface, and I can use whichever’s convenient, all to work on one document.

  13. I don’t know if Instiki can handle things like defining new LaTeX macros, cross-referencing labelled equations and such. I played with it some time in 2007, and it was pretty easy to get running and to use, but the details of the experience have faded from my memory.

    Stupid memory, always fading and stuff.

  14. in terms of collaborative editing, i’m a fan of using darcs for version control and using dropbox as a transparent way of hosting the data. In particular, dropbox in effect makes the server version visible locally, and I sink my local edits with the dropbox version. I’m really happy with it

  15. I don’t know if Instiki can handle things like defining new LaTeX macros

    no, that not,

    cross-referencing labelled equations and such

    That, yes, thanks to Jacques Distler’s math addOn.

    We are using his instiki setup quite successfully, I’d dare to say, for collaborative work (of diverse kind) on the nLab.

    As you know.

  16. @Blake and Anon,

    Instiki’s great for what it is: a proper math-enabled Wiki (i.e. it does MathML rather than pngs). But Blake is right, you can’t define macros. It does do cross-referencing on equations and definitions within a page, though not across pages (I think), and even then there’s the odd “feature” that one has to be aware of! The [n-lab](http://ncatlab.org/nlab) is, I believe, the largest Instiki installation at the moment and it seems to be holding up pretty well.

    But although Instiki does do LaTeX exports of its pages, it doesn’t feel like the sort of thing that Ben is looking for. I wouldn’t write a paper on Instiki.

    A paper and a Wiki article are two completely different things. They are used in different ways and I would guess that it is extremely difficult to write a single article that “fits” both set-ups. Maybe I’m unique in this, so I’ll make this personal rather than general. When I properly read a paper then I rip it apart, I pour over it, I turn it this way and that to make sense of it. When I read a web article, I glance through it looking for the basic idea and for the specific bit that I’m interested in. I flit from bit to bit, easily getting bored, and easily ignoring the finer details. Contrary to what might be expected, I actually read web articles in a far more linear fashion than research articles, partly (but not mainly) because sticky bits of paper are far more versatile bookmarks than anything that can be done online as yet (that I know of).

    It’s a bit like the difference between a seminar and an article. You wouldn’t just read a research article at a conference, and you wouldn’t publish the actual text of a seminar in a research journal (even proceedings are very rarely the actual text of what was said). They are different things for different purposes

    Of course there are overlaps and life is more complicated than I’ve made out. I’m exaggerating for effect (I’ve learnt that I need to say when I’m doing this!).


    Thanks for the compliment (I think!). I’m quite happy with the basic tenet of having an online system that is genius-proof (far harder than idiot-proof) and really easy to use. But I really don’t see why anyone (not just me) would actually want to be writing a paper online and be restricted to the tools that are available on the remote system. Have the data stored remotely, update the local copy, edit it, push back to the remote location. What could be simpler?

    I mean, there’s people developing extensions for firefox that enable you to replace text boxes by emacs sessions! That tells me that the push to make everything “in the cloud” has gone a little too far.

    Let me see if this is the killer. Next time you write a seminar in beamer, particularly one with pictures, count how many times you compile it. Now imagine that each time you did that, you had to wait while your application loaded a remote page. I think that the ‘lusers’ who weren’t tech-savvy would pretty quickly complain about the time lag on such a system and just not use it.

  17. I wouldn’t write a paper on Instiki.

    Me neither. Not directly that is. The instiki software is very useful for collecting all the material and ingredient that should go into a paper. That definition here, that proof there, that exposition from there, the list of references here. Even a link to a pdf bit, if necessary.

    Reorganizing this material into a more standard paper format is pretty straightforward then. That’s not the step that requires collaboration.

  18. For actual paper-writing, a DVCS (like BZR or GIT) is surely the way to go.

    I have written papers using Instiki. The biggest problem with that is not (at least IMHO) the lack of macros. Rather, it’s the lack of a (bibtex-aware) subsystem for citations.

    I’m very tempted to write one, but two things hold me back.

    1) There is already a lot of bibliographic software, that people are very attached-to (e.g. Zotero). It feels like reinventing the wheel to write something new. And no one needs an oblong-shaped wheel.

    2)Bibtex is such a gawdawful format. There really aren’t proper tools (at least not in Ruby) for handling it, and I have no desire to write one.

    What I can say in favour of Instiki (as Urs alluded) is that it does make for a nice collaborative environment for shooting around ideas. And, with its quite decent LaTeX export, whatever prose you do write, using it, is not wasted. That prose can be exported to LaTeX and stuck directly in your paper.

  19. I just saw the Google Wave preview http://wave.google.com, which is to be released later this year. The preview has a bit on collaborative editing with all the features you ask for and much more. I don’t think it’ll be easy to nicely integrate LaTeX input, so that will probably happen well after the release. In any case, it looks like there may be a very useful, friendly, and accessible product for collaborative editing of math papers in the next few months or years…

  20. I use SVN for nearly all my papers, but something I’ve found really really useful is to make sure there’s nearly always a recently compiled PDF available online somewhere.

    I’ve set things up so a single command “ant copy-pdf” in any of my article working directories updates the online version of the PDF.

    Having the PDF easily accessible is helpful in lots of ways — coauthors can read and comment on changes without needing to go through the full SVN cycle, and less technologically savvy coauthors can easily get hold of the draft without any SVN. (I’ve written a paper using SVN where only 2/4 authors used SVN, and 1 author did all of their writing by hand + a grad student!)

    I know it doesn’t sound like much, but if you use SVN and don’t keep the PDF online, you should try it.

  21. Another thought, an Australian company Atlassian makes brilliant software for managing SVN repositories (disclaimer; I used to go canyoning with the owner). In particular, looking through past revisions, finding out when some particular paragraph changed, etc., is really easy. Usually there’s no need for stuff like that in SVN, but when you want it, Fisheye is a godsend.

    It’s commercial, expensive, software, but at least in the past they would give free licenses to open-source software projects; presumably things like polymath1 would count!

  22. Just to put my 2 cents in:

    The feature that I’d love to see in a system that could be used for wiki / notes / paper writing, is for each paragraph, equation and figure to have expandable tabs that contain things like discussions, comments and derivations that you don’t want always visible or in the LaTeX export.

    I originally did this in a tiddlywiki (the references and IBP discussion expand — nb these are old notes, I know much better ways of doing what’s in there now). I’ve also tried Jacques’ instiki version as well as dokuwiki, wikidot and others…

  23. Gitit – wiki software written in Haskell – is getting there. It uses a distributed version control system as a backend – your choice of either darcs or git. It doesn’t use LaTeX syntax but it can export to LaTeX. I am going to contribute a patch back for bibliography support.

  24. Someone above mentioned ‘SubEthaEdit’. Another one that I’ve recently learned about (and just mentioned over on the Google Wave thread) is Gobby.

    It really does do real-time editing.

    You can learn more about it at http://gobby.0x539.de/trac/.

    I said over on the other thread that if anyone was interested in trying it out then I could try to set up a session (sort of a sandbox).

  25. noosphere!

    noosphere is the underlying software of planetmath and
    planetmath, a wikipedia like encyclopedia using latex, with
    diff merge tools etc etc

    Uwe Brauer

  26. I’ve been using EtherPad recently, with some success. I use a short Ruby script to grab the latex from the EtherPad and compile it:

    Shameless plug: there’s more info on my blog:

    Another great tool for adding math to any plain old Wiki is:
    It renders LaTeX using Javascript on the client side, so there’s no special support needed on the server side.

  27. I actually started a collaborative math writing project in a wikidot.com wiki:


    Here is its short press-release:


    My project is called “Filters on Posets and Generalizations” and aims to write exhaustive reference text about filters on posets, filters on lattices, and generalizations thereof.

    The only things lacking is actual collaborators (except of myself). Welcome!

  28. I think perhaps you should find some collaborators before calling it “collaborative”.

    Your claim “There were much talking about writing math research articles collaboratively but no real action.” inaccurately characterises the situation. There’s plenty of collaboratively written maths papers, and indeed examples that made use of wikis, instant messenging, google wave, and other software platforms. What’s unusual about your project is that you’ve announced that your project is collaborative in order to find collaborators.

  29. You said: *There’s plenty of collaboratively written maths papers, and indeed examples that made use of wikis…*

    Out of curiosity could you point any particular example of a research paper which is written openly collaboratively using a wiki (except of my project). I attempted to find such projects using Google but found nothing.

  30. Openly collaboratively? No. Open editing can’t produce high quality writing — you need to choose coauthors you know and collectively hold to an appropriate standard. That said, there are some “paperlets” on Dror’s wiki, some of which include contributions from people other than Dror. He has no plan to publish these, however.

    As Ben pointed out in the original post, wiki software is as yet unsuitable for LaTeX integration, with the notable exception of Distler’s Instiki setup. (cf. Urs Screiber’s work, which is often drafted in wiki form.) Mathematicians today use version control software, largely SVN. I host repositories for about a dozen groups. Most of these are private, but not all. See for example http://tqft.net/svn/fusionatlas/. Of course, commit access is restricted. The FusionAtlas project also has a wiki for documentation, although it’s out of date.

Comments are closed.