Salesforce.com OEM thoughts

Those of you who regularly read my blog (and I mean both of you) know that I'm a fan of many things that Salesforce.com does. As such, I found the announcement a few weeks ago of the OEM product to be very interesting. I've talked to several folks much more knowledgable than I over the last couple of weeks andI think the platform play is a great way of building a SFdC ecosystem. Smaller ISVs get access to what I understand is an easy to get going on platform and great online and community support (including a chief architect who answers developer questions posted to the forums). The documentation is also supposed to very good and I've heard Salesforce.com as being called "easy to work with."

However, some limitations were pointed:

1. Limit of 50 custom objects and 5 custom tabs. The ISV can create up to 5 tabs of their own, but no more. This means that the user can't get extra functionality that needs another tab. For example, there is an expense tracker available in the AppExchange, but since it needs another tab and most ISVs use all 5 tabs, the user can't install it.

Limit of 5 tabs will drive user to SFdC CRM product. Long term this will mean a whole new market for SFdC, not for the vendors. Buyer may start with OEM product, but won't stay on it a long time because of tab limit. "Oh, I guess, I'll just buy Professional edition and pick up the ISV's(e.g., Remend) app in AppExchange." My understanding is that the ISV has greater revenue from the OEM product than the AppExchange addon.

2. Integration

Some of the pre-built connectors built to link SFdC to other applications (ERP etc) may not work with the OEM platform products. Missing hooks into some objects (contact, deal). Object is a record type

• e.g., Any connector referring to the Opportunities tab will run into problems as this tab doesn't exist on the OEM platform product

3. If a vendor writes a "Native App," one built using the Salesforce.com web builder and hosted by SFdC, there is currently no way of hiding the code. My understanding is that if an ISV wants to protect their code, they are are told they should develop a Client or Hybrid App (which store the app logic on the ISVs servers).

4. ISV selling app thru AppExchange has to handle billing on its own. For example, the link from AppExchange goes back to the ISV website for billing, authentication etc. AppStore is likely the way they are going to introduce billing into AppExchange.