Dave Winer says

...it would be more convincing if Groove were open to competition, or at least open to being built on. When they came out with web services interfaces, finally, after years of waiting, the excitement was dampened because it didn't work with the programming environment I use. Maybe they are open to be extended, but, practically are there any extensions from people who are not working at or closely with Groove?

"Open to being built on". Groove has had an in-process development model (ie. build on the product, with code running in the framework's own process) from day one. Starting in 2000, my team at Agora built a set of tools, using our favourite kit: JavaScript, Visual Basic, XML and SVG.

To work with the Groove application from "outside" - a non-Groove.EXE process - use the GWS web services interfaces. I'm mystified by Dave's comment about "it didn't work with the programming environment I use": the wire protocol is SOAP. OK, so your programming environment can't use the "doc-literal" SOAP format natively? Why not fix that? Tim has done it. I've used GWS from Visual Basic, JavaScript, C#, perl and PHP.

SOAP-based access to "local system services" - collaborative services based on your desktop, in our case - really is a huge deal. Of course we're working with Microsoft kit more than anything else - as I hinted earlier, their development environment support for building web services clients really is exceptional - you hardly need to know that you're calling remote services, let alone the mechanics of how the message gets dispatched from A to B. That ease-of-access will be very important in the future, I think.

And, for an example from someone not working "at or closely with" Groove - how about Zhou's screenshot (in OS-X, in Shanghai)?

C'mon.

update: Jeff points out the screenshot isn't OS X, just a nice skin! Confused me, anyway.