The Argument *For* Software as a Service

Josh Catone of sitepoint.com wrote a really interesting post the other day titled  “The Argument Against Software as a Service“.  I left a comment, but I didn’t register and looks like my comment might be stuck in some moderation queue, so figured I’d blog my response here just in case.

Josh makes the larger argument that hosted/SaaS services could potentially go out of business creating a crisis for those who use it:

The more you rely on third parties to get your work done, the more difficult it becomes to stay afloat if those you rely on run into trouble. SaaS applications have allowed business owners to gain access to high quality software at lower prices and with a high level of convenience, but at what potential risk?

If all your customer and sales lead information is in Salesforce.com, what happens if Salesforce.com goes under? That might create a mess that’s harder to clean up than if your CRM data was stored locally, for example. Using Google Docs might save you a bundle on site licenses for Office, but if all your internal documentation is online, what happens if Google decides Docs isn’t worth it and axes the product line? It’s something to consider, certainly.

I agree that this is a concern.  But I believe that the really important question people should ask when selecting hosted services / SaaS is “can I extract/sync with my own data  and can run my own Open Source version of this service ?”

If the answer is “yes” than the risk is entirely mitigated, and the upside is huge.

A few quick comments below on how we answer “yes” to these questions at WordPress.com, and why the hosted/SaaS model does make sense for many individuals and businesses.

On WordPress.com users can always:

1) Extract a complete set of their data via a full XML export.  We don’t do anything to lock-in our customers.  It’s their data period – and it should be a 1-click process to get a complete copy of all the posts, comments, pages, etc.
2) Sync their data. WordPress.com provides a full XMLRPC API to sync all data, and many users take advantage of 3rd party tools, especially on the desktop client side, to manage their WordPress from outside of WordPress, creating a complete duplicate set of data on their local machine.
3) Run their own self-hosted WordPress locally or on a 3rd party host and easily import all their content & themes from WordPress.com.  Users can simply head-over to WordPress.org to download the software, or select to install WordPress with nearly any hosting provider.  This works the other way too – self-hosted WordPress sites can easily be imported into WordPress.com .
4) Ensure link/SEO continuity by mapping their domain on WordPress.com (i.e. domain.com) so if they ever leave our service all the google indexing and links will continue to work.

And as importantly, since WordPress.com is built with WordPress, an Open Source project, there is security and comfort in knowing that a huge community,  numbering in the tens of thousands,  is involved with WordPress.  And even if our company and WordPress.com would somehow fails to live up to our users’ needs, the WordPress project will continue to thrive.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s