Comments on: Salesforce.com’s Apex: Benioff’s Handcuffs for On Demand http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/ Understanding the Software as a Service Revolution Tue, 16 Mar 2010 18:42:44 +0000 http://wordpress.org/?v=2.5 By: Harmpie http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-94985 Harmpie Tue, 28 Jul 2009 13:28:20 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-94985 In other words: a .NET application will never run without te appropriate MS licenses....unless you consider mono an option for your business critical software (cough) In other words: a .NET application will never run without te appropriate MS licenses….unless you consider mono an option for your business critical software (cough)

]]> By: Harmpie http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-94984 Harmpie Tue, 28 Jul 2009 13:26:27 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-94984 APEX & Visual Force (as the on-demand GUI has been implemented) applications DEFINITELY mean a lock-in in terms of the platform... but ... what is wrong with it?? The choice of any platform implicates a lock-in, whether you decide to use .NET, PHP, Java or whatever technology ... you will always lock yourself in. The fact you can swap your java machine, .NET machine or whatever infrastructure or another, does not mean you're not locked in to the technology. APEX & Visual Force (as the on-demand GUI has been implemented) applications DEFINITELY mean a lock-in in terms of the platform… but … what is wrong with it??

The choice of any platform implicates a lock-in, whether you decide to use .NET, PHP, Java or whatever technology … you will always lock yourself in. The fact you can swap your java machine, .NET machine or whatever infrastructure or another, does not mean you’re not locked in to the technology.

]]> By: SaaS Blogs - » According to ISVs, Salesforce’s Force.com is Not the Platform for SaaS http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-37203 SaaS Blogs - » According to ISVs, Salesforce’s Force.com is Not the Platform for SaaS Mon, 03 Mar 2008 10:59:27 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-37203 [...] If you’ve been a SaaSBlogs reader for a while, you’ll recall a post I wrote a while back addressing the problems with Salesforce’s approach to platforms via Force.com (or Apex, or whatever the marketing term of the day was). Now that Force.com is active and pursuing market share, many of the same things I mentioned hold true. What would cause only two hands to raise? That’s easy enough: [...] […] If you’ve been a SaaSBlogs reader for a while, you’ll recall a post I wrote a while back addressing the problems with Salesforce’s approach to platforms via Force.com (or Apex, or whatever the marketing term of the day was). Now that Force.com is active and pursuing market share, many of the same things I mentioned hold true. What would cause only two hands to raise? That’s easy enough: […]

]]> By: SaaS Blogs - » Is Salesforce.com’s Apex a Platform? http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-999 SaaS Blogs - » Is Salesforce.com’s Apex a Platform? Tue, 06 Feb 2007 06:52:38 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-999 [...] Sure it seems like a kind-hearted message with success written all over it, and it is undeniably unified in its presentation.  But now couple that mantra with the technological implementation that is Apex and here is where the meat of my questions arise.  According to their own Apex landing page, Salesforce.com wants you to create the next Salesforce.com using the ”same tools that salesforce.com’s own development team uses to build [their] own apps.”  Besides being a lot of Salesforce.com’s in one sentence, this seems like a cleverly veiled way of saying “we’ll let you build the next Salesforce.com, but no better.  And we’ll keep you from doing this by giving you only the tools that we give our own application developers… who you will ultimately be competing with.”  See, this way Salesforce.com’s own developers define a ceiling… a gaurded gate through which the ISVs they are ‘enabling’ cannot surpass them.  You see, you can’t really create the next Salesforce.com, you may be able to create what Salesforce.com is today.  Tomorrow Salesforce.com will have progressed, and then you can try to be that.  Sound fun?  Sound endless?  By bringing in developers through Apex, Salesforce.com is swallowing competition in an enterprise application space that it is certainly not giving up.  Is Apex simply a vehicle for making sure that Salesforce.com stays ahead of the game?  After all, if you outgrow or otherwise find little need for the tools provided to you by Salesforce, you’d pretty much have to dismantle your application and start over on a different technology stack - putting you far far behind.  Sounds kind of Borg-ish to me.  Come to think of it… didn’t we talk about the risks of this thing called lock-in before?  In the case of Apex we might be talking about lock-in through assimilation!  Heck, you even have to learn the Apex language.  I rest my case. [...] […] Sure it seems like a kind-hearted message with success written all over it, and it is undeniably unified in its presentation.  But now couple that mantra with the technological implementation that is Apex and here is where the meat of my questions arise.  According to their own Apex landing page, Salesforce.com wants you to create the next Salesforce.com using the ”same tools that salesforce.com’s own development team uses to build [their] own apps.”  Besides being a lot of Salesforce.com’s in one sentence, this seems like a cleverly veiled way of saying “we’ll let you build the next Salesforce.com, but no better.  And we’ll keep you from doing this by giving you only the tools that we give our own application developers… who you will ultimately be competing with.”  See, this way Salesforce.com’s own developers define a ceiling… a gaurded gate through which the ISVs they are ‘enabling’ cannot surpass them.  You see, you can’t really create the next Salesforce.com, you may be able to create what Salesforce.com is today.  Tomorrow Salesforce.com will have progressed, and then you can try to be that.  Sound fun?  Sound endless?  By bringing in developers through Apex, Salesforce.com is swallowing competition in an enterprise application space that it is certainly not giving up.  Is Apex simply a vehicle for making sure that Salesforce.com stays ahead of the game?  After all, if you outgrow or otherwise find little need for the tools provided to you by Salesforce, you’d pretty much have to dismantle your application and start over on a different technology stack - putting you far far behind.  Sounds kind of Borg-ish to me.  Come to think of it… didn’t we talk about the risks of this thing called lock-in before?  In the case of Apex we might be talking about lock-in through assimilation!  Heck, you even have to learn the Apex language.  I rest my case. […]

]]> By: Sinclair Schuller http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-764 Sinclair Schuller Tue, 23 Jan 2007 12:00:43 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-764 Hi Arun, Thanks for commenting. Currently, the only viable alternative is to piece together custom code with various SaaS components available by providers. The problem is, this still requires a lot of effort. However, it does avoid sub-layer lock-in (no new programming languages, stacks, etc.) since some of these components use industry standard sub-layers. http://www.saasshowplace.com/ has an enablement category with some examples. As an aside, the platform we are working on alleviates many of the issues discussed, so the best alternative is yet to come;-) Hi Arun,

Thanks for commenting. Currently, the only viable alternative is to piece together custom code with various SaaS components available by providers. The problem is, this still requires a lot of effort. However, it does avoid sub-layer lock-in (no new programming languages, stacks, etc.) since some of these components use industry standard sub-layers. http://www.saasshowplace.com/ has an enablement category with some examples.

As an aside, the platform we are working on alleviates many of the issues discussed, so the best alternative is yet to come;-)

]]> By: Arun PC http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-746 Arun PC Mon, 22 Jan 2007 07:53:03 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-746 We know that the lockin is bad for everyone(of course not the owner of the platform) and we also know that we dont need a YAPL. Is there any other platform which doesnt pose this threat? Are there atleast lesser evils? Thanks, Arun.PC We know that the lockin is bad for everyone(of course not the owner of the platform) and we also know that we dont need a YAPL. Is there any other platform which doesnt pose this threat? Are there atleast lesser evils?

Thanks,
Arun.PC

]]> By: SaaS Blogs » Blog Archive » SaaSBlogs.com: Most Popular Articles of 2006 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-490 SaaS Blogs » Blog Archive » SaaSBlogs.com: Most Popular Articles of 2006 Thu, 04 Jan 2007 18:57:10 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-490 [...] Salesforce.com’s Apex: Benioff’s Handcuffs for On Demand [...] […] Salesforce.com’s Apex: Benioff’s Handcuffs for On Demand […]

]]> By: SaaS Blogs - » Marc Benioff, Please Stop Confusing Me http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-39 SaaS Blogs - » Marc Benioff, Please Stop Confusing Me Wed, 15 Nov 2006 23:08:18 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-39 [...] Salesforce.com has definitely reached powerhouse status, and is one of the main proponents of SaaS. For this, I thank them and really see them as a driving force. That aside, what is going on in Marc Benioff’s head? I wrote an article a while back about Salesforce.com using Apex as a lock-in strategy, which spilled over into a ZDNet blog article, and was vehemently opposed by Salesforce.com employees in both articles comments, with arguments ranging from there is no lock-in to there is no way around lock-in and expecting application portability is unreasonable. [...] […] Salesforce.com has definitely reached powerhouse status, and is one of the main proponents of SaaS. For this, I thank them and really see them as a driving force. That aside, what is going on in Marc Benioff’s head? I wrote an article a while back about Salesforce.com using Apex as a lock-in strategy, which spilled over into a ZDNet blog article, and was vehemently opposed by Salesforce.com employees in both articles comments, with arguments ranging from there is no lock-in to there is no way around lock-in and expecting application portability is unreasonable. […]

]]> By: SaaS Blogs - » Vendor Lock-in: Not new. Not gone, no matter what they say. http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-25 SaaS Blogs - » Vendor Lock-in: Not new. Not gone, no matter what they say. Thu, 26 Oct 2006 20:32:00 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-25 [...] We’ve had our fair share of vendor lock-in (handcuff) discussions on this blog.  [...] […] We’ve had our fair share of vendor lock-in (handcuff) discussions on this blog.  […]

]]> By: Tim Anderson’s ITWriting - Tech writing blog » Salesforce.com, Apex and Web 2.0 vendor lock-in http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-23 Tim Anderson’s ITWriting - Tech writing blog » Salesforce.com, Apex and Web 2.0 vendor lock-in Mon, 16 Oct 2006 12:09:53 +0000 http://www.saasblogs.com/2006/10/10/salesforcecoms-apex-benioffs-handcuffs-for-on-demand/#comment-23 [...] Salesforce.com, Apex and Web 2.0 vendor lock-in By Tim There’s a debate under way about whether the new Apex language from Salesforce.com represents a vendor lock-in. Sinclair Schuller says it does; David Berlind says mostly not. Berlind argues that the lock-in is mitigated since you are not forced to use Apex, but can use the same functionality via SOAP web services. I recently wrote a comment on the same topic for IT Week. [...] […] Salesforce.com, Apex and Web 2.0 vendor lock-in By Tim There’s a debate under way about whether the new Apex language from Salesforce.com represents a vendor lock-in. Sinclair Schuller says it does; David Berlind says mostly not. Berlind argues that the lock-in is mitigated since you are not forced to use Apex, but can use the same functionality via SOAP web services. I recently wrote a comment on the same topic for IT Week. […]

]]>