Cloud vendors understand how important developers are to their future, and they compete for developer loyalties by integrating open source tools with their environments. Red Hat's OpenShift Enterprise is a leading example, as well as VMware's Cloud Foundry and Spring Framework.

To expand the horizons of software-as-a-service (SaaS), Salesforce.com needs to attack the same problem in its own way. Salesforce.com is providing the programming means to reach out from a focused CRM and human resources set of applications to connect with other applications in the enterprise and bring useful information from them into Salesforce apps.

Its primary instrument for doing so is Salesforce Identity, which can build a federated directory of enterprise users, then manage user access across many applications from the existing Salesforce application environment. The service is still in preview status and scheduled to become available as a supported service in winter 2013. Without this building block, Salesforce would be hard pressed to know how to connect to any non-Salesforce application in its customers' environments.

Further in the background, but probably more important in the long run, is the Force.com Canvas service. It provides a software development kit to enterprise developers that lets them tie a new application, built either inside the data center or on the external Heroku cloud, into the Salesforce user interface. Canvas provides JavaScript libraries that can be invoked by a developer to tie application services produced in different languages into the Salesforce user experience. Until now, customization was done largely in Salesforce's proprietary Apex on the Force.com platform.

[ Want to learn more about Canvas, introduced at Dreamforce in September? See Salesforce.com Seeks Foothold Throughout The Enterprise. ]

In the early stages, it's hard to see exactly where the new capabilities will lead, but active customers have ways of thinking up uses for them. Salesforce is increasingly committed to expanding the capabilities of SaaS so that it is not stuck on a limited set of branded applications. From its position of strength in CRM and social networking, Salesforce is beginning to provide services to enterprise applications that were originally thought to have been totally separate from CRM.

Or at least, it's possible to conclude that as you come away from a conversation with Quinton Wall, director of developer evangelism, and Chuck Mortimore, VP of product management for Salesforce Identity. Both argue that service additions and custom enhancements can now take place on a much larger scale than before with SaaS.

Legacy applications still tend to be isolated systems inside the enterprise. Salesforce is trying to be a centralizing force for them as it provides for an Identity service, easily activated by anyone with a Salesforce account, and combines personal information from Active Directories and LDAP directories around the enterprise. "We can drive more of a streamlined identity management system, a single-sign-on system" if enterprise IT moves to using identity management as a service in Salesforce.com data centers, instead of exclusively relying on its own Active Directories.

Canvas has much broader implications. It could be used to connect a new custom service, built on the Force.com platform, to an existing Salesforce CRM application. But it could also be used to connect a custom service built in a non-Salesforce-generated language, such as Java or Ruby, to a Salesforce application.

Canvas allows the Salesforce-savvy developer to take an existing isolated application -- Wall likes to refer to them as "ghost town" applications: no one goes there anymore -- and think about "how can we take it and put it in a social network context ... make it an active part of the conversation."

The whole application wouldn't suddenly become part of the Salesforce application suite but some action of the application could be imported into the Salesforce context. One example is connecting the procurement system so that each purchase indicates how many fellow employees have purchased the same product.

That could previously be done inside the enterprise through a heavily engineered, point-to-point connection between a procurement app and the Salesforce.com app. Why not make it simply a Web service integration to a customer's Salesforce.com database, with an ability to call up the information the next time it's relevant?

Canvas provides JavaScript libraries that know how to connect to existing Salesforce SOAP or REST APIs. To the end user inside the familiar Salesforce.com user interface, the information seems to come from inside the Salesforce environment, along with all the other application services, even though an outside system is now the source, said Mortimer.

"We can take the legacy applications and expose them inside the Salesforce user interface," he said. One of the standards relied upon by Canvas to do this is OAuth 2.0, which authorizes an outside developer's application from the developer's private key to proceed and work with a Salesforce data center application.

The example is simple enough, but many more possibilities will emerge as Salesforce users contemplate what they might build on the Heroku cloud, now owned by Salesforce. There they can use many languages to construct a new application or service, then link it into their Salesforce suite. They can likewise add social networking features to the legacy app, extracting specific information and exposing it in the enterprise social graph.

From its name, it's possible to say Canvas is meant to provide Salesforce.com users with a broader palette with which they can paint a widening set of application linkages, pushing the horizon back from its current tight focus on CRM, HR and Chatter.

"With Force.com Canvas, developers can retool their legacy Web apps, or write new apps that instantly tap into Salesforce regardless of what language they are written in, or where they reside," said Wall.