SmoothSpan Blog

OnStartups has a great post that is critical of Force, Salesforce’s SaaS platform, as a desirable way to access a platform.  I’ve said before that my concern about Force is it’s basically a very conventional platform that’s been hosted.  The tool looks a lot like SAP’s ABAP, Peoplesoft Peopletools, or a host of other Enterprise platforms.  This is something Salesforce would never let an app vendor get away with: just hosting your app without radically improving it along SaaS lines with things like multitenancy is a no-no.

OnStartups drills down to the next level of detail to make some excellent arguments that deserve a much closer look:

• Lack of an Ecosystem
• Upper Limit on Growth
• Royalties
• Lack of Price Controls
• Gives Salesforce Too Much Power Over the ISV Using the Platform

Enterprise Irregular Rod Boothby agrees,  and suggests that while it isn’t ideal for software startups, there may be other audiences Salesforce is more interested in:

But I think force.com is aiming at a slightly different audience. force.com is aiming as corporate IT departments with only a couple of coders on hand, and no real resources to build and deploy ad-hoc internal applications. External consultants also fill this role. For these types of users, there may be some benefits to going with a company like force.com.

Before we throw the whole Platform as a Service idea out based on Force, let’s drill down on each of these and see if we can identify some cures that would make people more comfortable with the idea of a Platform as a Service.

Lack of an Ecosystem

This is a big one that plagues a lot of would be platform services, and not just Force.  Tools like Coghead and Bungie are in the same camp.  OnStartups says, “Where will you find other developers? Books? Training? Tools? Components?”  These are all good points that go to the inability to use any existing tools that already have vibrant ecosystems inside Force.  This has some deep implications.  If you require developers to adopt a completely proprietary approach where their old tools are no longer applicable, you create two problems.  First, developers hate having to relearn everything.  Second, developers become suspicious about what they’re going to do if they run off the edge of the platform.  Being able to employ familiar tools offers a safety valve.  The failure to address this is one of the big shortcomings of RAD and 4GL tools.  When you hit the limits of their models, you were done, and this happened all too often.

Amazon EC2 is a great example of a Platform as a Service that embraced familiar tools.  Yes, you will have to write some custom code to use it, but that code is largely around orchestrating familiar components written in familiar tools that have ecosystems.  That means developers have a much smaller learning curve:  just what’s new in Amazon EC2.  And, they can tap into their familiar ecosystems because Amazon supports a crude component model in the form of Linux virtual machines.  We can quarrel about whether finer grained components would be nicer, but the beauty of Amazon’s approach is they get to tap into any ecosystem (say open source components, for example) that runs on Linux.  That’s powerful!  I wrote about my visit to Amazon’s Startup Project, where they bring in enterpreneurs using their Platform as a Service to talk about it, and believe me, it was very interesting.

Here’s another aspect to the ecosystem argument.  Why not Open Source the platform?  We’ve gone back and forth about Open Source and SaaS before on this blog, and it surely doesn’t make sense for a lot of things, but it seems extremely valuable for a platform.  The platform vendor would employ one of the strategies Open Source vendors apply to retain economic return from the code, but the Open Source conveys several advantages to the PaaS vendor:

• It’s a nucleus for another community to build up around in an area that Open Source traditionally shines in: platforms.  It’s been proven that these communities can spring up in a hurry when you give them source.  Look at how quickly some of them have come into being when they’ve solved a real problem.
• It’s a safety valve in the event there is a problem with the platform.  It makes it dramatically easier for would be platform users to envision life if the platform vendor went bust.
• It helps facilitate platform adoption.  Engineers will want to get inside and kick the tires before adopting a platform.  With Open Source, it’s all right there to look at.  This has been a recurring theme with Open Source companies I’ve talked to like SugarCRM.

Upper Limit on Growth

Like the lack of an ecosystem, this one also has elements of a fear of the unknown.  What happens if your product is phenomenally successful on the Force platform?  The example given is what if you build the next Facebook?  Can the platform keep up, or will it hinder you?

This is a very interesting question, and one where I agree with the writer that Force has problems.  Before we look at the concerns, let’s keep a perspective on what the Salesforce people will say:  if you can actually build an application that rivals Salesforce, you’ll be our most important customer and we’ll do everything we can to help you succeed, until then please remember we’re the most successful SaaS company to date!

It’s not a bad answer, but I’m not sure it’s a great answer.  I think of it as a question of business focus.  How large does your application get before it becomes distracting to Salesforce?  At that point, you’d better hope your interests are well aligned and that they really do want to help you succeed.  Because of the lack of ecosystem, you’re stuck if they don’t.

Now let’s flip back around and look at Amazon EC2 again.  It’s not the only game in town, see 3Tera for another placeholder that’s interesting and along similar lines.  And that is precisely my point, by the way.  If the PaaS is capable of running on multiple sets of infrastructure, that seems like a mighty good answer to me.  Think of it as the next thing after the LAMP stack.  Many providers offer LAMP, what is the equivalent PaaS/SaaS solution?  What comes after LAMP for more power and scalability, more business features needed for SaaS, and the ability to use a Polyglot Language strategy?  Picture such a thing available on multiple hosting infrastructures and we’re starting to get somewhere.

We will see a lot of big companies get engaged in the Utility Computing Hosting space.  I’ve named 2, but we can expect IBM, Google, Microsoft, and many others to dive in.  Sun offers Sun Grid today as another example.  What if the PaaS is more of a middle man that can rehost to any of those services, including more than one service at a time?  Doesn’t that give it more legs to deal with the “Upper Limit on Growth” angle?  Moreover, I would argue platforms should be the PaaS company’s only business, and not a sideline like Salesforce.  I’d rather my platform vendor not be building apps that could potentially compete with me, thank you very much.  This means their focus is totally around making applications built by others successful on the platform.

Royalties

OnStartups worries that royalties can burden a startup to the point where it can’t compete successfully.  Force charges $25 a seat/month, which is a lot. 

It’s a lot indeed.  If we take the average of 3 SaaS vendors (Salesforce, Concur, and RightNow), they spend about 22% to deliver their services.  To get to that competitive benchmark, you either have to talk Salesforce down on the price (good luck, they’re legendary for sticking to guns on these prices), or you had better be able to charge $25/22% which is almost $114 a month for your app.  That’s a LOT more than Salesforce charges, BTW.  Suppose you want to charge $60 for your equivalent of Salesforce.  That means your PaaS vendor has to be willing to host you for a little over $13 a month or you won’t be competitive.

This seems like a massive showstopper, and in all honesty, I don’t expect it to change for Force.  Their argument will be that you’re getting the benefit of their community so that the platform delivers sales leads, and those are where the value is to offset the cost.  The reality is you can get that benefit a lot more cheaply, as many are doing, by building a small component around Force and keeping your flagship off the platform.  The small component gives you a reason to talk to Salesforce customers, and if they like it, it can be unbundled to a few seats while you sell the lion’s share of your product on a different platform.  How long Salesforce will let that continue remains to be seen.  However, if they tip their hand by being predatory about it, that’s just another reason to look elsewhere for a platform.

Must royalties be a poison pill for any PaaS offering?  I don’t think so, but they have to be inline with the economic model.  Suppose we take my 22% cost to deliver services.  If the PaaS can host the new application for 22% and provide other significant advantages such as time to market, why wouldn’t you consider it?  In this case, you’re just paying the PaaS vendor what you have to pay a hoster anyway.  In fact, I’ll submit there’s room for a little extra for the PaaS vendor if the platform really got you there an order of magnitude faster.  The thing is, the business model for the PaaS vendor must not be at war with the SaaS vendor building atop the platform.  This is possible if the PaaS economics slot into and replace existing line items for the software vendor.

Lack of Price Controls

Another great point.  Imagine you’ve built the next great mousetrap on a PaaS.  You started out with a reasonable deal along the lines of the 22% I mention above.  It seems like over time, the more you succeed, the more your PaaS vendor ups their prices, which allows them to siphon away all of your profits.  Terrible scenario!

What’s the answer?  First, it has to be possible for you to move your software in a reasonable amount of time to new lodging if it gets too ugly.  I’ve been involved in projects that involved radical rehosting around an OEM platform, for example.  That means software that has some 3rd party component at its heart, something happens, and suddenly you have to do a rewrite to replace the 3rd party.  In these cases, a “reasonable time” seems to be about 1 year.  The job can be done in less time, but the platform user feels less pressured if they can take up to 1 year without undue stress while staying on the PaaS in the meanwhile.

What about those price controls?  SaaS vendors like Chris Cabrera tell me that the solution is to sign a 2-3 year contract.  BTW, this is pretty typical for OEM component deals too.  You don’t pay BOBJ to embed Crystal Reports on a month to month deal.  You sign a 3 year contract so that your development cost is amortized over a reasonable period.  That contract sets the price during it’s term. 

So what happens at the end of the contract?  If it were me, I would simply negotiate an extension 1 year before the end of the 3 year contract for another 3 years at prices negotiated.  This makes it very manageable for the platform user to understand what it will cost them and to prevent the PaaS vendor from suddenly spiking their fees at an inopportune time.  Most ISV’s would view this as a comfortable deal because they’re familiar with these types of terms from OEM deals they’ve made.  If you can’t come to terms, you have a full year to rehost to another platform, which is doable.  SaaS CEO Steve Singh said in my interview of him that SaaS works so well because it keeps control in the hands of customers.  That’s what’s needed here too.

Such deals also benefit the PaaS vendor because they further establish stickiness and long term recurring revenue while eliminating an important objection to the sale.   Salesforce will likely give such a deal too, but the rub will be getting the deal at a price that’s economical.  Salesforce will tell you, “Show us the volume and we’ll show you the quantity discount pricing.”  The PaaS vendor has to be willing to negotiate a low price without having huge volumes yet.  This can be factored into the contract as well. 

Gives Salesforce Too Much Power Over the ISV Using the Platform

The last point is one of the most important.  I’ve written about this before when I said your platform vendor needs to act like Switzerland, and not be bent on world domination.  I gave some examples of “Swiss” platform vendors.  Adobe has done a great job for a long time not making Flash, a platform for rich user experience in the browser, punitive.  Ning does a good job not competing with their customers.  This is really the issue: is your PaaS vendor going to be tempted to enter your SaaS market?  If they’re already an application vendor, it’s scary.  What are the chances Marc Benioff will let a breakthrough CRM component thrive on his platform versus taking steps to force them to sell to him or worse, building a competitor?

BTW, the steps I’ve recommended above give customers of the PaaS platform recourse if the PaaS vendor gets too rambunctious.  If the platform is Open Sourced and runs on a variety of hardware infrastructures from companies like Amazon and others, worst case is you can take your marbles elsewhere.

Conclusion

Building SaaS software is hard: 

• 70% of what you have to build will be wasted, because it doesn’t create proprietary advantage.  It’s things every single vendor does almost the same way, but that still have to be built and tested.
• There are no good platforms yet that embed most of that 70% of basic things business software needs, let alone the next tier which is what a SaaS vendor needs (such as multitenancy).  Everyone has to “roll their own”. 
• There’s not even really a good ecosystem around SaaS.  There are a ton of Open Source components and ecosystems around Social Web software, or simple Web software niches like E-Commerce, but SaaS remains very proprietary.

A platform that saved a lot of that waste, that slotted into an economic model the SaaS vendor could live with, that worked on a variety of hosting layers like Amazon’s EC2, that didn’t make you relearn everything and integrated with existing tools and ecosystems would be a hot commodity among the folks I know who are building out SaaS companies.  Even the web startups are beginning to wonder whether building yet another ad-supported social network is a viable business model.  They should be looking at delivering Web 2.0 to business, but business is used to dictating a whole list of requirements the garage shop angel funded web world hasn’t yet come to grips with.

Related Articles

Since this post is very highly ranked by Google when you search “Platform as a Service”, those coming here should be sure to check out the rest of the blog.  Platforms as a Service, SaaS, and Cloud Computing are the major themes I dwell on here.  There’s always something new going on in the Clouds!