salesforce.com's Apex language is not the lock-in attempt it appears to be

While I was at Symposium/ITxpo, my colleague Dan Farber was attending salesforce.com's Dreamforce conference where the company announced that its Java/SQL-esque Apex programming language would be opened up for use by customers wanting to use it (Apex) to customize their salesforce.com applications.

When Dan Farber first shared the news with me last week (prior to the Dreamforce event), my reaction was not a positive one. Although Java and SQL programmers will find elements of Apex that make them feel right at home, it's still different enough to be considered proprietary (nothing else I know of uses it). The minute you begin to use something proprietary (or, at the very least, something that's not supported by other vendors), you run the risk of locking yourself into that something so badly that, should the need to switch to a different solution arise, the cost of switching could be too much to bear. The result? You end up staying with the proprietary technology and enduring whatever issues there are that made you want to switch in the first place.

What could those issues be? Well, not that salesforce.com has any of these problems, but maybe there's something out there that offers performance, security, cost, or features that are more suitable to your organization's needs. Or maybe your organization just went through an acquisition and your systems have to be consolidated with those of the acquirer. In the name of flexibility and agility, there are all sorts of reasons to do whatever it takes to avoid getting yourself locked into a certain technology.

Perhaps the best case study of this happened a few years back when Microsoft made some sweeping changes to its software licensing programs. For some of Microsoft's customers, the change resulted in a net positive with the beancounters. But for others, the cost went up significantly (which of course made headlines). But, if you were one of those customers whose entire archive of business documents had been created with Word, Excel and/or PowerPoint, what choice did you have but to take Microsoft's licensing changes on the chin? The cost of converting that archive to some other solution -- a cost that cannot be stretched out over any length time (in an effort to ease the pain) -- far exceeded the cost of staying with MS-Office.

But let's say you were using standard file formats for those documents -- ones that were supported by other solution providers. Not that those formats existed at the time (they do now), but let's pretend they did.  Well, for starters, the cost of switching should you ever become dissatisfied with MS-Office would have been much easier on the budget. Secondly, knowing that it might lose customers if it raises its prices, Microsoft might think twice before doing so. Finally, when those standards exist, the chances go up that some game changing innovative offering will show up on the market and that's what keeps the rest of the solution providers on their toes (working hard to keep your business instead of the other way around). 

So, now let's circle back to Apex. At first, this is exactly how I was thinking about Apex. All sorts of red flags went up. But then, I saw some very public discourse on the issue taking place over on one of Sinclair Schuller's blogs that has me rethinking my hardline position for the first time. Schuller works for Apprenda (a vendor) and, so, anything he writes must be taken in the context of what Apprenda's agenda might be.  But, given what he wrote, Schuller, who points to Dan Farber's interview with salesforce.com co-founder Parker Harris, is my kind of guy. The same alarms that went off in my head apparently went off in his when he first heard of Apex. In a post titled salesforce.com's Apex: Benioff's handcuffs for on-demand (Marc Benioff is salesforce.com's other co-founder and CEO), Schuller wrote:

This sounds enticing and definitely has a lot of “wow factor” fluff associated with it. But once we get past all of this rhetoric, what substance are we left with? What trade-offs are we required to make? The answer is as easy as looking at the history of the industry.....As an industry, we’ve struggled hard and continue to struggle against being “held down” or “locked in”. The ramifications of requiring that an entity or development firm be veritably tied to another are massive, and quite frankly, the proposition sucks. Granted, working with a company like Salesforce.com gives a vendor exposure to a large customer base. This has an inherent value associated with it, but what about long term strategy and what about risk? Harris describes the language as new and powerful, but never mentions lock-in and limiting. We’ve reached a day in age where the advent and proposition of SOA allows use to start forgetting about implementation details and to focus on solving problems, not working around vendor lock in. We have a plethora of languages and implementation platforms that are very good at what they do, and are very open. We know Sun has promised to fully open-source Java giving the community control over much of its definition. Microsoft has published an open specification for the .NET platform and for C#, allowing developers to build new languages for a powerful platform, or build .NET implementations from scratch, such as Mono for Linux. As a whole, the industry is moving more toward interoperability and openness, where reinventing the wheel and building difficult to break proprietary locks is looked at as both silly from technological and strategic standpoints. Why then, has Salesforce.com opted to peddle proprietary nonsense as their on-demand platform and language? Because Benioff wants to handcuff vendors, preventing them from ever leaving. After all, watching AppExchange’s “application” count only go up through the blocking attrition by making it expensive to decouple your business from Salesforce.com is quite nice…

Leaving aside Schuller's confusion of .NET with the Common Language Infrastructure in terms of specifications that were published through Ecma International (the CLI is a subset of the classes found in Microsoft's .NET Framework), he clearly understands the proprietary vs. open debate as well as most and I found myself saying "Yes!... yes!.. yes!" as I read his treatise. However, when I got to the comments where Kingsley Joseph and Adam Gross (both of salesforce.com) make their cases for why Apex is different, I withdrew my "yesses" for further consideration and quite frankly, I'm still undecided on the issue.

Schuller and those who side with his argument would have a sealed-shut case if there was no standard way other than Apex to access the progammability of salesforce.com.  But, across multiple comments, salesforce.com's Joseph argues that that's not the case:

It would be handcuffs if no other form of development was available. You can continue to use our API and build apps on your platform of choice....Apex and the API are equal ways to develop on our platform. An Apex instruction invokes the exact same code that the SOAP API invokes, less the transport related overhead.... We have a great web services API, and Apex can’t do anything that the API [can't] do. There is no crippling of anything. Just another option, which some people find convenient.

If this is truely the case -- that the APIs for accessing salesforce.com's underlying functionality through standard Web service calls will now and forever offer the same fidelity as APEX -- then salesforce.com isn't nearly as guilty of attempting to lock its customers in as it might have otherwise been. This reminds me a little bit of the situation with applications servers that are based on the Java Enterprise Edition (was J2EE, now just JEE) specification. Virtually all of them (from IBM, BEA, etc.) are offered with proprietary extensions none of which corporate America is forced to use. Smart JEE pros know when they're crossing into the proprietary zone, know the potential costs to their organizations of doing so, and know they have a choice not to. So far, no one has raked IBM, BEA or other J2EE providers over the coals for their proprietary offerings because none of those companies are forcing their customers to use them. Here, in some ways, salesforce.com is doing that one better by saying all of its functionality is available through the proprietary route or the standard route: take your pick.

So, then comes the obvious question. If the playing field is level, why on Earth would anyone choose the proprietary Apex route over the standard Web services approach? The answer once again is there in the comments under Schuller's blog and it's the sort of answer that could be fodder for all sorts of interesting discussion because of its on-demand context. Traditionally, the entire switching argument assumed that the solutions you were running and that you might swap out for something else were run locally on your own systems. But with salesforce.com and its contemporaries like Rightnow and Authoria, everything runs in the cloud. If switching from salesforce.com to something else is something you're worried about, then you're right to be concerned about data and code portability.

Setting aside data (salesforce has import/export utilities that work fine... I've used them), one of the primary goals of Web services was to enable easy solution switching. You have to remember that the folks who drove Web services into the market -- IBM and Microsoft -- had mutual reasons for turning software into services that were accessible through standard application programming interfaces (APIs): they wanted to make it easier to steal each others' customers. If the inputs and outputs to and from an API are the same, then the API is abstracting all of the underlying system specifics. That API could be powered by IBM's Websphere just as easily as it can be powered by Microsoft's .NET and the software that calls the API shouldn't know or care which it is (IBM and Microsoft both have their reasons for believing that their products are better ones to power that API).

Much the same way standard Web service APIs can abstract the application infrastructure specifics, salesforce automation APIs could theoretically abstract salesforce automation solution specifics. Provided there were standard salesforce automation APIs that worked across SOA-delivered (services oriented-architecture) salesforce automation solutions (there aren't), it's at this API-level where portability really matters. From an IT management perspective, you'd want the ability to easily decouple your coach from one locomotive, and couple it to another. Even without standard, cross-vendor salesforce automation APIs, just taking the SaaS is a step in the right direction. For example, it's far less work to adjust the code that currently calls one API (perhaps a salesforce one) to make it call another that does roughly the same thing (perhaps a Siebel API) than it is to translate an entire library of source code from one proprietary system to another. 

So, with the SOA approach having such obvious benefits and reduced risk, why Apex? Because  today, depending on the implementation, taking the SOA approach has one other downside if you're someone who has already bought off on the benefits of cloud-based computing. The code that calls the salesforce.com APIs has to be hosted somewhere else -- in most cases, systems that are run by you. For those who are completely sold on the idea of utility computing and who don't want to host any of their own infrastructure, that could be a step backwards. In their comments to Schuller's blog, Joseph and Gross argue that, for those customers that want to have their cake and eat it too -- in other words, have the programmability of salesforce.com without ever leaving the cloud -- Apex is the solution: 

[Jones] If you don’t want to host your code on your own server and just want us to run it, now there is an option to do so. There are also performance and stability advantages to doing that....[Gross] Apex isn’t just a language – its the execution context to run code on demand and in multi-tenant model.

That's the part that made me withdraw my yesses. To the extent that we're talking about general purpose scriptable compute utilities, or, in the case of salesforce automation, vertical scriptable compute utilities, the industry is in brand new territory here. Venture capitalist Mark Gorenberg views Apex as a potential sea-change too. According to my colleague Dan Farber, Gorenberg "hailed Apex as the most significant announcement since Sybase announced stored procedures."

I'd go back even further. Having a debate over whether Apex is proprietary is essentially like arguing over the x86 instruction set when it first came out with the key difference being that, by then, assembler was the widely accepted standard language for accessing a chip's instruction set. Today, there is no widely accepted language for accessing the instruction set of the cloud. Could there be? For example, could it be Java, C#, Perl, PHP, Python, Ruby or one of the remaining handful of languages currently in play? Perhaps. But, does it matter? Did the fact that Intel 8088's and Motorola 68000 could both be progammed in assembler make the machine code for each portable to the other. I think not.

Thinking it through, let's suppose the standard language for scripting salesforce.com was PHP. Now imagine that you want to dump salesforce.com for Siebel's on demand solution. Or NetSuite. Or, even something you might locally host like SugarCRM. And let's assume all of those targets are equally scriptable with PHP (big assumption). The idea that the code -- with its dependencies on salesforce.com specific things like its table structures  -- could somehow be easily dropped into one of those other systems just because it uses the same language is ludicrous. The amount of work to switch would be nearly equivalent to writing the code all over again.  

So, instead of saying "Yes!," to what Schuller has to say, now, I'm saying "Hmmmmm" because now comes the question of whether or not there's even newer ground that salesforce.com could be breaking here.  For example, if they wanted to, for those customers that want to stay with cloud-based computing but that prefer the reduced risk (of lock-in) that goes with a Web services approach, saleforce.com could offer to host some sort multi-tenant scripting environment (using one of the standard languages) that's designed to access salesforce.com via it's Web services API rather than directly as Apex does.

The net result is that instead of you hosting the code that might normally access salesforce.com's APIs, salesforce.com is. If, for example, salesforce.com picked Java as the standard programming language, it would be as though salesforce.com was offering private Java Virtual Machine hosting as a part of salesforce.com.  Theoretically, you could pick anybody to host your JVM (provided there was such a thing as JVM hosting or on-demand JVM utilities). But having salesforce.com host it might have its performance advantages since API calls and returns wouldn't have to cross the Internet. 

Could salesforce have done that or still do it? Sure. In fact, during the Dreamforce conference,  Apex was described as a virtual machine environment.  There are obviously a lot of issues to work through. What languages to support first? How to reliably scale those software infrastructures in a multi-tenant environment? How to support it? But quite frankly, every company that's pushing the envelope on cloud-based computing -- for example Amazon with its revolutionary EC2 elastic computing service -- has to start somewhere, pick its battles, and chip away at perfection (in the customers' eyes). By the way, the traditional hosting business, if you ask me, will be in deep doo doo once offerings like Amazon's EC2 hit their stride and others, perhaps Google, join that race.

Apex is a language that is optimized for developing applications that run on and are hosted by salesforce.com. Java is not. Nor are the others. In fact, what do you get when marinate Java with some salesforce.com specific SQL calls in order to make it easier to build salesforce apps? Apex. In the bigger scheme of things, when you consider how staying with one of the other all purpose languages would probably have done very little to fix the lock-in problem (see my earlier arguments), but how it might have sacrificed some of the optimizations that empower developers to more quickly and easily harness the salesforce platform, salesforce.com ultimately made the right choice for itself as well as its customers. Can use of Apex end up locking you in? Absolutely (at least until other SaaS outfits embrace it.... if salesforce.com lets them). Does salesforce offer an alternative route should you wish to mitigate that risk. Yes. Is the world of computing as we know it evolving right before our eyes? Absolutely.