I found this post by Paresh Suthar in his weblog. I agree that Groove is bet used for more ephemeral work in process. I have found the tool most useful when there is an agreed upon deliverable and the project team comes together to work on it, until its done, then publishes the result.
Groove as a Conduit,
Yesterday I was part of a meeting with a company that has been developing enterprise scale Groove applications for a while. During the course of the meeting, one of them indicated what they see as the value proposition of Groove - "center to edge to center". That is, taking data from center based systems and putting it into Groove for collaboration, and when the collaboration is complete, taking the data from Groove and putting it back into a center based system.
As the meeting progress, they were asked about the average lifetime of Groove spaces that they were creating. Their response was that the lifetimes of the Groove spaces exceeded their usefulness - not exactly a direct answer to the question, but interesting none the less. They expanded to say that the actual period of collaboration could be measure in months/weeks, but the typical user did not delete the Groove space after collaboration activity waned/completed.
This comment reminded me again that some people are seeing Groove as a destination or a final storage mechanism. While this might be viable for non-enterprise situations/use, it typically will not be for enterprises. Enterprises have significant investments in server based systems, not to mention the people who manage them, and they want data to live there. Groove complements server based systems by providing a facility for collaboration - it does not compete with them. Perhaps another way of thinking about Groove is that it is a limited lifetime conduit between people and data, where the data is pulled in/pushed out of the conduit on demand.
