Image by BULLETSAYS via FlickrAs we approach the inevitable look back over another year in the software business, one buzz word that stands out is ‘Cloud Computing“, or ‘The Cloud’. Like it or not, the likes of Nirvanix, Amazon Web Services and Windows Azure are changing the landscape for us all.
As
someone who has historically (read hysterically) stuck to the desktop,
I find that the cloud is intruding ever more on my consciousness. If
you’re already in the web camp, the cloud is probably already on its
way to being your bread and butter.
The more interesting
challenge (from my perspective) is how best to take advantage of cloud
based services from the desktop. How long before I’m adding S3/Nirvanix
backup into Home Document Manager? How long before I provide web based
access to the same data?
Whilst I still believe that for PC’s in
the home and business, rich desktop applications still offer massive
benefits over their web based competitors, if your app can successfully
straddle the cloud gap, there’s no need to have your feet in just 1
camp – you can open up new revenue possibilities with a hybrid solution.
If you have a data centric desktop application, it’s worth checking out some of the SDK’s available for your platform:
[Last week I had the good fortune to spend a little time talking
with Gord Graham from WrappedApps on the subject of SaaS and the micro
ISV. His ElastX initiative may well alter the game for micro ISVs. Gord
has kindly contributed this guest post on the subject.]
What is the right model for
delivering MicroISV applications over the internet?
The Software-as-a-Service (SaaS)
delivery model for offering applications over the internet has really
caught fire…Salesforce.com drove big competitors in the CRM space
into extreme hardship (poor Siebel!), Google’s productivity applications
are being recognized as a great alternative to desktop suites. A friend
of mine with a traditional client-server app says that half the RFPs
they see now they can’t even bid on because they require delivery
over the internet on a subscription basis.
Five years back, everyone thought
that SaaS was going to enable software vendors to reach the small-and-medium
business market, but surprisingly the early adopters were large enterprises,
and that continues to be the focus of SaaS providers. And the reasons
are clear…large enterprises recognize that the total cost of ownership
of software goes way beyond paying the license fee…there are servers
to buy, update management for the operating systems and applications,
security management, performance management, and of course all the expensive
IT guys and gals to do this stuff. As well, many companies “lock-down”
their desktops and don’t allow their employees to install applications
so they can outsource desktop support to an off-shore call center.
So buying enterprise applications,
like CRM, ERP and HR, on a subscription basis was just the ticket…reduce
your IT headaches and have access anywhere, any time, over the internet.
Most microISVs still use the
shareware model for marketing their applications…download to your
computer for free, try it for a while, and maybe 1 or 2 percent will
decide to pay for a license. The SaaS alternative looks pretty attractive…nothing
for the user to install, no license keys to manage, and the stats on
customer retention by SaaS vendors like Salesforce.com is outstanding.
I think SaaS is a great opportunity
for microISVs, but they face several problems. Their apps usually weren’t
designed to be offered through a browser over the internet (that problem
can actually be solved quite easily), most hosting services that provide
the infrastructure for provisioning and hosting apps, subscription management,
and the like aren’t particularly interested in the relatively small
niche markets of microISVs, and SaaS marketplaces like AppExchange require
redevelopment of the app in a proprietary language that restricts you
to one marketplace.
But the biggest problem, I
think, is the subscription model. Subscription to an application still
requires the user to make a purchase decision based on the specific
app, make a payment transaction to subscribe, and make a psychological
act of commitment to it. Whenever you ask a customer to make an act
of commitment, particularly one that involves a purchase transaction,
you are going to experience a high attrition rate.
I think the right model for
microISV applications is what I call the “cell phone model”. For
my cell phone I pay a monthly fee that gives me a certain number of
minutes of talk-time (I’m not masochistic enough to have a Blackberry
yet). So it looks something like a monthly subscription, but when I
flip open my phone I can call any number in the world without “subscribing”
to it. I don’t have to make the decision to subscribe to Grandma’s
number, or subscribe to my girlfriend Sue’s number (God knows what
would happen if I ever let that subscription lapse!). I just dial a
number, and the phone company takes care of measuring my talk time and
remitting money to whatever carriers were involved in delivering the
call.
That’s what I think a SaaS
platform for microISVs should look like. The user creates an account
once, and then has immediate access to any microISV app in the library
at a reasonable hourly rate. The SaaS provider takes care of metering
usage, remitting usage fees to the ISV, and everything else.
Later this year we are going
to be launching a platform called ElastX based on this model
(the details won’t be available until July 7 on www.elastx.com).
Clearly, not all microISV applications
are appropriate for SaaS…some have to be run on the user’s computer,
or are in constant use so a pay-by-the-hour model isn’t feasible.
But there are thousands of apps that personal or small business users
might want to use for a couple of hours a week, and I think that SaaS
is a perfect distribution mechanism for them.
Amazon’s Flexible Payment Service (FPS)
is a system for the transferring of monies between any 2 individuals or
companies with Amazon payment accounts. As well as allowing developers
to create their own payment systems, vendors can delegate their payment
processing to Amazon, which should be of some interest to micro ISVs.
When it comes to the trust stakes, having a co-branded payment page
must be up there. I can’t remember a Word Wide Web without Amazon.
Overview
FPS allows payments to be configured and prepared in 3 steps:
A set of rules can be defined to configure which criteria must be met for a payment to go ahead.
The parties agree to the rules and approve the transaction.
FPS performs the transaction.
There are 3 actors in a transaction, the caller, the sender and the recipient.
The caller is the actor who orchestrates the whole
transaction. She is responsible for obtaining the authorisations from
both the sender and the recipient. The caller must call the FPS APIs,
so must also have an FPS developer account.
The sender is the actor who is making a payment.
She will send money from any sources associated with her Amazon payment
account, whether it be a credit card, bank account or Amazon Payments
balance.
The recipient, for our purposes, the micro ISV, is the actor that receives the money. The balance of the transaction is added to the recipient’s Amazon payment account.
There are 4 types of Amazon Payment Account:
Personal accounts are generated automatically for
users when they first make a payment through FPS. Accounts are
initially restricted to payments by credit card, but can be enhanced
(with a confirmed email address) to include paying directly from a bank
account, and receiving payments from any source other than credit cards.
Business account have all the benefits of an
enhanced personal account, but with the added benefit of being able to
receive credit card payments.
Developer accounts are similar to Business accounts but allow for API access too.
Ultra accounts are special accounts for users who
have a consistently high volume of transactions. Ultra accounts receive
a discounted rate for credit card transactions.
Pricing
For Transactions >= $10:
1.5% + $0.01 for Amazon Payments balance transfers
2.0% + $0.05 for bank account debits
2.9% + $0.30 for credit card
Spreading the love – a few 3rd party FPS solutions:
.netCharge – an ASP.net component backing onto FPS