Tuesday, July 12, 2011

They Grow Up So Fast

Exactly one year ago today, android2cloud hit the Android Market. Two weeks later, it was already getting far more usage than I had ever imagined. Since then, the usage has increased pretty steadily. It has been covered by most industry blogs (just Google 'android2cloud'). It has been covered by the venerable Lifehacker, and included in several of their 'top ten' lists. It has gained an advocate (and I've gained a friend) in Kevin Purdy, the author of those Lifehacker posts. It has run into money issues, and gotten two awesome sponsors, SiteSpect and Wonderproxy. It has gotten the team early access to new APIs from Google that now form the core of its software. It has gained an amazing supporter in Moishe, the developer that wrote the API and who now advocates for our project whenever and wherever he can. It has been acquired been Second Bit. It has been launched, still buggy and non-working, to thousands of users. It has been fixed by an overworked, sleep-deprived team on a tight schedule. It has been rebranded to 2cloud as we lay the foundations for expanding into more and more operating systems. It has gotten a gorgeous website from Eternity Online. It has had ads enabled as an opt-in way of donating to the server. It has brought the team to Google I/O. It's been one hell of a year.

And we can't see it stopping any time soon. We've been contacted by a publication (let's call it "Eebowai Mag") that plans on reviewing 2cloud in an issue at the end of July/beginning of August. We'll let you know more information as it becomes available and we're sure it's okay for us to publish it. Suffice to say, Eebowai Mag has several hundred times more readers every day than we do users since January 1st, 2011. And considering we've had over 16,000 users since January 1st, that's not saying nothing.

Ever since we were contacted by Eebowai Mag, the team has been in lockdown, trying to get updates and improvements ready. But Tino (the project manager) and I have been in lengthy discussions about how to make the application scale to support an influx of users. We don't think we'll get all the readers of Eebowai Mag by any of stretch of the imagination, but if we get even one tenth of a percent of them, it will bankrupt us rather quickly. A sustainable system for supporting the application has been our top priority ever since July 1st. We've come up with a system, and I hope you'll like it.

The problem, as I see it, is that we can't pay for all of you to use this as much as you want. I wish we were a multi-million dollar company and could. I really do. But we have a very limited bank account and as our only product is losing money, it tends to dwindle pretty quickly. Your donations are appreciated and amazing and wonderful, but they, unfortunately, don't cover the balance, or even most of it. So if we do nothing, our server will be going down. We started by just assuming this would happen, and planning for it. Our first course of action was to make sure we fail gracefully. We want to make sure you know what is happening. We want to make sure the app doesn't just force close, or silently fail and leave you wondering what happened. We want it to return an error message saying "We're over quota. We'll be back tomorrow."

And this train of thought led us to an idea. What if we do that, but let you pay to get around it? I mean, we can't pay more money--we don't have it--but if you have the money to pay for your usage after that and want to, who says you shouldn't be able to? So we're going to do two things:

  1. We're going to set the App Engine quota high. Unconscionably high. So high, we'll never be able to pay for more than a couple days of it.
  2. We're going to implement our own "soft quota". We're keeping track on our server of how many resources we're using, and when we hit the limit for resources we can pay for, we fail gracefully. We say "Sorry, we're out of quota". But we also offer to let you pay $1 to get around the quota. Right now, we're saying $1 buys you the rest of the day. We still need to do some testing to figure out what those numbers should be-- it could wind up being $1 to get a week of no quota.
A lot of this work was already done. Our team has been feverishly working since July 1st to implement this. We've also been refactoring our codebase so it's readable and takes advantage of everything we've learned in the last year. We were really hoping to have a beta release for you today, but fell barely short. We'll be releasing something to our beta testers tomorrow, if everything goes as planned.

It has been a really exciting year. 2cloud has grown significantly in the last year, and the team has grown with it. We're much better at handling an open source project. We're much better at writing scalable, efficient software. We still have a long way to go in both those. We owe a lot to a lot of people for that. One person who deserves a huge thank you is Matt Turland for all his guidance and mentoring in application design. Our code would be far worse off today were it not for him. So if you have a moment, @ mention @elazar with a "Thank you".

We're really excited for the future. We hope you like the things we've come up with. We hope we've fixed the bugs that are bothering you. But, most of all, we hope you understand how grateful we are to you, our users. This application is what it is because of you. We have over 1,000 reviews on the Android Market and a 4 star rating. We're working really hard to live up to that rating.


  1. I think a 'for the rest of the day/week' model could face some reluctance from users. A monthly subscription might make more sense, maybe even a tiered one (low usage, medium usage, high usage, unlimited...). Of course, you'll have to figure out what load users generate on average and how much that costs.

    Alternatively, you could just sell packages of X shared links without a limitation to the time period, which I could see users accept even more than a subscription based model (You pay what you actually use). You'd have to account for price increases in the hosting though.

    This is just my 2 cents of course, I may be completely wrong.

  2. I'm sorry, I'm not being clear at all.

    The quota is ONLY for the connection between the server and the Chrome extension. Send as many links as you want-- we'll hold on to them until the next day, and send them along to you. Paying to escape the quota just means the links continue opening as they normally would.

    A monthly model is intriguing, and certainly possible, though it would actually probably be less cost effective. Your payment only matters if the server goes over its allotted quota (not something we expect every day, or even every week) and quotas are reset every day, so I thought the obvious choice would be to bill on the most granular scale possible: a day.

    We'll also be experimenting with the possibility of selling a "get out of jail free card"-- you buy five, and the next time the server goes down, one gets traded in for ignoring the quota for that day. Repeat four times, and you're back to needing to buy them again. This would insure that if you paid, you actually got use out of it.

    Thanks for the feedback! We're still trying to gather statistics and information so we can approach this in an intelligent, controlled way. We'd love to hear any ideas you may have.