- Immediately shut down and get out of Dodge: At best this is rude and at worst you've really screwed your former users as they've lost their data forever. Not a valid option for responsible developers.
- Hang a going out of business sign: Even if everything else is free, there is an opportunity cost is keeping a 'failed' idea going (discussed more in #3). It's perfectly reasonable for someone to want to move on. The crucial ingredients here are sufficient notice and data reclamation options.
- Build in at least one month of lead time before services get shut off. Two or three months would be more considerate.
- Stop accepting new users (unpublish for apps, no more signups for web sites).
- Notify users via email and/or web site banner.
- If you have an app, consider publishing a final version that includes a conspicuous popup every time the app is launched informing them of the impending shutdown. Drive the point home any way you can.
- In the last couple weeks, review your logs/database for people still uploading data and send them a friendly reminder.
- Give users lots of options for downloading their data to convenient formats (CSV, etc). Even if you didn't have this feature before, you're going to need to build it to shutdown gracefully.
- Remain available even after shutdown for stragglers.
- Keep your product available in perpetuity: If its not costing you anything, you could keep it going for the long-term. There are disadvantages and risks! APIs change. Users will still seek support. You could get a bill one day for a service you consume.
Additionally, there should be an expectation that someone is minding the store. Developers who go this route can never completely disconnect. Consider not accepting new users and being up front about your intent to stop iterating.
Monday, March 19, 2012
What to do when your free app doesn't take off
Sunday, March 18, 2012
OpenShift test drive
UPDATE 5/5/12: I used OpenShift to host my semester project for a grad school class I'm taking. It's available (for now, probably not forever) at http://tornado-ryancutter.rhcloud.com/. The app attempts to process large amounts of Google+ content and rank attached links intelligently.
The only issue I had with OpenShift was a lack of support for python multiprocessing. The issue is documented here. When I discovered the problem, I hopped on IRC and was able to immediately talk to an OpenShift rep (on a Saturday, no less). Talk about customer service! Hopefully it'll be fixed one day. I was able to use python threading to do what I needed to do but I can see how this would be a showstopper for some people.
Overall, very impressed with OpenShift.
Friday, March 2, 2012
Running Jython apps using HBase
$ export HBASE_HOME=/usr/bin/hbase
$ export JYTHON_HOME=/usr/bin/jython
$ export CLASSPATH=`$HBASE_HOME classpath`
$ alias pyhbase='HBASE_OPTS="-Dpython.path=$JYTHON_HOME" HBASE_CLASSPATH=/usr/share/java/jython.jar $HBASE_HOME org.python.util.jython'
$ pyhbase
Jython 2.2.1 on java1.6.0_30
>>> from org.apache.hadoop.hbase.client import HTable
>>>
Once the environment is set up, you can write an app. Let's say you have a table called 'test' with a column family named 'stuff' and column named 'value'.
import java.lang
from org.apache.hadoop.hbase import HBaseConfiguration, HTableDescriptor, HColumnDescriptor, HConstants
from org.apache.hadoop.hbase.client import HBaseAdmin, HTable, Get
from org.apache.hadoop.hbase.util import Bytes
conf = HBaseConfiguration()
admin = HBaseAdmin(conf)
tablename = "test"
table = HTable(conf, tablename)
row = 'some_row_key'
g = Get(Bytes.toBytes(row))
res = table.get(g)
val = res.getValue(Bytes.toBytes('stuff'), Bytes.toBytes('value'))
print Bytes.toString(val, 0, len(val))
The only weird behavior I couldn't explain is the need to overload that last Bytes.toString() call. I posted a question on StackOverflow but didn't get any great feedback. I'm thinking it's something in Jython maybe(?).