I find much of what I read in the media about the “issues” involved in developing SaaS products as silly – and sometimes just plain misinformed. Is it just me or are there just too many analysts with nothing else to write about? Hint: Pick up the phone and talk to some people who are actually developing a SaaS product…

SaaS itself is a victim of this type of FUD (Fear, Uncertainty and Doubt). There seems to be a rise again of articles about “continuity assurance” and “source code escrow.” I’m not going to link to any of them – all of them seem to assume that there needs to be some draconian legal answer to the problem of data portability. Let’s be honest people – No Technical “Solution” is Forever <PERIOD>. If you’re not taking steps to manage your risk for control of your data and processes from day one you’re in trouble no legal agreement or high-priced lawyer can fix.  And yes, a smart SaaS vendor will build portability into their product because they understand the business value it gives – but nothing can force customers to use it and plan properly.

Likewise, I think people who are researching the business and technical issues for developing SaaS products are finding more FUD than substance. Yes, SaaS business operational issues are different, particularly for vendors of traditional “premise-based,” single-tenant applications. Yes, the technical requirements of the Internet-based and “cloud” environments are different.  In fact, it would be a good idea to seek help on these issues so you can concentrate on delivering a service with business value.  But honestly, I would and have recommend that for anyone developing a software product today. Think lean. Don’t waste money and time developing what you don’t have to – use services and frameworks you can leverage. Spend on developing a product customers will pull into the market. Learn customer-driven product management.

But doing that means leaning on tools, frameworks and yes – platforms so you can focus on your product. Enter the Boogie Man. Analysts produce lists of lists of keywords that capture a perceived issue: “vendor lock-in,” “Opex Vs. Capex,” “proprietary lock-in,” etc. And as anyone who has followed the industry knows – there have been failures.  But on the other side of the coin – the number of failures has been quite limited considering the wealth of tools and services available.  That isn’t a lot of solace to companies that bet on Coghead – but I have to say they should have seen the writing on the wall a long time before the doors closed. The total lack of data/code portability tied to a vendor that was clearly struggling to get traction and funding (read: no business model – the smell of burning cash) should have caught prospects’ attention.

The real truth is that software development has been depending on tools, frameworks, application servers, services, and platforms since the days when we left assembly code behind. You can’t avoid them.  If we were constrained to coding directly for each processor and environment, technical progress would be dismal indeed. Java, C#, HTML, .NET, Apache web server, XML, PHP, Ruby, Python – all of these simple examples are at some level an abstraction of layers below them. But like Microsoft’s Visual Basic – they are all tools that have a lifecycle and will eventually be superseded or folded into the next generation product. Technology moves on. Nothing is forever.

Of course, this doesn’t mean application developers shouldn’t consider where their tools are in their lifecycle and viability of the community of users around them. It doesn’t mean that the business side should ignore the risks of the choices the technical team has made.  It doesn’t mean we don’t need to have an idea of what we would do if the worst comes and we need to change our assumptions. How long would it take? What would the most likely alternatives be? What is the real risk of doing nothing because you’ve become a “deer in headlights” with all the choices you have to make – instead of just making decisions, allowing for risks and moving forward to a positive cash flow from a product with a growing, paid user base?

Because we don’t believe “doing nothing” is an option that will lead to success, at Scio we’ve made a conscious choice among the tools available to us. We’ve picked a group that we believe deliver business value to our customers.   We have invested our time and resources in this “platform” to develop our delivery expertise and are continuing to do so.  I say that not to highlight ourselves – it is what service companies do. They leverage tools to deliver their services better, repeatably and more competitively.

Do I need to say it? SaaS is a service business. Don’t succumb to the irrational fear of tools you can leverage to better deliver your expertise and value to your customers. Learn to evalute and manage risk. You cannot be successful if you are totally risk averse.

If you’d like to know more about how to navigate the operational and technical choices in developing SaaS products – let me make a suggestion: Jim Geisman, of Software Pricing Partners and I will be giving workshops on SaaS following the OpSource/SIIA SaaS Summit 2010 – “All About The Cloud,”  May 10-12 in San Francisco.  We’re very serious about making this an opportunity that people can take advantage of – so we’re “crowd-sourcing” the workshop configuration before we open registration. We need feedback from people who are either planning to be in the area for SaaS Summit or are just in the region and interested in attending (you don’t have to attend SaaS Summit to attend our workshops – but we encourage it).

Would you give us some feedback on the workshop configuration that would be most useful to you with this survey?  We would really appreciate your help on this.  And watch for more about the workshop starting next month.