A good discussion has ignited within the SaaS community. I first caught this on a post by Sinclair Schuller from SaaS Blogs. Salesforce’s PaaS model has drawn criticism ever since it was launched. At a recent OpSource Summit, Phil Wainewright conducted an informal ’show of hands’ survey and the results reignited the debate of whether Force.com makes sense for ISVs.

The big shocker: In the seminar hosted by Waineright, only 2 out of 250 ISVs said they are considering Salesforce’s Force.com platform. Critics have quickly pointed out the pitfalls of an ISV business model built on Force.com and these are my comments to some of their arguments.

———–

• Force.com Is Not A True Platform:If you read between the lines of the marketing jibber jabber, they’re actually right. I recognize that Apex Code is a huge technological feat but basically Salesforce took some native features like (custom objects, workflows, the web service API), then added Apex code and Visualforce and branded it the “Platform Stack”. It’s almost like taking their CRM and stripping it down to build an application with customization features.
• Vendor Lock In: It has been argued that code portability is an issue when you develop software with proprietary technologies like Apex and SOQL. By portability has always been an issue. If you have software written in Java, you’re going to have to do a massive re-write to change to C/C++. Instead, I think there is a different kind of vendor lock-in. Vendor lock-in is inevitable because you will never dare to change your underlying platform once you have thousands of subscribed customers. If you build on top of Force.com you’ll never be able to forklift that data into the new .NET system you built. Nor will it ever be a seamless transition from one system to another. Downtimes and data loss would be inevitable, and it’s almost certain that some customer will claim you caused ‘catastrophic losses’. It’s like trying to change the table cloth while your customers are eating dinner. Once the platform is set, it’s set.
• The House Always Wins: Since you’re building your product on top of Salesforce.com’s infrastructure, they’re at liberty to charge whatever they want and do whatever they want. They could build a product that competes with yours and include it with the next edition. For example, this has happened to some of Conga’s mail merge features. Because of the vendor lock in problem and their ability to kill your product with a flip of a switch, it makes many people uneasy. This is a valid argument but it’s not a problem with Force.com it’s a problem with any On-Demand platform.
• Too Expensive: With a price of $25-$50 per user it would be impossible to establish a business model around Force.com. This may be true but remember, if Salesforce.com puts you out of business, they’re also putting themselves out of business.

I think the critics make very valid points. Obviously these are my commentaries on the discussion. We should remember that it’s still pretty early in the technology adoption lifecycle for on-demand platforms or mainstream SaaS. Most vendors are only starting to warm up to the SaaS business model and have not even thought about what technologies to use. If you’ve read Crossing the Chasm, Early Adopters are now seeing the importance of a SaaS offering and the innovators are starting to think about the technology. Given that the on-demand platform is still a relatively new value proposition, the reaction to Wainewright’s survey shouldn’t be that shocking.

Finally, most ISVs are binded to technologies either contractually or politically. For example, a Microsoft partner may be in a contractual agreement to only use Microsoft technologies. Or, ISVs may prefer a specific technology because of other incentives. What if most of their customers are DB2 and WebSphere shops? Or what if they get deep discounts with preexisting partnerships? Most ISVs are partnered with some technology giant and it would be difficult to shake them loose.