Skip to content

Thoughts on Saleforce

A Salesforce.com community dedicated to making Salesforce, it's products, and partners better...

Click to register with Salesforce.com for a FREE 30-DAY TRIAL!

Sponsors

Login Form






Lost Password?
No account yet? Register
Home

Salesforce.com’s Dumbest Decision

I started this blog a while back now because I was dissatisfied with Saleforce.com in several material ways. I’ve blogged about a few of those ways but I have yet to blog about the main reason I was upset with Salesforce.com and why I started the blog in the first place; their not offering the Salesforce.com API or AJAX to users of Team or Professional Editions.  I’ve been waiting to write this to ensure that I would do the topic justice, but for reasons you’ll see in my next post, I can wait no longer to finally get this off my chest.

There are many other issues I have with Saleforce.com, but limiting their API to premium customers only is by far one of the most serious. I believe it is their dumbest decision, bar none. 

I knew from my prior experience as founder and president of Xtras that one of the best ways to improve the fortunes of a technology business is to cultivate add-on solutions for the business’ core offering(s). The existence of a broad swath of add-ons adds value to the core product (a.k.a. platform) and hence generates a lot more interest in the core product. Having a significant number of add-ons also adds greatly to a product’s market resiliency, especially if those add-ons are driven by actual market needs. Further, when there are many add-on developers with have a financial incentive in the core product maintain a large marketshare there is tremendous inertia generated for the core product from people outside the company. Those add-on vendors are essentially unpaid and uncommissioned sales reps for the company, and their marketing is in-effect marketing for the core product as well. You can’t get much better than that as Kevin Kelley wrote in New Rules for the New Economy when he said:

"Every time a closed system opens, it begins to interact more directly with other existing systems, and therefore acquires all the value of those systems."

And Salesforce.com knows this of they would never have created AppExchange.

But what Salesforce.com still doesn’t get is how limiting access to the API (in hopes to make an upsell) is only limiting Salesforce.com ability to grow its company’s value long term. I think it is probably a sales culture that has made them so short-sighted. They want to upcharge you for everything. They want to make sure there is never any money left on the table for an given customer. And that approach is just so incredibly short-sighted when you consider what is required to empower people to create add-ons.

Of course Salesforce.com and their apologists will argue "But the Developer Edition *is* free. Salesforce.com *do* recognize the value of empowering people" to which I just sadly shake my head and sigh. I know from significant experience that the best add-ons, the ones that truly meeting a market need are the ones developed by small scrappy companies that experience the need themselves. And small scrappy companies aren’t going to build add-ons with the Developer Edition if they can’t use those add-ons for their own business in their Team or Professional Edition accounts.

Large enterprises may create the add-ons but they have their own real business to run and won’t be bothered to bring their custom add-ons to market. Taht leaves the companies that develop add-ons for a business; they are essentially speculating on what the market needs and try to address those needs but they almost never have ongoing first hand experience as they only experience those needs vicariously through their customers.

And this is not an indictment of software companies; no, not at all. They are doing a great job offering the add-ons they offer. And the good ones have developed sales and support processes that are needed to serve their customers which is something the small scrappy companies I mention don’t start with. But this latter group, the software companies are rarely likely to identify a truly underserved need or innovative solution and then bring it to market simply because they don’t experience the need as a pain point on a daily basis like the small scrappy companies who have the need do.

But what differentiates the small scrappy company from the large enterprise is that the former often realizes that bringing their add-on to market would be a better business than they are currently running whereas that will never happen with the large enterprise. To paraphrase the name of a 1988 movie you might even call the former "The Accidental Add-on Vendor" as they don’t start building add-ons to sell them, they start building add-ons because they need them. Almost without exception, the market leading add-on vendors in my former business Xtras started developing add-ons because they needed them for their own business, not because they were trying to be add-on vendors and build software to sell to someone else.

And these small scrappy companies can’t afford Enterprise Edition so they are not going to use the Developer edition to create add-ons because they can’t use those add-ons they create for their own business. So the people in these small scrappy companies just do without, or do it elsewhere. Kevin Kelly also said in New Rules for the New Economy that you should "maximize the opportunities of others" which is something Salesforce.com just doesn’t do.

Empowering small scrappy companies to become accidental add-on vendors is the tremendous opportunity that Salesforce.com just fritters away because of their almost pathological need to upcharge for everything. And that’s the dumbest decision they have ever made.

UPDATE: Phil Wainewright of ZDNet talks about how AppExchange seems to be all hype and few success stories. Given the situation as I explained it above, is there any wonder at all in this?

Is SalesForce.com TRUSTWORTHY, Redux?

Peter Coffee, one of the two men (formerly) from the media I respect the most[1] just blogged about how code running on Apex "is safe" from prying eyes because you never install at a customers site. However, he then goes on to say:

The only third party that could possibly access the actual code — salesforce.com, for example — is the one with the greatest interest in helping to protect it, and thus protecting the reputation of the multi-tenant platform that supports it.

Well, as I blogged previous (but unfortunately have yet to have the time to follow up), I have serious concerns about Salesforce.com not always putting it’s interests ahead of its customers. Whereas a customer using a company’s code illegally might result in an opportunity lost cost, the overall cost to the company is rarely if ever business threatening[2]. On the other hand, if Saleforce.com decides that an AppExchange vendor is occupying a spot that Saleforce.com would like to occupy, Saleforce.com can put them out of business like that.

While I do trust Peter Coffee as I implied above, he doesn’t make the decisions at Salesforce.com, Marc Benioff does. And based on everything I’ve seen, I don’t trust the cabal led by Marc Benioff not to have situational ethics when a significant market benefit might potentially be gained.

But then, maybe that’s just me.

  1. The other person being Jon Udell
  2. If it is business threatening, then the business has much bigger problems that management should be more concerned about.

Why APEX, and why not Java, C#, VB.NET, PHP, Ruby, etc. etc.?

Stuck on the Apex?
Dog Precariously Perched on Apex
Photo by hangdog

I understand from Investor’s Business Daily via SalesforceWatch that Salesforce.com’s new secret sauce is a programming language called "Apex."  My question is, "Why create YAPL?" (Yet Another Programming Language)  Why not leverage one of the many excellent programming languages that already exist? 

Why create the need to learn a whole new language when they could have leveraged one that already exists?  After all, most of the functionality is in the class library; why not just create a class library for Java or C#/VB.NET or PHP or Ruby instead of an entire new language?  Or why not buy Delphi for god’s sake?!?

Naybe Saleforce.com is just trying to increase revenues by planning to charge for training and certification?!?  There goes me not trusting Salesforce.com’s motivations again. Or maybe it is just arrogance and/or delusions of grandeur on their part?

But bottom line this is a foolish strategy. Clearly Salesforce.com wants to see more apps developed for AppExchange but going this route means significant increasing the friction required. And as most of the successful Web 2.0 companies have show, the more you reduce friction, the most quickly you are able to harness collective intelligence.

Before I close, let me point out that I founded and then ran for over a decade an Inc 500-recognized company that sold components for Visual Basic and later to .NET developers. I understand programming languages and I can program in more languages than I have fingers (and I’ve got all ten, thank you very much.) I also understand third party markets like AppExchange extremely well as that’s exactly what I focused on; reselling third party components and tools to developers. So I think I have the authority to comment on this. This strategy of launching a new programming language, though they may eventually be able to tuff it out over the long term to make it look successful is, IMO, just plain dumb.

P.S. Even after bitching about this, I’ll probably still learn Apex. Assuming they don’t limit it to just Enterprise and Universal edition customers, DOH!