Joel on Software - Monday, October 24, 2005: "This is where Google is actually hurt by the long tail world of millions of small sites."

This long tail thing - it's not all good, y'know. I was thinking about this the other day whilst chancing across some stats analysis we were running for a client.

We do a lot of porting work - taking mobile applications that we (or others) have written and converting them to work on new mobile phones. This is an inherent part of our business right now and whilst it's not as obviously rewarding as developing scratch, like it or not it's very necessary. There are porting frameworks which aim to help you get around this problem (in fact we wrote a rather snazzy one ourselves which we use internally) but they don't get away from the need to build and test your apps on real devices.

So which handsets do you port to? Well... there are a few biggies, a few which obviously stand out when you look at who's trying to use your service - and you should look at who the prospective audience is, up front, because different audiences will have tendencies towards ownership of different handsets. But there are a few up the top - Nokia Series 40, high-end Sony Ericssons, etc. - which are a no-brainer. But then look at the rest of them - the graph below shows the number of unsupported customers we've had for about 127 handsets which our service doesn't currently support (it has been explicitly ported to just over 40 more popular devices, of course!):

Oooh, it's a long tail - the top 19 out of 127 handsets (15% of them) which we don't currently support make up 50% of traffic. But look at the other 50% - to support these we'll incur incremental costs testing and development, so they become commercially unfeasible.

The morals of this tale?

1. "Write once, run everywhere". Stare into the mirror and say it's name three times - it doesn't appear, it's just a fairytale.
2. You need to look at your audience before you decide which devices to port to.
3. Porting costs are a matter of economics: the more you spend, the wider your audience. But it may not be commercially viable for you to widen your audience beyond a certain point.

Comments

[Simon Cavill]

Interesting - We run mobile payment services for mobile operators and other content owners and utilise a Java MiDP 1.0/2.0 applet as one channel. The app is very simple in look and feel and uses 3DES encryption. The real issue for us is that if you do go for a vanilla app to cover a wide range of devices, it looks sooo ugly in both look and feel due to the limitations of the early (read widespread) devices... The only alternative is to do as you have and create multiple versions for families of devices - Its horrible which ever way you look at it - No wonder most of our clients default to SMS....

We are now working with games companies etc putting our payment kernel inside their apps, so they take on the pain of phone compatibility!!!

Great Blog,

Simon

[Tom Hume]

Simon - another alternative is to create your own app platform, built on top of MIDP. This is what we ended up doing (see http://www.futureplatforms.com/fp/cactus.jsp) and along with a well-tested methodology for managing ports, lets us do tightly defined custom UIs across many devices.

Interestingly, we've just gone through a process of looking at outsourcing porting. Thus far it looks like the cost savings of using offshore labour are mitigated by the need to support, document and manage the porting process; and if it's been built sensibly with portability in mind then the original development team are better positioned to handle ports and can do them *way* quicker.

But it's early days and I suspect this may change over time.