We are currently completely rewriting the entire frontend of SMC using React.js, Flux, and RethinkDB ...
... I'm living on credit cards
Are you sure a full rewrite of the front-end is a priority at this point?
I've been there. When your business is going down, it's easy to believe that a technically beautiful v2.0 is going to save the day. It didn't do anything for my business though, and in retrospect I should have spent the year on something else.
> There are much better approaches now, which are critical to dramatically improving the user experience with SMC, and also growing the developer base.
I seriously urge William to, at the very least, survey developers before making this conclusion. I would expect something like "we spoke to 500 developers and at least 60% of them would use the application if it had a more robust dev stack". I find it amazing that extremely analytical and rational people (including myself!) tend to make generalized conclusions without informed data.
It can be easy to justify uninformed decisions with vision. Did Steve Jobs ask people what they want? How about Henry Ford, who supposedly said that "they'd just ask for faster horses"?
I don't love data myself either. It feels better to be right by divine vision, although it sure doesn't happen that often.
Having data is fine, but even the richest dataset is wide open to misinterpretation. This is even more true when the data is a snapshot of a compression of human opinion and feelings.
The interpretation of information collected from a survey such as '60% of developers I asked say..', even assuming it's statistically valid and reasonably accurate (which is not trivial to achieve), still involves a lot of assumption, intuition, and frankly guesswork about the real problems and facts of the situation.
It might provide slightly more of a hint towards the facts than just blindly following a strategy based on vision alone, and there are many success stories of data-driven approaches that vastly outperform the predictions of human 'experts', but implicitly trusting that this will always be the case is probably unwise.
I'm for data-driven decision making in general, just saying that it's never a magic bullet and is often not even an advantage (could indeed be the opposite) if done naively.
This holds back so many projects - how expensive hosting web applications eventually becomes. I'm hoping for more decentralized options to eventually emerge (like IPFS, etc.), but in the meantime, I'd probably recommend to this guy to perhaps offer a paid app version, or just charge for accounts on his site. Or else try a kickstarter or indiegogo campaign.
How expensive would an application like this be? I don't know much about this, but I'd like to learn.
What's an algorithm for figuring out a pretty good guess of any random application's hosting costs? Also, is there a way to figure out how large the expenses could become over time? Is there some way to relate number of users to cost?
There's no upper bound for how much money one could spend, but let's use the midpoint between "extremely frugal" and "money isn't really a concern."
Hosting on GCE costs about $1700/month right now, and at this moment we have $490/month in recurring revenue (we have 56 subscribers to various plans). I've put much work into making SMC more efficient, in order to bring the hosting price down, but there are limits. The reason it costs this much are: (1) there are often about 500 users signed in, every user is using at least one Linux account, and what users do is often very computationally and memory intensive (mathematics, number crunching, etc.), (2) I snapshot and backup all files both to Google Cloud Storage and also copy backups offsite. Doing offsite backups mainly costs bandwidth -- I spent about $20 in the last 3 days on downloading offsite backups of user data (to a USB drive on my desk). (3) In addition to compute nodes, there are database and web servers, which are redundant so that two can go down and things still work; this is very important since teachers often give lectures from SageMathCloud or run computers labs, so downtime is very bad. (4) I also snapshot all the disks images regular, which costs more, but reduces the chances of data loss. I care that users don't lose their data in case of a disaster (hackers or lightning striking Google four times), which just makes things cost more.
teachers often give lectures from SageMathCloud
or run computers labs
OK, sounds important.
I care that users don't lose their data in case
of a disaster (hackers or lightning striking
Google four times), which just makes things cost
more.
And it sounds like you care. So, how much do you charge for such an important tool?
we have $490/month in recurring revenue (we have
56 subscribers to various plans)
$8.75/month. Try tacking on an extra zero to all of your plans. Or, better yet, tack on an extra zero and ALSO let your customers decide whether or not they care about things like backups.
I don't want to sound like an asshole, but your business is never going to succeed if you keep going down this path. And to be clear: I want to see you succeed.
Here are a few things by patio11 you should go read right now:
At ShareLaTeX (https://www.sharelatex.com), our hosting costs are around $1500/month (can probably be doubled once you add in backups and other supporting services). This is for a similar service (LaTeX is just subset of what SageMathCloud does, but a resource heavy subset). However, ShareLaTeX handles orders of magnitude more traffic as far as I can tell. One of the big factors in a service like this is being able to get the cost-per-user down low enough that it's a viable business model given that a student/academic is not going to pay more than about $10/month and most won't pay at all.
One of the big wins for us has been using Docker to isolate projects. Sure, each project is resource heavy when run/compiled/executed, but if you have lots of users, they're probably not all resource heavy at the same time. The more lightweight the virtualisation/containers, the more they can share resources. It sounds like maybe each user is getting to hold on to too many resources that they aren't using, and so it's costing an order of magnitude more than if they could share all the resources perfectly?
I'd be happy to chat more about this stuff (almost all of the ShareLaTeX code is open source as well, except for the enterprisy stuff). We've also got a new project called DataJoy for Python and R (https://www.getdatajoy.com) which has similar scaling challenges that we've been working on.
The typical usage pattern we have is somebody interactively using a SageMath worksheet over the course of an hour or two. Sage uses a lot of memory (large matrices, plots, etc.), and the state must be maintained in memory during the course of the calculation. Also, people will often open many worksheets, which spawn numerous processes. We use fork for Sage processes to keep down resource usage (maximizes shared memory). Each project is not in its own VM; instead we use cgroups extensively (similar technology that Docker uses under the hood) to control resource usage. All the CPU/memory of the free computers is typically maxed out, and being shared (controlled by cgroups) fairly between users. cgroups is awesome technology.
> Sage uses a lot of memory (large matrices, plots, etc.), and the state must be maintained in memory during the course of the calculation.
1. I thought sage used a ton of RAM partly because of the huge amount of statically linked libraries. I see you said you're using fork to maximize shared memory. Have you tried KSM (Kernel Samepage Merging)?
2. Have you looked at zram? Certain matrices and such may be easily compressible.
At this moment there are 585 people connected to SMC (a bit higher than usual due to Hacker New effect), and most are using it for free. We only introduced a fully automated paid plan about 10 days ago, and many of our sign-ups have been in the last week. Paying customers get enhanced support, the ability to upgrade project quotas, and can ask (it's not yet automated) to have projects moved to members-only servers. The members-only servers have an order of magnitude less users on them. There were also until recently obstructions to charging users due to IP and other issues involving University of Washington (my employer).
It would be great to get these paid users writing a line for SMC expenses into their NSF grants. For instance, you could charge $400 for a year's worth of supported SMC for a group (PI and her grad students, postdocs), or $200 for an REU group SMC. It may be easier to get money by asking for a rather larger amount up front, that people plan into their grants or get departments to pay for, rather than asking for $9/month, which I'd feel compelled to pay personally because the hassle of getting reimbursed $9/month is more than the 3 lattes it costs me.
We now offer $79/year and $499/year plans, which would fit perfectly the model you describe. We only started offering them a few days ago due to demand.
The interesting thing, to me, is not the overall cost of hosting, but the new ways that we can host.
I've got a current project that I'm working on. I have no idea how successful it will be and I'm not interested in putting a ton of my own money at risk to see if it will be successful. But using a model where I have zero of my own servers (Lambda, API Gateway, Static hosting) means my fixed costs are under $20/mo and my variable costs scale with usage. All I need to do is ensure that my per-user monetization is higher than my per-user cost and my application scales up without any effort on my part.
In the era of hosted servers, capacity planning and scale out took a ton of my time and energy on projects like this. And while I might end up paying a bit less in the long run if I followed the same methodology today, not having to worry about that kind of stuff and being able to focus solely on the application is really nice.
As an outsider, here is my perspective on a number of things you could do:
Segment your users into plans. Do some user research on the archetypes and Jobs To Be Done that different people are using your product for. Segment features according to this and charge accordingly. For example all of the high availability, redundant web servers and snapshotting should go only on the paid plans. You can make the reasonable assumption that if people aren't paying for your service then they don't value their data very highly, so why should you? Some rough plans I can imagine would be: Undergraduate, Graduate, Professor. These people have different needs, desires, and fears; cater to them.
This might be a hard one, but dropping the free plan will make you cashflow positive immediately. For people who can't/won't pay, you can provide good instructions on how to set up the VM if people don't want to pay. Give people 30 days notice, and give them benefits for signing up, e.g. 20% discount for life of their account.
Look at partnering with teaching institutions that are using your software. Offer them a discount on a class purchase of accounts, or sell them support running the VM on their own infrastructure (perhaps integrating with Moodle or their auth system for an additional fee?).
Look at how people get value from SMC, your costs scale linearly with usage, so it may be good to scale your prices too. One option could be to replace the free tier with a pay-as-you-go tier where people pre-pay for x hours/month, and higher tiers get unlimited usage.
On the homepage, remove the section about grants received as it sounds like that is no longer the case.
Make the homepage a lot nicer and present the benefits of SMC much more clearly.
As others have said, it's not clear at all what plans are available or what differentiates them until you put in a payment card. This is not a compelling prospect.
The goal appears to be to appeal to developers to entice them to contribute; not so much the end-users - although one could argue whether this is the correct business goal?
I also found that further development on SageMathCloud was becoming too slow and frustrating for me, even though I knew the system extremely well (certain important things turned out to be very hard using the original approach). In order to implement the features a lot of users demanded, it was necessary to use a better approach. It is starting to pay off.
... I'm living on credit cards
Are you sure a full rewrite of the front-end is a priority at this point?
I've been there. When your business is going down, it's easy to believe that a technically beautiful v2.0 is going to save the day. It didn't do anything for my business though, and in retrospect I should have spent the year on something else.