The launch of Salesforce.com’s AppExchange back in January might have been one of the most successful for any new development platform. More than 200 partners have been signed up in about six months, and 300 applications have been released. By any measure, this is impressive. But what these numbers are not telling is where the platform is going, and what AppExchange 2.0 might look like down the road. I met with Salesforce.com’s Chairman & CEO Marc Benioff today, and gave him my take on the subject, following a discussion hosted last week by the Enterprise Irregulars.

AppExchange is essentially two things: a platform for developing online applications, and a marketplace for selling them. The primary target for AppExchange is an Independent Software Vendor (ISV) that wants to deliver Software as a Service to its customers, without having to build and maintain the infrastructure required for it. Two major editions are available, and cater to the needs of two different kinds of ISVs: the regular edition — for lack of a better term — gives access to the Salesforce.com CRM application, therefore appeals to ISVs that want to sell value-added applications to existing Salesforce.com customers. The newly-released OEM Edition provides the exact same infrastructure, but without access to any business content. As such, it will appeal to ISVs that want to develop standalone applications, without any needs for integration with Salesforce.com.

I like this packaging, for I believe that it will increase Salesforce.com’s addressable market. CRM was a great application to start with, but there is more to business life than dealing with customers — even though some might say that nothing is more important. Personally, I am using Salesforce.com as a generic information management platform, and as such, I would have been perfectly happy with AppExchange OEM Edition, should it have been available eighteen months ago when I started to use Marc’s application extensively. From a packaging standpoint, my only advice would be to allow ISVs to switch back and forth between the two editions, or to support the development and distribution of applications that could work with both, as long as they do not use any CRM-specific functionality.

What makes Salesforce.com unique is the ability to customize the application, by creating user-defined applications, objects, tabs and controls, without having to write code, ever. To a certain extent, Salesforce.com does for data what a good BPMS does for processes, and the archetype Salesforce.com developer looks very similar to what I call a process analyst with respect to her skillset — this explains why this post is the first in my new weekly BPM 2.0 cycle. Now, such a capability is offered only for custom objects at present time, and the only way for developers to create custom business logic is to use the AJAX toolkit, which has two limitations: one, it only supports browser-side business logic, not server-side; two, it requires developers to write code manually, which goes against Salesforce.com’s model-driven development philosophy.

In order to deal with the first limitation, my suggestion was to add support for server-side custom code execution, as discussed in this previous article. In a perfect world, AppExchange would support multiple languages, PHP and JavaScript at the very least. PHP because it’s the most popular (3 million developers out there), JavaScript because it would allow developers to learn and use the same language for both browser-side and server-side execution.

BPM is the answer to the second limitation. Should Salesforce.com embed a BPMS such as Intalio’s within the AppExchange platform, developers could create custom business logic, design complex workflows, and integrate with on-premise applications, without having to write code. For complex processes, an Eclipse-based process designer would extend the AppExchange Toolkit for Eclipse. And for simpler processes, an AJAX process designer could be developed using a subset of the BPMN notation and be accessible with any web browser from a new Salesforce.com Setup -> App Setup -> Build menu option. Some existing Salesforce.com customers and partners have already expressed interest for such a capability, and we are seriously considering it today.

Another area where I believe AppExchange should be extended is integration. To date, 23 integration tools are offered by the AppExchange, but my take is that basic integration capabilities with the most popular databases and packaged applications should be offered by the AppExchange platform, out of the box, and at no extra cost. Salesforce.com recently made a step in this direction when releasing a connector for SAP R/3, and all we need are similar connectors for Oracle, PeopleSoft, Siebel. Similarly, it would make sense for Salesforce.com to make a deal with Spanning Partners in order to provide RSS feeds for both standard and custom objects. This would encourage developers to use such a functionality more broadly. Also, I reckon that my good friend Charlie Wood is working on a way to synchronize Salesforce.com events with Google Calendar, extending the newly-released integration with Apple iCal. If there ever was a Web 2.0 killer app for Salesforce.com, this is it.

Last but not least, adding simple document management capabilities to the AppExchange platform would enable a brand-new range of applications that require custom development today. Simple versioning is all that is needed really, but basic integration with Office 2.0 applications such as Google Spreadsheets or Zoho Writer would be a nice addition too. We might want to leave these for AppExchange 3.0 though.

To summarize, adding server-side code execution, standards-based BPM, SOA-like integration and simple document management capabilities to the AppExchange platform would turn Salesforce.com’s most recent initiative into a legitimate platform the developing enterprise-grade applications. Salesforce.com has done a great job of listening to its customers and partners over the years, and its success in launching AppExchange is proof for this. Let’s hope that Marc and his team continue down this path.

Aloha