3 ms·

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 un

• JoshTriplett 15y ago
  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.
  • beck5 15y ago
    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.
    • JoshTriplett 15y ago
      > 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?