Wednesday, September 04, 2002

Thanks to Jeroen Bekkers for encouraging me to switch to radio. The tool is very flexible. Switching could be made simpler though - couple of hours if you don't find the homepage template you like. I'll keep blogger-radio bridge running for a while. My first feature requests: Allow automatic import of the content from a different blog and post it with the right dates (in the past). Pure Windows client for posting that would use MS Word for text entry (a-la Outlook)      Just about every blog I’ve checked this morning had a link to Ozzie’s reply to Joel’s article on Platforms. The fact that a lot of people expected a public reply from Groove/Ozzie tells a lot about how blogs have changed high-tech PR game. Can’t wait for other software executives to catch up! In my opinion Ray Ozzie did a wonderful job explaining Groove’s strategy. The bit I especially like is the appearance of previously unpublished info on Groove OEM Kit. The existence of such kit confirms that Groove does recognizes the demand for Groove runtime and is working towards making it generally available. This is good news. But notice have Ozzie skillfully blends two things together. He calls Groove Workspace an application, but it is a platform too. Yet, there’s “Groove Platform OEM Edition” as well, but its not yet generally available. Let’s see if I can get it straight. First of all, there’s Groove Platform. 3rd parties can develop applications on it using OEM Kit. Then, there’s Groove Workspace. It is an application that runs on top of Groove Platform, but also allows 3rd parties to extend it by writing Groove Workspace Tools. The best analogy I can find is Windows and Office. Windows is a platform. Office is a Windows application, but you can also extend it by writing Office plug-ins and marcos. Ok, this sounds very very reasonable and healthy. So what’s wrong with Groove’s picture? The priority. Clearly, Groove has made a conscious decision to invest much more in support for developers of Groove Workspace Tools while providing a bare minimum support for Groove Platform developers. Imagine if 95% of MSDN was allocated for information on how to develop Office plug-ins and 5% was given to help out Windows application developers. And you had to "negotiate" with Microsoft to get that 5%! From the architectural perspective, there’s a risk that some of the critical functionality would creep into Groove Workspace from Groove Platform. Don’t get me wrong, I’m convinced that Groove’s architects are very smart and experienced people, but its really tough to build a nice generic platform when you have one single application that tests it. I think Groove has made a strategic mistake, but its not too late to correct it. Groove needs to increase the priority of getting Groove OEM Kit into general availability. They also need to start encouraging people to develop on Groove Platform just like they encourage to develop on top of Groove Workspace. So far Groove have done a really good job listening to developers, so if enough people complain, I believe they will find the way to solve the problem.      It's about time Groove has got some competition! Matthew French reports on CADwire.net on Availl From the first glance, it looks like Availl has solved pretty much the same problems that Groove runtime solves (security, firewall traversal, online/offline handling). In contrast with Groove Availl seems to be only focusing on selling the 'briefcase' solution - file sharing and synchronization. Compared to Groove, Availl's file sharing product looks extremely simple to setup and way more transparent - no shared spaces, no UI.      Joel Spolsky has some harsh criticism for Groove strategy. While I disagree with most points expressed in the article, I think the core message is consistent with the one expressed by me here and Philip King on Groove developer's forums. If this sounds odd, read on. When talking about multi-layer product such as Groove, one should define the terms to avoid confusion. So first, a quick terminology intro. "Groove Runtime" defines a UI-less piece of code that offers such services like secure communication, firewall traversal, persistence model that allows efficient broadcast of data set changes, handling of online/offline contexts, etc. "Groove Transceiver" is an application that uses Groove Runtime to offer the UI for such features as shared space management, user management, instant messaging etc. "Groove Tools" are hosted inside the Transceiver and allow the user to perform a specific function inside Groove Transceiver. Joel claims that Groove Inc. is making it hard to build applications (Tools) on Groove. I think this statement simply cannot be further from the truth. Clearly, Joel have never tried to create a Groove Tool with VS.NET Toolkit. For a young startup it is truly impressive to see how much effort was put to simply the creation of Groove tools. Joel also claims that Groove Inc. doesn't know that Groove is a platform. I wonder why is there a developer's zone on Groove's site? Again, this argument doesn't stand basic analysis. So do I think Joel's article is wrong? No, it simply fails to capture the real issue with Groove - there are two different views of "Groove Platform". One is being offered by Groove Inc. and another is wanted by ISVs. Groove Inc. defines the platform as Runtime plus Transceiver. Want to build on the Groove Platform - write a Groove Tool. Most ISVs define the platform as Runtime. Period. Most of the people thinking of integrating Groove's collaboration capabilities only want the Runtime. This is why Joel's analysis of cost/benefit of integrating Groove with CityDesk is right on the money - it illustrates the Groove/ISV gap. In Groove's defense, they do claim that the Runtime can in fact be used by ISVs in their applications (whoever there seem to be technical issues with this model in the current release). But still, the primary positioning of the platform is Runtime+Tranciever. So, its not that Groove thinks they don't have a platform (or they're clueless) - its just that their priorities are out of sync with those of their partners. This strategy flaw can be corrected. And if enough people complain, I believe it will.

Site Statistics

© Copyright 2003 Alexis Smirnov. Last update: 5/6/2003; 5:41:14 PM.