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

Summary: While I was at Symposium/ITxpo, my colleague Dan Farber was attending'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.


While I was at Symposium/ITxpo, my colleague Dan Farber was attending'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 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 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 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's Apex: Benioff's handcuffs for on-demand (Marc Benioff is'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 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 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 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 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  But, across multiple comments,'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's underlying functionality through standard Web service calls will now and forever offer the same fidelity as APEX -- then 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, 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 and its contemporaries like Rightnow and Authoria, everything runs in the cloud. If switching from 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 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 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 was PHP. Now imagine that you want to dump 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 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 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, could offer to host some sort multi-tenant scripting environment (using one of the standard languages) that's designed to access 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's APIs, is. If, for example, picked Java as the standard programming language, it would be as though was offering private Java Virtual Machine hosting as a part of  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 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 Java is not. Nor are the others. In fact, what do you get when marinate Java with some 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, 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 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.


Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Excellent Continuation


    Thanks for continuing the discussion. You made some points that were well-taken! Although I must say, a correction is due since "the CLI is a subset of the classes found in Microsoft's .NET Framework" is not true. The CLI is a specification, as I mentioned in the article. What you're referring to is the CLR, a CLI implementation.

    That aside, I do agree that regardless of my opinion Apex, has achieved an early milestone (see And yes, I do understand that their is an alternate means to accessing HiFi Apex. The vision laid out for Apex, both at the conference and through their marketing, however, shuns the notion of accessing Apex through web APIs, and rightfully so. Service delivery platforms like Apex, used in their full hosted splendor, is what the excitement is about. It means a vendor would not have to learn to be a hosting company, buy hardware, hire staff, just like Benioff said. The code-portability is a caveat, however. Apex, because of these portability issues, manages to de-shackle vendors from SaaS and shackle them to While your Java App Server analogy is somewhat relevant, the problem is that for the entire set of an app server's defined space, there is some subset (a powerful one named the Java EE spec), that is common with the remaining app servers. This makes an ecosystem that is 90% portable across the app servers, which is what most devs shoot for. For example, if I dislike JBoss, I can uproot with relative ease and make my way over to WebSphere. Where do I go with my oodles of Apex code if I want to up and leave. I think there are two branching visions, I side with one that draws a parallel between SaaS service delivery platforms and modern application servers, leaving the "serving" up to the server and "defining" up to the businesses and engineers.

    I'm sure this debate will continue to grow in the near future, and it'll be very interesting to see where we all end up!

    Sinclair Schuller
    Sinclair Schuller (Apprenda)
    • Not exactly

      Hi Sinclair...relative to salesforce automation,....the JEE environment is general purpose environment. There are no assumptions about what it's supposed to do. So, it makes perfect sense that you might have some Java code and want to move it between Java app servers. And, there's a community of solutions that has formed around Java to build competible Java application servers.

      That example might be relevant if, say, there was some similar community that has formed around what equates to a vertically oriented application server (the vertical being salesforce automation). But right now, that community doesn't exist. There's no common platform selection that has taken place between Siebel, Salesforce, NetSuite, the idea that you might be able to write code that runs in the Salesforce VM and drop it into the Siebel, NetSuite, or etc VMs (which don't even exist) makes zero sense. Even where APIs exist, there's no commonality. For example, there's no standard Web service API that returns "all campaign members" across SFA solutions (an example of a vertically-oriented call that could easily turn up in a list of standard SFA Web services calls, but not a list of standard ERP Web services calls). And, if you ask me, if standards need to happen within verticals, it should start with XML schemas and work it's way up through Web services APIs long before it gets to vertically oriented VMs and the scripting languages that run within them.

      Could the salesforce automation community get together and standardize on some common SFA-specific language that works across all their platforms? Sure. Could try start that community? Sure. Does that mean or any other vendor in a similar position should wait until such community (let alone agreement) exists before giving customers access to a programming environment that's optimized for scripting a cloud-based and vertically oriented utility? I don't think so.

      Bottom would take way more than standardization on a language to make SFA code portable from one SFA platform to another. It's completely different than porting your own custom code from one JRE to another. Under the hood, all certified JREs must respond identically to calls for SQL or memory allocation and the like. Under their hoods, none of the SFA platforms respond identically to anything (some can't even be scripted). There are simply no common underpinnings in place to make SFA-oriented source code portable. So, we can't possibly say that shoulders the entire burden of fixing that problem and that it should wait to deliver value to its customers in the interim.

      • ISV Lock-In

        Hi David,

        I don?t think that the point of contention is that we need a standard SFA, or ERP API. I also don?t believe that standards should happen within verticals. To me it seems to defeat the purpose of true standards.

        It seems like Sinclair is talking about writing independent applications on Apex, not SFA extensions. That?s where I too believe the lock-in comes into play.

        I don?t think you could build a brand new application using Apex?. decide that you're not happy with the Apex ?platform? anymore, and the next day have your application up and running again for your customers somewhere else. It?s not about locking in the consumers of the services; it about locking in the ISV?s developing the applications as services.

        Jesse Kliza
        • ISV Lock-In

          Hi Jesse,

          I think you've nailed it. Apex provides customers with additional power to customize and mold salesforce to their individual needs. But an equally important motivation is the establishment of an on-demand development platform that without Apex is lacking as a "platform".

          There is definitely a certain commitment involved when deciding a platform on which to build a solution, whether it's .NET, J2EE or Apex. Porting a web application from .NET to J2EE or the other way is not a high value activity. The Apex proposition includes more than just the logic or IP that goes into the code, it includes the "stack".

          Apex delivers its value in the context of creating a net new SaaS application where the value of the stack being in place is a compelling business decision.

          The lock-in question seems to be a bit of a red-herring as there aren't alternate "cloud" platforms from which to choose your language from.
          The decision to be "like" Java and plsql was made to allow developers, both ISV and IT, a familiar environment that can leverage their skills and knowledge within.

          Dave Carroll
        • Extensions? Are you kidding?

          check out the video (on the right) here:

          Or look at the sample code here:

          and the way it refers to contacts and accounts.

          The context of these examples very clearly CRM/SFA.

          While there's no question that an innovative ISV could leverage's schemas to build some sort of non-CRM/SFA application (turning the infrastructure in a general purpose compute utility), the demonstrated context in these links is clearly CRM/SFA.

          So, I'm not talking about writing SFA extensions either. Apex is already one big honkin' CRM/SFA extension as it is. And that's my entire point. To the extent that the extensibility of Salesforce's AppExchange appears in the Apex language, show me where that exists on other SFA/CRM platforms and where the opportunity for normalization and portability between Apex and whatever corresponds to it (on those other platforms) exists now? It doesn't.

          So, sure, like I said in my original analysis, if you use Apex, be aware that you're entering lock-in territory. But, it's not like there's some other non-SOA way to portably script a CRM/SOA platform that is portable to other CRM/SOA platforms and that should have adopted first. If you want portability, take the SOA path (even that, given the lack of any vertical standards at the schema and API syntax levels, isn't very portable).

          Bottom line point: No matter what you do in the CRM/SFA, you're pretty much locked in. The best case scenario (way different than, say, Google's Writely and IBM's Workplace both being able to open and manipulate the same OpenDocument-based word processing document) involves imports/exports of data where the no custom fields were added and some amount of massaging would still be involved.

          • Wow

            First, let me say I never expected this discussion to go so long, but it's quite fun to see so many opinions!

            Apparently, we all agree on the same thing (kind of). Apex does a very good job at allowing you to build a SFA application where the dataset/schema is tightly paralleling the application. This can be viewed as an "extension" or an SFA "application"; naming is irrelevant. And to that end, it's obvious that "lock-in" is also irrelevant because it would be absurd to be able to move your CRM code to say, SugarCRM. The rub then lies with Check out this video of Benioff:


            or on the Apex landing page, read this "...a powerful new tool for developers interested in building the next generation of business applications." It is not immediately described by *anyone* at Salesforce as a platform for scripting their CRM platform. The vision is clearly defined as the premier platform for building on-demand applications, period. Based on that, one would easily interpret that you could build a Writely, or BaseCamp, or whatever. Well, in those scenarios, I would venture to say that lock in becomes very important, and portability between different on-demand platforms because very important. Imagine you want to deploy a regular old website. Now, imagine for a specific web host you had to use some variant of PHP that only they had that gave you first class access (through the language rather than libraries) to a shopping cart. What happens when you end up hating their customer service, or the speed? If you uproot, you will spend time and money. On the other hand, there are many hosts that support PHP, JSP, ASPX, etc.

            I think things would be a lot clearer if the "vision" and marketing signal delivered by Salesforce was much clearer, but it does seem that they want you to write on-demand apps from scratch rather than simply "script" the CRM engine.
            Sinclair Schuller (Apprenda)
  • Thanks!


    Thanks for listening to our case and for quoting me. Your thought process is the exact same one that I went through, starting with my first reaction, which was "why are we re-inventing the wheel ?" In the end Apex will empower our customers and developers more than anything else we could have done. Your last paragraph pieces this together more succinctly than I've managed to do.

    As for the argument that this is only going to be vertical extension on the SFA stack, I invite you to take a look at the AppExchange, which already has more non-SFA apps than SFA ones.

    - Kingsley Joseph
    • Finally, someone shed's some light!


      First of all I want to thank you for enlightening us with your comment and clarifying Dave's position. Unfortunately I must side against you and Dave in this matter. Although I couldn't agree more with you when you say:

      "?In the end Apex will empower our customers and developers more? "

      It's the last part of the sentence that I can't accept:

      "?Apex will empower our customers and developers [i]more than anything else we could have done.[/i]"

      You could have certainly done a better job when choosing your language and underlying implementation technology. I quote your requote: " why are we re-inventing the wheel?" and that is exactly what I keep asking my self: why are you re-inventing the wheel when you could have chosen Java or any other widely accepted language for developing apps for the AppExchange? And the answer to that can only be explained by Salesforce's goals.

      Unless I completely misunderstand everything you guys have been saying since the inception of AppExchange, the goal of AppExchange is to be an online platform for anybody to be able to write on demand applications.

      So now I take the position of a vendor wanting to write my application on AppExchange that is not dependent on the salesforce schema, why on earth would I want to go through the trouble of not only learning a new language but also writing my entire application in a language that is [b]ONLY[/b] supported by What happens if I'm unsatisfied with the service, or simply I grow enough to the point that I want to move my application to my own datacenter because it is more economically feasible in the long term? The answer is, I cannot do such a thing. We could never do this. We are eternally bound to (Unless, of course, as Dave mentioned, they provide a specification for Apex compatability) If instead of writing my application in Apex, I would write it in Java or any other widely accepted language that you could have chosen, aside from the inevitable tie in on data access which you would have to re-write you are home free to get up and go when ever you please without major problems.

      This is what SalesForce should have done, building the qualities of on-demand (like multi-tenent) into a stack coming from a standard implementation stack. Frankly the reason why I believe SalesForce didn't do it is because they are trying to retrofit their existing application into a platform instead of writing a platform from the grounds up.

      The bottom line is the lock-in era is over and that is the foundation of SaaS. I saw some pictures of SugarCRM discussing "vendor lock-in" so I don't think I'm by myself on this. Anyone that doesn't see it is waaay out on left field (alone).

      Either way, excellent discussion.


      Abraham Sultan
  • Great

    I was also in doubt about the Apex. This article helped me clearing some doubt. Thanks
  • Salesforce do lock you in

    I am a bit late to the party. But almost 4 years on from this article and with some salesforce experience under my belt I can say "once your signedup to salesforce - they bind you to them much tighter then other vendors!'

    Does salesforce offer an alternative route should you wish to mitigate that risk? You said yes because you can develop using the API instead of APEX. However time has now shown it has turned out this way as not all of the functionality in APEX is available in SOAP API so they force you to use their substandard APEX code.

    Additionally as Visualforce does not follow standard HTML and make you use their popiarty tags you views (web pages) are also tightly coupled to the vendor. Where as other web application technology's use regular HTML it is easy to reuse or use 3rd party tools to design you pages.

    If they used a standard language like Java or C# it would also make witting new application much easier as you could reuse existing code or even import an entire library. Using Apex you have to make EVERYTHING from scratch.

    Finn ally the biggest problem you you have using APEX is not that your locked into the vendor and they can screw you over at anytime. But the fact that the APEX language is has so many short coming and does not allow you to do half of what you want. The API is tiny and the limits places on function calls are ridiculously small making simple task near impossible.