Later this morning, I'm heading over to the Open Source Business Conference here in San Francisco to do a panel on open APIs. I was asked to send the moderator a few sentences on "why I'm on this panel", and thought the result might be worth sharing here.
In the cloud, if you're not interoperable, you're irrelevant. If your APIs don't create new opportunity for developers, you're unattractive.
More than half of the workload carried by salesforce.com systems arrives through our API, rather than coming in through the UI of one of the applications that we ourselves offer on our platform. By that measure, we're more an API company than an applications company. That ratio will continue to grow. When we launched our new Chatter product, API access and integration of that API into our existing product set came first; the stand-alone product will come later.
We are also a consumer of APIs: most of the truly interesting stories about enterprise use of salesforce.com are stories of integration with a combination of both on-premise resources and other providers' cloud services. The more APIs there are in the world, the more the advantages of high development productivity in our Force.com environment can translate into diverse business benefits. Bilateral APIs make us a potential addition to the toolkit of every developer, and make every other API-accessible resource a potential expansion of what our customers can get through us.
Lock-in is the nasty way to talk about leverage. If people valued portability over all other attributes, we'd see far more 80×25 text-mode applications running in windows on our Windows and Mac OS X and Linux machines. Microsoft took a calculated risk by dropping dual-platform, Windows and OS/2 support from the first shipped release of Visual Basic (I personally reviewed the page proofs of the dual-platform documentation): the market weighed the drawbacks of building Windows-only applications against the incredible improvement in speed of crafting and deploying a highly usable tool, and voted by a landslide for developer leverage. Ditto the combination of iPod/iTunes: that offering came into a market that already had non-proprietary ways of getting non-proprietary files downloaded to versatile personal devices, but the market voted for something that simply worked better — leverage for consumers, not developers, but the same market choice nonetheless.
That said, every platform must have a story that gives developers freedom to put some things where the leverage is greatest, but puts other things where portability is preserved. If you're writing an application with a useful life of months, you want the leverage; if you're developing intellectual property that's going to be an asset for years, you may prefer to code that in a way that lets it be used in as many environments as possible. We have many examples of applications being partitioned in this way to use Force.com for high-leverage delivery of a superior user experience, while using other facilities to run existing code in a scalable environment.
On the other hand, nothing should wrap itself in the flag of being a non-proprietary standard where that value proposition is not truly fulfilled: WebSphere Java applications aren't Oracle Java applications, for example, no matter how standard the Java language itself may be.
Have a great day.