Commandeering Applications by Replicating APIs
One of the items Jesse directed my attention toward was the recent implementations of the Twitter API by three different sites: WordPress.com (the host of this blog), Tumblr (another popular blog hosting service), and identi.ca (a prominent Twitter alternative which has supported the Twitter API since 2008). By providing 100% API compatibility with Twitter, people can use any application built for Twitter with these other services (as long as the app allows you to modify the service URI/endpoint it uses). Because services survive or wither based on use, supporting a popular and relevant API can instantly yield a slew of applications to support users better. As a result of their work, WordPress.com has gained applications like the iPhone application Tweetie. Although many of the applications for Twitter currently do not allow you to modify the API endpoint (Tweetdeck, for example), most developers want more users, and API-level compatibility makes it short work for developers to support your service. I suspect that soon, nearly all applications created for Twitter will let you modify or add to the default API endpoint.
This got me to thinking about GroupWise, Novell’s strong alternative to Microsoft Exchange.
Novell: Align with Google for Developers
Novell GroupWise has a complete web API, and has for quite some time. Unfortunately, Novell seems to neglect developers these days–especially in their legacy products (as evidenced by GroupWise having only a SOAP API). Aside from their list of close partners, few developers use the GroupWise API.
Meanwhile, with Google’s enormous cachet with developers, numerous applications support Google’s collaboration-related APIs (such as Contacts). Perhaps even more importantly, developers can easily integrate Google’s API into new and existing apps through the numerous source code libraries available for Google’s various API’s (again, see Contacts, this time for the list of libs). Google’s Atom-based REST API’s are popular, well-understood, and widely used.
Consequently, Novell has an opportunity to serve their dwindling fan base better: replicate the Google API’s that are most relevant to GroupWise. Make it so that developers can easily adapt their apps to serve GroupWise, and so that end users can select from a wider assortment of 3rd party apps. This would give nothing over to Google that they don’t already have. It can only increase the relevance and extend the life of Novell’s venerable old product.
It also makes it possible for Novell to get on board with the biggest technology trend of the latter half of the last decade…
GroupWise in the Cloud
Since my time at Bungee Labs, I have been considering how Novell could offer GroupWise as a hosted SaaS offering as a way of acquiring aspiring new companies. As Salesforce has shown well, small is beautiful, and there is big business in the “No Software” proposition. This is where GroupWise competes (entirely ineffectively) with Gmail (“Google Mail,” actually) and its related collaboration components. It’s very easy to set up a Gmail account that uses your own company’s mail@domain. You can’t do that with GroupWise today.
But GroupWise does have something that Google lacks: a rich client. With all the apps that Google enjoys, none do a complete enough job of unifying all the typical collaboration features of an enterprise collaboration suite. With legacy collaboration being such an unsexy subject in the age of the social web, it seems unlikely that Google will re-solve some of these relatively mundane features. Finally, although there is a de facto rule about “everything through the web,” that does not mean “everything in the browser.” GroupWise has browser-based access, but it also has a full client that works online as well as offline, giving Novell a complete end-to-end advantage.
So put it all together–SaaS + Google API compatibility–and Novell has a viable technical path for GroupWise. All that remains is to figure out a freemium model that can viably compete with Google. (This is where I clock out.)
Note I realize that it’s kind of cheap to sit back and throw out directives for how some other company should manage its API strategy while sparing any mention of the company over which I may have actual influence. Some of the above thinking applies to our planning at Mozy. However, we do not offer a public API (yet), so it’s a challenge to directly discuss this subject without getting mired in caveats and cautionary or indefinite statements. If you have any more than a casual interest in where Mozy is heading with our API, please contact me by commenting on this post.