Having a discussion with Mark Smith from Virtual Methods started by comments about what kind of groove tools will succeed.

Mark: Obviously I 100% disagree with your comments about whether Groove Tool Vendors will succeed. The major problems I've got (apart from price/quality issues) with our larger competitors is that they treat software development as almost a solo activity, carried out in an environment tighlty bound to a developer IDE. Your link to the Infoworld Booch interview shows that other firms are pushing in the Analyst<->Designer<->Developer direction, as borne out by their most recent product releases. My view is that the other direction-Customer<->Analyst<->Project Manager -is being neglected. I also know from direct personal experience that a Groove space provides a better way of specifying and designing software than the current hotch-potch of email, Word documents, scribbled notes, meeting minutes and so forth. Would you agree that the integration of requirements, design and project management can only make softeare projects less painful?

It seems we’re talking about two different issues – first being whether Groove tool vendors will succeed and the second being the vision and the target market of UMLTool. Obviously, its not my place to critique UMLTool and Mark's vision behind it. I sincerely wish Virtual Methods luck making it a hit! I’ve only used UMLTool as an example of a new application that knows collaboration in an established market of feature-rich tools that don’t know collaboration. Fair?
I think we’re in agreement that current software development tools simply lack collaboration feature set. Yes, software development is highly collaborative process that involves many different types of stakeholders as Mark points out. I would pay to have the better collaboration tools for software developers. But I would only pay if those tools don’t take away my other favorite features. In my work I use UML using Visio. I’ve selected this tool because it is feature rich, integrates with office, stable, gets the job done, blah blah blah. But this tool doesn’t know collaboration. So naturally, I turn to UMLTool. Will I end of switching from Visio to UMLTool? I will, only if UMLTool doesn’t take away all of my other favorite features present in Visio.
I believe this very logic will be used by majority of buyers of Groove Tools. If users find groove tools sub-standard in areas other than collaboration, I believe they will opt to use their current tools and simply end up using Groove for file sharing. Same logic will apply to Groove-created tools like calendar. What would Outlook user prefer while arranging a meeting with a partner: seeing their shared calendar directly in Outlook or switching to different UI of Groove, going in the shared calendar and trying to figure out the conflicts with his/hers personal Outlook calendar?
Would you agree that sub-standard tools that know collaboration are less valuable to the user than full-featured tools with added collaboration features?