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.
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.
<< Home