Expert Texture Home Contact me About Subscribe Digipede Connect on LinkedIn rwandering on Twitter rwandering on FriendFeed

The blogged wandering of Robert W. Anderson

Marc Benioff & Hybrid Hosting

Marc Benioff was special guest in the recent Gillmor Gang (VIdeo Gang Parts I and II).   After getting through the initial discussion on earnings we moved on to talk about the SaaS business and their application platform.

Mike Vizard led off the questions about ApEx with a good one: how will SalesForce get developer traction for their language / environment / form?  Marc enumerated several things they are doing about that.  Most of this is kind of “business as usual” for those building a developer community, though I do think that one of their strategies is pretty innovative: rent out cubicles to developers in a building devoted to ApEx development (this is happening in old offices of Siebel — this would be ironic if it weren’t intentional).  These developers get everything they need to build apps on the SalesForce platform.

This may turn out to be of great value to those who are already interested in the platform.  Of course, the drive for developers to build applications on ApEx will come down to one thing: is there a viable marketplace for the applications they build? 

Clearly Marc and SalesForce understand this fully.   They are not pushing the “build it and they will come” mantra; instead, they have built an application exchange (i.e., the AppExchange) to enable a viable marketplace.

On a slightly different tack, I asked Marc to talk a little about their hosting capabilities for third party applications sold through the AppExchange.  Without getting into too much detail about the different kinds of applications that support the ApEx (native, client, hybrid, etc.) there is a class of applications that requires external hosting.  These applications take advantage of the APIs yet are not built on the ApEx platform.  As a result, these applications are not hosted by 

I grok why they choose not to post these hybrid applications.  Doing so requires a different hosting model: one that is application-specific possibly supporting different hardware requirements, different OSes, different staff, etc. I can only guess that they have made the decision not to do this in favor of their “pure” ApEx strategy.  Certainly the “pure” strategy is a lot cleaner, more focused, more repeatable,  more like an “product sale” instead of an implementation sale . . .

However, lets go back to the earlier point of developer adoption.  Wouldn’t it be easier to get developers to adopt ApEx and AppExchange and the whole concept of SaaS if you were able to provide a hybrid hosting solution?

This reminds me a little bit of .NET.   One of the key features of .NET is support for COM.  If users had to throw out their legacy code to begin to adopt .NET in their organization, .NET would have had a much slower adoption rate.  They don’t. 

It sound likes an ApEx developer who wants to take advantage of the AppExchange has to either start everything from scratch or provide their own hosting solution.

So I wonder, would SalesForce be able to ramp up developer adoption rates with a hybrid hosting strategy?

Tags: , , , , , ,



    Jim Benson wrote @ November 17th, 2006 at 10:40 pm

The backward compatibility is important. But I caution developers about taking the lazy way out.

ESRI’s ArcObjects package is a collect of objects for rapid development of geographic information systems tech in other packages. We’ve used it extensively.

However, when .NET came along, rather than rewriting their COM objects, they got lazy and just put COM wrappers around them and called it good. For most people, I suppose, that may be good. But it’s caused us no small amount of trouble.

Maybe backward compatibility should come with a definite sunset date to help spur developers along. Reward adoption to begin with and then move people along the migration path.

    Robert W. Anderson wrote @ November 18th, 2006 at 8:56 am

Yeah, it is a mixed bag. I figured you were going to argue about polluting a “pure” design to cover hybrid solutions. Sometimes those arguments win out, but in terms of COM compatibility I really disagree.

Sure, someday COM may not be supported anymore; however, companies are still beginning the migration to .NET. They still need that COM support.

    Dan Ciruli wrote @ November 21st, 2006 at 2:47 pm

The one thing I haven’t read about AppEx is how developers are compensated–but I am positive that it is part of their model.

I do find the whole product fascinating, though, and keep finding myself comparing it to Amazon’s web services.

Salesforce seems to be at a disadvantage–Amazon’s web services are wide open, and could allow a developer to run virtually any software (this is a big difference between their product and Salesforce’s).

But the developer who chooses the AppEx platform gets two big advantages: the ability to market to an established customer base ( customers), and the ability to charge those customers through the platform/model. Seems to be that it drastically lowers the barriers to entry.

    Mike Leach wrote @ November 22nd, 2006 at 4:21 pm

The PodCast was great and straight to the point. Though .NET vs. Apex seems like an apples and oranges comparison.

Apex coupled with Salesforce’s existing UI designer is more like a PowerBuilder or Delphi for the web.

The Salesforce Web Services API allows Java and .NET developers to get their hooks into the system if needed.

    Robert W. Anderson wrote @ November 22nd, 2006 at 9:08 pm


Thanks for the comment. I certainly didn’t mean to compare ApEx with .NET. That said, your suggestion that it is more like PowerBuilder or Delphi then the comparison could be made between the ApEx designer and Visual Studio as an application builder.

Though my real point was that sometimes there is an advantage in choosing legacy compatibility over a completely new platform. .NET was just an example — not intended to be a language comparison.

Your comment

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>