Today’s news from the more SaaS-y part of cloud-land is that SalesForce.com’s platform, Force.com, now integrates with more of Google, in an even tighter way.
The Announcement
The ongoing idea here is to move all the on-premise, enterprise software up to “the cloud,” which here means the sort of “classic” idea of a SaaS, backed with middle-ware and programming as you’d expect in business applications. You know, “cloud as URL users go to,” not “cloud as a bunch of virtualized servers you deploy your stuff on.”
Put more succinctly:
Salesforce.com just released a Google Data client library for the Force.com platform, enabling access to the full suite of Google Data APIs using Apex code.
The demos we saw this morning were all very interesting, primarily because of their elegant simplicity:
- I need to schedule a sound system install in my SalesForce-based workflow system. Stuff cranks away, and the result is a scheduled item in Google Calendar.
- The accountants really like spreadsheets. We need to re-allocate some funding, so this little chunk of our SalesForce-based workflow system “shells out” to Google Sheets to let the accountants get their Excel warm-and-fuzies.
As was pointed out many times, while calls between SalesForce and Google were possible up-to-now, you had to do them on your own server. This announcement is all about SalesForce baking that integration to Google apps into the platform.
Threats
Really, this kind of ongoing thing is very impressive. With things like 1.5M users switching from Exchange/Outlook to Google Apps/GMail, seeing a workflow that crosses from SalesForce to Google Apps to schedule meetings, kick off email work-flows (though, we didn’t really see any of these that I recall), and otherwise tightly couple business workflows with Google Apps start looking like a very real, here-and-now threat to Microsoft’s Exchange and – maybe – SharePoint strong-holds.
Perhaps even Office, though it’s hard to think of people switching over to Google Docs and Sheets just yet. Buzzword & co. seems more realistic (Force.com/Acrobat.com integration?) if less big name.
Platform-as-a-Service, Lock-in FUD
As with Amazon, SalesForce has packaged up their general web application platform and productized the use of it in the form of Force.com. From the conversations I’ve had today, people still think of SalesForce as being strictly CRM – managing the process of getting leads and harvesting more cash out of existing customers.
Indeed, it’s not entirely clear why you’d use Force.com to build a sort of stand-alone application that didn’t have anything to do with SalesForce.com – as it is now and as it will become in “the next 10 years.”
In theory, you could build such stand-alone applications, using the existing Force.com platform for cloud-as-infrastructure. But then you’d face the number one thing that “makers” I’ve talked with today site: lock-in.
Lock-in is a common enough idea in the on-premise world. It means that you develop your software, relying on a technology that’s difficult, if impossible to transition from at a reasonable “cost.” The first form of lock-in, of course, is deciding what language you’re going to write in. More “normal” forms are relying on a vendor for the platform to run your software on, or in.
Force uses the Apex programming language and – unless I’m missing something – only runs on Force.com. Once you write your application, you’re “locked-in” to always having a relationship with SalesForce.
The question is: is this bad?
Obviously, the open camp would say yes. (Too status quo?) A more pragmatic camp would say yes on the condition that you’re building an application from the ground up.
On the other-hand, there’s an emerging place where it’s just dandy: when you’re selling features instead of whole applications.
(The ever-snarkier response to all these fears of lock-in is to ask if it’s possible, really, to have it any other way. We’ll leave that one as an exercise for the reader – remember to cite at least one example, or 2-3 if you’re feeling A+-y.)
Hedging
From what I’ve seen today, it looks like your best bet for developing on-top of Force.com isn’t in building full-blown applications, but either extending or augmenting the general types of business applications that exist in the SalesForce world. Plugins, features, extensions. Whatever you want to call them.
Don’t get me wrong here: we saw demos this morning, like Appirio’s, that seemed like full-fledged applications rather than just extensions. My architectural question is if this is, long term, a good idea.
There are at least two areas of risk for lock-in here: SalesForce raising their prices and/or another attractive platform coming along that you’d want to switch to, but will have to pay a high price in re-writing time to go to. See “the freedom to leave.”
If you’re going to develop your whole application on-top of Force.com – instead of just parts or providing “features”/mini-application – the key is realizing that you’ll be a Force.com developer. This is not necessarily bad in the same way that’s it not necessarily bad to be a “Microsoft developer” or an “Adobe developer.”
Open Source in World of aaSes
But why get all hung up on my open source 1.0 biases? The questions for SalesForce, here, are the same ones for the likes of Bungee Labs (who seem to be working on open sourcing) and even the last mile of closed source folks in Flash-land:
- Do the advantages of open source – cost, transparency, and community – apply, even work, to the application layer of cloud computing?
- Do the developers of cloud computing care about open source, or are they jolly to be “proprietary”?
To me, these questions get down to the scale of your application and the breadth of where you want to take it.
Honestly, I’m not sure how far you could push Force.com as a general platform – I need to check it out more. There wasn’t a whole lot of discussion about what Force.com doesn’t do, but there was plenty of bandying about of Gartner’s application server magic quadrant-ing, where Force.com showed up as most “visionary.” This, of course, suggests that SalesForce very much wants Force.com to be a generic application platform.
The point here is that the more breadth a platform seeks to have, the more I’d lean towards it being open source as advantageous. If you’re just adding in features or building on-top of the platform, classic open source questions seem to matter less.
So there is that weird open question about Force.com: are we really to take it as a general runtime for any application?
ISVs and/or Corporate Developers
There’s a whole other open question here as well. As I wrote in Twitter earlier today during the event:
Are Force.com developers ISVs or corporate developers? Writing software to sell, or software to use?
The ISV/corp developer split is one that people often over-look, but in platform plays like this one, it’s a key point to nail down.
Pretty much all of the talk was geared towards ISVs (those writing software to sell it, not use it internally). What with the concerns of lock-in being chiefly an ISV concern, though, it seems like Force.com corporate developers would be especially attractive: get the benefits of custom – and customized – applications along with the benefits of cloud-as-data-center.
Clearly, at this stage Force.com needs to attract ISV developers. I’m not sure, however, that they’re throwing the nets out for corporate developers as much as they could be.
Anybody Seen Open Source?
Stephen recently talked about Google as being an open source company, which is another fun pivot to look at this stuff on. For me, the nut is:
If it seems as if I’m downplaying the significance of the software here, that’s because I am. Because while software is always the foundation, it’s entirely possible that the value of the source code from a retail standpoint could be far less than the value of the data that it’s used to collect, as Nick Carr argues. If that bold assertion proves to be true, or even partly so, we may yet come to regard these periodic arguments over open source business models as quaint and archaic holdovers from legacy monetization strategies.
My take-away is one of those oh-so-clever nonsense phrases I like typing up: commodification itself has been commodified.
The Crazy Notion of Paying for Software
SalesForce’s pitch, demos, and all that are, of course, compelling. The web is compelling and anything built on-top of it looks like magic compared to on-premise software. The promise to developers, on-top of the technology, is that this is the kind of software you could make quick money off of (something SalesForce doesn’t quiet beat the drum on enough).
It’ll rattle plenty of open source people – I’m reading the comments in my head now – but that’s never been a huge strength of The Promise of Open Source: you’ve always gotta weasel out some way to make money, or just be happy with small amounts of money while you wait for The Big Buy Out.
And in this age of iPhone applications, it seems we’re slowly creeping back to a notion that a generation of developers – myself included – seem to have lost: you might have to pay for software, and maybe that’s OK. You might be able to even make a living off the novel concept of people paying you for the code you write. Pay you directly for the software itself even: not with ads, the VC funding-then-acquired-cash-out loop-hole, support/training/consulting, or nuthin’!
I know! Shocker!
Disclaimer: SalesForce paid my travel and expenses out to Tour de Force here. Adobe is a client, as is Microsoft.
It has always been hard to make a business out of open source, SaaS/PaaS just makes it a tiny bit harder.
Things will have to adapt, but there will always be a need for some on-premise software, even if it is on a phone 😉
However, in the Enterprise things take a long time – so there is time to adapt.
The question of how to earn money from software is always interesting. What I see with the likes of force.com is the formation of new software channels. Being locked in to one channel means putting your eggs in one basket.
Can force.com exist in its own right, outside the umbrella of salesforce.com. If not, will it get quashed?