Salesforce.com’s Apex: Benioff’s Handcuffs for On Demand
When I first read of the Apex rumor, (Salesforce.com’s new “on demand programming language and platform”) over at Salesforcewatch.com, I started monitoring some of the various blogs and sites I regularly read for related news. I was hoping to find some tidbits of information that aren’t part of Salesforce.com’s marketing spiel. After Salesforce’s official Apex announcement, I found an excellent article that Dan Farber wrote about his discussion on Apex with Salesforce.com co-founder Parker Harris.
Harris discussed Apex in various contexts, defining it as a language with syntax that is a hybrid of SQL-esque style statements mixed with Java, and that the learning curve should not be a problem, allowing developers to quickly build on-demand applications. 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…
Apex, based on the description, seems like an evolution of SAP’s ABAP Objects (Advanced Business Application Programming Objects) language and NetWeaver, only evolved for on-demand and some quasi-OOP platform. While I appreciate Apex’s resemblance to Java, its still proprietary, just like ABAP and NetWeaver. While SAP touted ABAP as the end-all app development language and NetWeaver as the premiere platform for building business applications, we know full well that your general purpose technologies and languages as a whole have trumped things like NetWeaver time and time again. Granted, NetWeaver lets you use Java through some tight “hooks” to NetWeaver if you don’t want to ABAP, but your still “hooked.” NetWeaver and ABAP are not “mainstream” (how often do you see Digg/Slashdot/Red Herring articles on powerful applications or companies built on NetWeaver?). Apex presents the same proposition as NetWeaver: build your applications using Salesforce.com’s proprietary stack and you get to NOT have the flexibility of easily moving from Salesforce.com to another platform, of NOT being able to use for-sale and open source libraries in your applications, and having the pleasure of existing within Apex’s limitations. We’re in a day in age where we do not need YAPL (Yet Another Proprietary Language) or YAPP (Yet Another Proprietary Platform). I can’t imagine that Apex will be well accepted by the mainstream because of its lack of openness, flexibility, and overall stink-of-Salesforce aroma that surrounds its essence.
This makes me question Salesforce.com’s motivation. Why not embrace the many, many (and maybe one more ‘many’) well built technologies as the core implementation proposition to your vendors? Why provide something that is proprietary and less powerful, all while reinventing the wheel; according to Harris, they haven’t quite figured out debugging yet and have yet to come up with a way for vendors to build a UI because they “…need to build a pretty radical UI layer “. Excellent, I can’t wait for Apex UI Super Duper Extreme, the language for “on demand UI development”. My take on it: (1) Marc Benioff wants to keep the vendor close by making it expensive to build on and strategically unfeasible to leave the Apex platform and (2) they already have plenty of time and money invested on their own internal platform, which wasn’t originally designed for public use, and have retrofitted it to be a general purpose platform. Number (2) is very reasonable and any company would have done the same. We don’t need a specialized stack for on-demand. The power of on-demand and SaaS as a distribution model can be realized with the knowledge and technologies we have. The notion that a specialized “language” knock-off is needed to facilitate on-demand is absurd. The full power of on-demand can be provided without it, through a platform that embraces current technology.
*Gasp* Imagine if you could write an application using your existing knowledge set and a well accepted technology stack and still deliver it through a platform, on demand with oodles of multi-tenancy, single instance, high availability fun?! Nah, that could never happen…well, at least not until someone steps up to the plate…
Update: As per Mr. Joseph’s comment, I have removed the following sentence from the post:
I doubt a big Apex movement will be started on Sourceforge, seeing as how becoming a Salesforce partner developer costs more than an XBox 360
Mr. Kingsley pointed out that there is no fee for being a developer. After some research at some other sources, it is only for “certifying” the application that a vendor is required to pay a $10,000 fee.
Loading ...
You’re confusing an option for a constraint. 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. New features, like outbound messaging, where an event inside Salesforce can trigger an external web servicec, where built almost exclusively for developers who want to do this.
However, there are a number of developers who don’t want to do that. 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.
To correct some of the other misinformation in your post: It costs nothing to become a Salesforce.com developer. The developer edition is free. Listing the app you develop on the AppExchange directory is free.