Anne Truitt Zelenka

I was intrigued to hear about Salesforce.com’s announcement of Apex, their “on-demand multi-tenant Java-like” programming language that allows for arbitrary customization of the Salesforce.com customer relationship management product. To me, the most exciting thing about Web 2.0/Office 2.0/Enterprise 2.0 (or * 2.0 pronounced “star 2.0″ as Coté calls them) is the do-it-yourself web. There are a bunch of web-based app development environments including Ning, Dabble DB, Zoho Creator, and the soon-to-be-launched Coghead that could eventually make IT obsolete. Okay, that’s decades off, but isn’t it an exciting thought? Why shouldn’t users be able to build their own apps, just the way they want them?

What I don’t get is why Salesforce.com chose to create a strongly typed, compiled language. Okay, I do get it, because they hint at their reasoning in their introduction to Apex presentation. They want Apex to be safe. It’s a multi-tenant implementation, after all. But hey, the fact that their database and implementation is multi-tenant should be transparent to the end users. If my company runs Salesforce, so what if the company next door does too?

Where it matters is for application developers offering their own apps on AppExchange. Salesforce.com is not going after the do-it-yourself web with Apex. It’s creating an infrastructure and application market aimed at software developers. Those developers want to offer their apps to as many customers as possible, hence the need to market Apex’s multi-tenant design.

Still, I think Salesforce chose safety over velocity. Java’s not dead by any means, but it’s not any way to go about attracting developers and attention to your service. They should have provided a dynamic scripting language instead and called it “Ruby-like” not “Java-like.” They still could have put on restrictions to support multi-tenant databases and runtime engines. And they could have gotten in on the Ruby buzz even without actually offering Ruby support.

If you want to hear about an actual Salesforce.com implementation, check in with the Office 2.0 Podcast Jam on Thursday. I’ll be publishing a podcast interview with Judi Sohn, Director of Operations and Communications for the Colorectal Cancer Coalition. Judi manages information technology for C3 and spearheaded C3’s implementation and customization of Salesforce.com. She has real insight into Salesforce.com’s announcement of Apex, suggesting that 37signals (”we know the best interface for you”) versus Salesforce.com (”you decide what UI works for you”) might make for a great SaaS provider cage match.