React, Flux, RethinkDB and SageMathCloud – Summer 2015 Update
sagemath.blogspot.com
sagemath.blogspot.com
... 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.
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."
teachers often give lectures from SageMathCloud
or run computers labs
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.
we have $490/month in recurring revenue (we have
56 subscribers to various plans)
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:
http://www.kalzumeus.com/2014/04/03/fantasy-tarsnap/
https://training.kalzumeus.com/newsletters/archive/saas_pric...
Are the rest unpaid subscriptions? Or do the subscribers have numerous users?
~$20 seems reasonable. Cheap even. You can always discount when you get to a scale that sustains.
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.
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.
Hosting web applications costs a fraction of what it did 5-10 years ago, both in terms of straight costs as well as operational expenses.
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.
> 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.
I don't love data myself either. It feels better to be right by divine vision, although it sure doesn't happen that often.
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.
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.
I'm no longer in academia and haven't used Sage for years but it's great to see how far this project has come. I hope it gets the funding and development it needs.
A. Turn your billing model inside out.
- Create an AWS account for each user, and start them in an AWS free tier[1] micro instance. Let them decide when to upgrade to a bigger box, how much to spend.
- Put your images on AWS marketplace[2]. Then customers pay Amazon, and Amazon will pay you your markup.
B. Sample projects! Make some demo videos to give the general idea, and when a person creates a new account, let them try out some sample projects, just to get a feel for the system. After I register my only option is "create new project". I'm also in Seattle, happy to discuss, buy you lunch. Contact info in my profile.
Since the project is 100% open source, I'm not sure this would make much money. Do you have experience with marketplace images that are 100% open source?
Your idea about automated subscribing customers is interesting and likely to generate revenue... but wouldn't they pay Amazon instead of SageMath, Inc., which wouldn't support further development?
They're still your users. The biggest benefit is Amazon paying for the free instances for the free users. And Amazon WANTs this. They WANT people to get hooked on using cloud services.
You might even have a mode where the expensive node is only allocated when a big computation kicks off. Hours are way cheaper than months.
- The concept/vision are great and you could be a serious competitor to Mathematica if you got a product person on board. It has all the power of mathematica, a more popular programming language (python), and a good user-acquisition strategy (professors are already using it for college courses... you just need to get the students to take it with them when they leave the course).
- You need a product person / designer because there are serious UX gaps and the feature-set feels really scattered. For instance, the fact that I had no idea you could pay is a big red flag.
- Figure out what your goal is. Are you making Mathematica or Linux? My guess is it's more towards the former and you should apply to YC.
Edit: Thanks for making Sage, BTW!
You can fix legacy later when it's time. And let's be honest, there are proven, good web applications out there using <that stack you're used to> that are in reality no worse than node/whatever, just not as hip.
I love react for the pure frontend and I'm still using it there for many pages (except the ones I want to just be static), but I'm sticking to my python roots for a backend and I'm 100x more productive.
https://github.com/tylerkahn/isomorphic-es6-react-martyjs-to...
This may help you out. I created this after also struggling to find a good isomorphic example app.
1. Some sort of backend DB integration. It's very hard to figure out how people are interacting with NodeJS databases other than MongoDB these days, frontend alone isn't the issue. Sequelize + postgres for example would be great to get an app up and running I expect, including things like connection pooling. (Bookshelf seems okay too, but I don't like it purely because it seems to automatically infer attributes from the database, which makes coding harder as you'll need to hit the REPL or schema to know what's coming out). In addition, webpack is easy to get running. Making it sane from a module size perspective (dead code elimination...etc) is harder.
2. Test coverage. Unit + integration. There's a million test runners, mock frameworks, etc etc out there. It's not trivial to get something you know is sane working (more so from integration side). Not to mention new-style imports entirely break most frameworks like rewire in my experience, so I wouldn't encourage their usage.
And, well, for me I KNOW those answers for python (I haven't done that much nodejs backend work since ~2013. I've used the node ecosystem exclusively for frontend since, a lot), so it's a lot more simple for me to get started.
Martyjs (and the marry-express module) makes this very easy to do in that you can write your application without having to consider the context in which it is running (server or client).
I think the backend DB integration is a separate concern from how to build isomorphic js apps.
In terms of test coverage I don't have much experience testing js apps so I can't speak to the pain points there.
But that's a pretty painful way to start a project as well. /shrug
Anyway, I hope things will get financially better for you.
* On that note, I just went to sign up for a subscription because it's ghastly that I haven't. The 'upgrades' tab just says that I should 'Sign up for a subscription in the billing tab', and the billing tab only asks for a credit card number. The subscription page should probably pitch a few benefits of subscription, with an easy click from a given subscription to the billing page.
* I've used SMC for writing a couple collaborative papers, and have found it fantastic for that. Checkpointed latex with easy access to Sage code is great for collaboration, far better than subversion or (shudder) dropbox. I wonder if there might be good ways to build that userbase a bit: Perhaps some interesting collaboration with the arxiv? Transparent checks for arxiv compatibility as you're building your document? Link 'public code' and data sets in an SMC project on the arxiv side?
Making it easier/better for people to get their papers on the arxiv would be fantastic, and bring in more users. If the arxiv is bought into the effort, it gets SMC more visibility, bringing in more users than just making the features available. Now, the arxiv is extremely conservative by design, so this isn't an easy partnership to make, but it's a pretty obvious one to try in terms of getting a bigger SMC userbase.
But really, the important part is trying to bring in as large a flock of paying users as possible, for a minimum amount of effort. Maybe this is undergraduate students, maybe it's individual researchers (like me) signing up for subscriptions, and maybe it's university math/cs/physics departments signing up for big subscriptions. I know a couple departments that are running their own servers which might be able to save a decent chunk of money by moving to SMC, for example. But it requires some outreach work to get in touch with them, and some bargaining to get them to switch models.
The market and strategy you describe at the bottom is exactly what I've been pursuing, and I hope we turn a corner with it soon due to the new academic year.
As as stop gap measure to slow your burn rate, you should start limiting the resource consumption of your accounts until your subscription revenues at least equals your costs.
I did run SageMathCloud on a lot of dedicated hardware that I hosted at Univ of Washington from March 2013 until May 2015, but had to stop due to University rules. I had planned to buy computers and rent hosting in a data center, but when I looked into the costs of commercial dedicated hosting, bandwidth, and the time and people required to maintain physical hardware with the availability requirements I have, it started looking much worse than using GCE (especially as GCE prices kept dropping). I don't have any employees at all, so when something goes wrong with the hardware, I would have to drive there and fix it myself. What if asleep or traveling across country? No matter what, the odds GCE will fix any problem in a timely manner is much higher than the chances I will. The middleground is something like Rackspace, etc., which doesn't look that much better regarding cost than GCE. Of course, the price of hosting on GCE is a lower order term compared to the price it would cost to pay myself to admin everything, if I wasn't doing it in my spare time.... and then there is development work too.
Good luck with the other suggestions in this thread.