SE Toolset and Methodologies
To be more precise: in open source projects, a set of tools and methodologies are used to develop software and manage the roadmap with teams distributed over the whole world, such as:
- Mailing lists
- (Sourcecode) Repositories
- Bug/Issue Tracking systems
Specialised Groupware Tools?
In many cases a good solution can be the installation of proven software-engineering related tools even in non-SE domains. Still, the problem persists, that different types of users with different skills want to work with these tools, and the integration between those applications is typically rather weak (particularly from the standpoint of a not so skilled user). So generally spoken, I see a significant "market" for integration software, that actually uses established repositories, content management systems, instant messaging protocols and so on, but helps to integrate those with unified user interfaces for different target audiences.
Additionally we still face the problem, that a good toolset has to be used! The hardest part in establishing a groupware strategy is not the installation of the tools, but the "refactoring" of the usual work-processes. I.e., bringing the users to actually using the new software appropriately.
Establishing Groupware = Software Installation?
Additionally various channels, now separated, can be used on similar channels. In our paper we suggest for example, a system, where resources are exchanged via instant messaging plugins, but are actually held in a reliable backend repository like Daisy or WebDAV or SVN. Another thought is, to bring IM and resource access and exchange technology into email clients. Then users could share documents in their "favorite style", namely using the mail client, but they would actually be exchanged e.g., via SVN and not via SMTP. The advantage is clear: the user has his or her familiar environment, but in the backend a more stable solution is established (versioning, access via various systems, e.g. content management...)
This strategy should reduce the gap for the user between his old environement and work-processes and new processes and tools. Later on, more advanced tools can still follow when required.
Any thought to this connection between SE practices and general collaboration? Particularly considering different audiences?