Asphalt and the Long Tail

The other day I got a letter from a frustrated customer – an actual, physical letter written on paper with stamps and everything. The customer was upset about a host of things – all of them very legitimate and things I’d heard before. I didn’t have good answers, which made me feel bad, but I did manage to get his problem solved and with our Orcas release, I hope to reduce his frustration level dramatically.

But what was interesting is the application he’d created: it was a VB application to determine the correct asphalt mixture for road building. He’d worked as a civil engineer for a state highway department and one of the things they’d needed to work out time and again was the correct mixture of ingredients for different applications. Based on what I was able to deduce, his application was pretty clever and, for the probably 2,000 companies around the US that deal with this on a regular basis, might have been incredibly useful and that these 2,000 companies might even have been willing to pay something for it.

There must be tens or hundreds of thousands of applications like that: applications that are very specific to a particular customer and a particular problem that will probably never have more than a few hundred customers. The term I hear for these applications a lot is “tail” applications – so called because they’re not in the “head” (i.e. the 90% case of applications that a typical person would want).

Recently, I dug around in some of our internal research about professional developers, specifically professional developers who say they work at ISVs. There aren’t that many of us, as it turns out. When you take the “big” ISVs (companies that have 15,000+ developers each) like Microsoft and Oracle and IBM and so on out of the picture, the overall number drops hugely. In fact, about two-thirds of all ISVs have fewer than 50 employees total, and one third are under ten employees. That’s employees, not developers.

The overhead in taking an application like this to market is substantial – you have to package it up with a nice setup.exe, build some documentation, find a place to “sell” it, figure out how to take payment, track feature requests and bugs, build awareness of the product, and so on. In all, for most people the process is prohibitive. It shouldn’t be that way.

With offerings like the Windows Marketplace and business models that incorporate multiple revenue streams (e.g. pulling together advertising, product sales, consulting services) there’s a huge potential to see more small ISVs making money. Of course, it’s not that easy – we have to make it easy for the small ISV to handle all the non-technical things like figuring out how much to charge and actually collecting their revenue. But I think this is a very doable thing.