ACE seems like the best choice; I didn't realize it didn't do remote cursor tracking. Definitely not worth going out of your way for. As for showing the cursor in the PDF preview, even just doing that for the user's own cursor would work quite well.

I definitely wouldn't suggest that you allow people to install new packages globally. However, TeX supports personal LaTeX paths, so users could have their own path with whatever extra packages they needed. (Also, if you ever decide to provide paid-account-only features, that seems like a prime candidate.)

TeXLive definitely covers most needs. Beamer and TikZ represent the biggest things I regularly want that TeXLive doesn't include, and would want to install to a non-project-specific location (since they both have big piles of interacting packages). Other bits, like conference and journal styles, usually come as a single .sty or .cls file that I could easily enough just drop in my project if necessary.

One more thought: I desperately want this to integrate with git, since I version-control almost all of my LaTeX documents.

Having individual user paths with style files and other packages is something I have thought about. I think for my premium account I will probably only offer unlimited accounts and perhaps continuions compiling behind the scenes looking for errors. It is quite important to me to offer a full service for free.

on git: I want to add some sort of versioning, my current plan is to do a nice friendly wrapper around a single branch on git. This could then be pulled from for peoples peace of mind but probably not pushed to. My thinking is git is hard, I use it all day as a dev and I am still googling how to do things, if you are a mathematician yes you have the ability to learn it but you shouldn't have to and probably can't be bothered to.

With few exceptions, most of the papers and presentations I've written get finished, tagged, archives, and never touched again. Sometimes I'll start a new presentation and take some material from a previous one, but I still typically do so as a new document. Given a model like that (which seems fairly standard in research), unlimited projects wouldn't really affect me much, since I can just delete projects I've finished with. (I wouldn't keep the canonical original on ShareLaTeX anyway.)

Do you expect many people to keep a giant pile of still-edited documents on ShareLaTeX?

Regarding git: using it for basic built-in versioning seems useful, but in my case I actually don't want to treat ShareLaTeX as the canonical source of the document and keep the git repository there. I'd just like to use ShareLaTeX as an editor, and keep the Git repo elsewhere. I don't know offhand the best way to support that, though. Pushing to ShareLaTeX to edit and pulling back when done to push to the canonical repo could work, and it seems like the simplest option, since you can safely ignore conflicts entirely. Using ShareLaTeX as an editor on a third-party git repository seems potentially awesome, but fraught with unfortunate security implications, as well as having to deal with merge conflicts on pull.

You are right about people just moving projects in and out. Another option is to follow Cloud9's lead and have public projects for free and private available to premium. There are other things to limit like number of collaborators however its quite important to me personally to let as many people use this as possible. People do spend a lot of time on the site which might make adds an interesting alternative, but I would rather not muddy up the site with them. Any ideas are very welcome.

I feel people on HN/you are a small percentage of people who use latex and git in that way. I think most latex users backup policy is copying and pasting folders. Im not against the idea, what I really don't want is to deal with merge conflicts and people emailing me asking for git help it is likely I will offer a pull only service one day.

> You are right about people just moving projects in and out. Another option is to follow Cloud9's lead and have public projects for free and private available to premium. There are other things to limit like number of collaborators however its quite important to me personally to let as many people use this as possible. People do spend a lot of time on the site which might make adds an interesting alternative, but I would rather not muddy up the site with them. Any ideas are very welcome.

Please do remember that you've created something awesome here, and you should try to make some money from it. :) I realize you want as many users as possible, but when designing your premium features you need to select things that some significant subset of people will want enough to pay for. I certainly want to pay you for this, but if you give me everything I need for free that makes it harder. :)

In particular, as a user I want you to make money from this so I'll feel confident that it'll stick around.

The private/public distinction makes a lot of sense. It might also work to just allow a single private non-collaborative repository, which would suffice for a user who rarely uses collaboration to try the service (since they can delete and add projects at will), while anyone doing collaboration on a private project with several other people will want those people to have the ability to edit at any time, and thus they can't take down the project to work on something else.

Freemium does seem highly preferable to ads, here. I won't say that you couldn't make a decent amount on ads, but I don't think they'll work nearly as well for you, given both the target audience and the amount of resources each user needs.

I do think you have the right idea about git: supporting arbitrary repositories would help power users, but allowing read-only access to a one-branch git repo goes a long way with relatively little effort. Your priorities seem entirely sensible. :)

By the way, how do you plan to scale? A single compilation of a large document takes multiple seconds of CPU-bound computation even on a dedicated system; what happens when you have even a few hundred simultaneous free users? That suggests a very sensible possibility for premium accounts: any kind of real-time previewing or fast compilation would go in the premium category, while free users get to click the "PDF" button and wait in line for a brief period. (Browsershots and similar services follow this model.) You'd still provide a huge amount of value for free users, who can collaborately edit for a while and then hit "PDF" and wait a bit for the result. Meanwhile, in my case I compile several times a minute by hitting a single editor keystroke and having the PDF viewer in the other window automatically update, and I'd happily pay to make the delay go away, given the collaborative features here.

On a closely related note, I think this would work most effectively if you allow one user to pay and then invite other collaborators to edit a document. A couple months ago, I needed to prepare a presentation with two other people elsewhere in the world. After a failed attempt to use Gobby (non-trivial for one of the collaborators to install the current version on OS X), I ended up using one of the various EtherPad sites floating around to edit the TeX source, and repeatedly grabbing the entire document and running pdflatex locally to get a preview. I still had to clean up the document by hand afterward due to broken TeX formatting, since other collaborators didn't have the ability to compile. If I could have paid to make that problem go away, and just handed a link to my two collaborators, I gladly would have.

Which raises an interesting question: does this make more sense as a monthly service, or as an "ow ow ow this hurts here's some money make it stop" service with a more pay-as-you-go model? I edit LaTeX documents often enough to use a service like this quite frequently, but not so often that I wouldn't have a month go by without doing so, which hurts when paying for a monthly service. Perhaps something like $small for a few days (for the initial "ow this hurts" use case), and a reasonable multiple of $small for a year (for the case where you expect to use it repeatedly). When you stop paying, your documents stick around (because a bit of text costs you almost nothing to store), but the private collaboration and fast unqueued compilation/preview goes away.

How does that sound?

Great feedback thanks:

Yep right again, I should try and make money. What price points would you think is acceptable? I was thinking around $4/mo $35/yr. Great idea on PAYG, a one off project for $7 which could actually get a lot of sales, that would have to be time limited to say 2 months however because people could just switch the content in and out. You are correct I would never delete the content, the cost is so low. Actually getting the money is another problem, Im based in London so the best option is currently paypal, I would like to hold out for stripe but who knows how long that will take....

Scaling, You are right that it could get bad, I've been chatting to a guy who's pdf compiles down to a 28 meg. The next step would be breaking the compiling out to a different server, the code is nicely decoupled so it would not be hard to implement. It wouldn't be to hard to have multiple compiling processes getting jobs from a que. Other than that I've not thought to much about it.

For simplicity sake I am planning on having 1 owner who's account is 'debited', other users could be of any type. Interesting idea like Browsershots, I will have to look at that a bit more.

This is great advice, please keep it coming.

First of all, a disclaimer: ask a pile of interested people very carefully before deciding on prices; people suck at accurately saying how much they'd pay for something, and that almost certainly includes me. :) If you want to get fancy about it, take a look at https://en.wikipedia.org/wiki/Van_Westendorp%27s_Price_Sensi... , and perhaps http://www.priceintelligently.com/ ; if you don't want to get fancy about it, just make sure you talk to more than a few people.

That said: I actually think $4 would work nicely as a "project" price, and for more along the lines of 1 week rather than 2 months. That would nicely cover immediate one-time pain like the case I ran into. $4 falls squarely in the category of "yeah, I'll pay that to solve this problem today", and I'd have paid that just for the 1 day I needed to use it.

If you feel like you can comfortably serve people at $4/month, I'd absolutely pay that price without hesitation; $7/month seems reasonable too. Perhaps you should just treat that as the "project" case, and market it so that people think of it more as a "pay once and use it for a month" price than something they necessarily have to pay repeatedly for via a subscription. I think that'd make more sense than trying to go off the beaten path by talking about weeks. :) (Most "monthly" services don't really cater for the case of "let it lapse, then start paying again when I need it", but in the case of this project I think it would work beautifully to do so several times a year.)

I don't have a strong feeling for the right price for a year. You want something that makes people say "I'll use it often enough that I don't just want to pay $4 (or $7) each time I use it." You might just want to start with monthly and add annual if someone asks for it. Annual billing also introduces new complications, such as making chargebacks more frequent and more serious.

I also think some great opportunities exist here for "organization" or "college department" plans. I could easily imagine an entire CS department getting enough value out of this to pay for it, if you don't mind jumping through the hoops it takes to sell to such entities.

Regarding queuing: Redis works beautifully for this. Just add the ID for the particular version of the project to a queue when the user hits the PDF button (Redis: LPUSH), and run a pile of queue processors, each of which grabs an ID from the queue (Redis: BRPOP) and runs pdflatex. To handle premium users, use a separate queue with some queue processors only looking at that queue and some looking at both. (BRPOP accepts multiple lists and returns an item from the first non-empty list.) Track the processing time for premium and free users, and throw enough resources at queue processors to get each of those to the level of service you want to provide.

Regarding payment: words can't express how much I'd recommend against PayPal. But then, I have access to things like Stripe and Samurai; sorry. :( I'd still recommend finding a decent payment gateway if possible. You'll also find it a lot harder to sell to organizations or departments if you use PayPal.

Interesting on redis, I already use it to store sessions. A friend talked about have 2 ques, only process free que when premium is empty as well.

When I get a chance to breath I will look into the price levels in more detail.

I would ideally look for a provider who can just take all the hassle out of taking cards and doing reoccurring payments. Sorting out a payment gateway is a lot of effort which I would rather focus on the product in the short term (next 3 months).