Microsoft has a large number of internal distribution lists for discussing specific topics (more like listservs than newsgroups). On the morning the plan to acquire Groove was announced, I saw questions from our sales force demanding to know what the exact implications would be for every product Microsoft makes. I told the guys in question that they, like we, will just have to wait a little while. When you propose to a mate, you can’t tell which extended family members will approve and which won’t. You certainly can’t predict exactly when you’ll have children, let alone their genders and personalities.
But I can say that if there’s any technology/product that shouldn’t be at all worried, it’s WSS/SPS. We’re actually pretty happy about this.
In the current release, not having the resources to create our own offline client, we opted to make our data accessible by smart clients. Outlook took advantage of this to some extent by being able to maintain-yet-keep-in-synch offline copies of calendars, contacts, and document attachments. Groove went all out with it, being able to read and write just about everything we keep inside of our sites. SInce they’re first-and-foremost peer-to-peer technology, they can in turn share out their offline copies of SharePoint site content with other Groove users on the extranet. For environments that don’t want to put a WSS farm in the DMZ and give extranet users AD accounts, this is a Good Thing.
What does this mean for developers? Well, the offer we implicitly made in 2003 still stands: we give you remotable APIs for creating your own smart clients with offline capabilities. You can (and in many cases should) still write those (I’d love to see someone create an Windows Explorer shell sync extension for SharePoint libraries). But your other option is to have your customer use Groove and just write Groove extensions to handle the lists/libraries you’ve customized for your application-focused sites. Actually, you could have done this before we started this acquisition, too.