Maintaining Dual Products with Salesforce.com’s Apex: Does it Make Sense?


I recently read a comment by Marc Benioff that baffled me. Dan Farber recently interviewed him and summarized the interview in his latest post Salesforce.com’s platform ambitions. In the interview, Farber asks Benioff whether a company like SuccessFactors should write natively to the Apex platform instead of just integrating with Salesforce.com through the sForce API. Here is the excerpt from Farber’s post:

“I [Farber] asked him [Benioff] whether a company like SuccessFactors, which has an HR on demand application with more than 2 million subscribers, should write to the Apex platform, rather than just integrate with the salesforce CRM application through Web services. ‘I think it would be wise to natively support our platform and have a version on their’s. There is no reason not to do both,’ he said. ‘I am sure their competitors will if they don’t…’”

Say it ain’t so! Hopefully one you (the readers) can help clarify this for me, as my nimble mind seems to be crippled by the weight of Benioff’s reply. What I got out of it is that Benioff recommends you, the software engineer or ISV, maintain two equivalent products as two implementations: one of your own likings and one using the ultra cool, ultra fantastic (sarcasm) proprietary and closed Apex language and stack. That is, maintain two code bases, market two products (I guess one to Salesforce.com customers and one to everyone else??), patch two different products when you find bugs, etc. Oh, and by the way, if you don’t your competition will; the advantage of spreading themselves thin will undoubtedly endow your competitor with the ability to crush you in share of market numbers. Ok, I must admit, that’s simply my take on that excerpt (and don’t forget my disclosure, I founded a SaaS platform company of my own) so I’m asking anyone reading this to weigh in: what do you think Benioff was trying to say? Did I understand it correctly?

Links
View Technorati Links

SaaSBlogs Tags
Tagged with: •

(2 votes, average: 4.5 out of 5)
Loading ... Loading ...

Information and Links

Join the fray by commenting, tracking what others have to say, or linking to it from your blog.

Information
January 22nd, 2007
3 Responses
Feeds and Links
Comment Feed
From This Author
Del.icio.us
Digg
Technorati
Categories
Business
SaaS

Other Posts
It Costs More to Be a SaaS Company. How Platforms May Fix That.
SaaS Ecosystems: Are They Valuable and To Whom?



Write a Comment

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

Reader Comments

Comment Number:
1
Written by:
Matt Ammerman
Posted on:
January 23, 2007 at 4:07 pm

Sinclair,

It’s probably not fair for me to reply here because we talk about this every day, all day… but I’d like to extend your example and reframe the question:

If your understanding is correct, and Marc Benioff proposes that developers fork their projects and maintain an Apex codebase, then let’s assume that other platform players will follow in his footsteps. After all, the only safe platform is a “walled garden” right now, right? Well, then my question becomes… what makes developers interested in jumping on a platform? This is the cannibilization notion we talk about all the time in SaaS. In order to pursue SaaS, you (the developer) must give up a piece of your core competency to join one of these platform ecosystems. What is the most important part of that decision on the developer’s part? Is it just a matter of “My CTO told me to do it, so I’ll start writing Apex code too.” Is maintaining, say, .NET code AND Apex code for the same product an issue in anybody’s eyes?

I’m interested too.

Comment Number:
2
Written by:
Aimee
Posted on:
January 24, 2007 at 5:56 pm

I have no idea why someone would say that. It makes no sense at all! I totally agree with you!

Comment Number:
3
Written by:
Jesse Kliza
Posted on:
January 25, 2007 at 10:13 am

Mr. Benioff has always made bold statements about his company.

Recently (as noted in the above referenced post by Dan Farber) he said: “We will destroy Oracle and SAP because they won’t be able to respond to the innovation we are about to unleash.”

Personally, I don’t see APEX as a formidable innovation capable of destroying Oracle and SAP. Though I may be wrong, and Salesforce may also have a number of other “tricks up their sleeve” so to speak.

I took his quote about maintaining dual products with Apex as another bold statement. I think it is more wishful thinking on his part. For his statement to be considered reasonable, one would have to assume that APEX will one day become the platform of choice for end-users. So much so that end-users would come to a company like Success Factors, and say…”We know you have an awesome on-demand product, but we love APEX for some reason, and we won’t subscribe to your app unless it runs on APEX.”