I have been working with a bunch of different groups on rolling out different projects. The issue of collaboration and communication is a constant issue. The common question comes up, how do I make sure everyone understands what is going on and reduce the time spent in making xyz work. We had an internal discussion about this yesterday and I was tasked with coming up with a collaboration strategy for my team.
If we start with information sharing, it typically starts with conversations between two or more people. When the group gets larger conversations become more and more difficult. This works well for small groups of 10 or less people. It is relatively easy even if the group is dispersed across multiple cities. Time zone issues can come into play if the distances are across multiple countries but this is typically not the problem.
Once everyone agrees on topics and action items, this information typically needs to be written down and shared. Email and text documents are the typical way of sharing this information. Things like shared files, network stores, or shared home directories are typically the answer.
The big problem comes up when you want contributors that are diverse, don’t know each other, and typically don’t get together for regular meetings. Something like this needs a web page, forum, discussion group, or wiki to maintain and share information. Blog servers can also be used but these are typically used for individual contributions and not group communications.
Historically, web pages have been used to share information in a publish and subscribe methodology. This is good for distributing information but is typically a push model. One or multiple people create content and others read this information. A newspaper is a primary example of this model. You have a group of writers that create news articles and a large community that read the information.
Recently, most newspapers have added the option of a discussion to supplement the articles. The discussion allows the readers to annotate or augment the articles. This is a good step because it involves more people in the creation of information and quality of the information presented. If, for example, a reporter states that something happened at 2pm but it really happened at 3pm, the readers can post a correction below the article.
The key drawback to this option is that you still have a handfull of content creators and not true collaboration. If you want a large number of people to create content, something must be in place to create structure and either allow or not allow joint editing of information. The key difficulty of web pages for this is that ownership of a web page comes down to file ownership. Having two people editing a web page can be a problem because the changes need to be merged or the file locked for editing by one person.
Blogs can be used to resolve this problem because each person can edit content and the information shared. The other problem with blogs is that it does not have structure. The structure of a blog is linear by time and not organized by subject. If multiple people talk about the same topic, they must link to each other and create a linked thread of the idea. Unfortunately, this does not allow for organization of ideas in a structured way, it is organized by date. A good discussion of this can be found here
A Wiki server, on the other hand is a hybrid of a blog server as well as web page. A user can edit the content of a web page on the wiki server similar to what is done on a web server but the wiki server manages web page editing through the web interface. A wiki server also allows you to create a structure based on products or ideas. If, for example, you want to talk about hardware, you create a page discussing hardware. If you want to talk about disk storage, you create a sub page that can be found under hardware. If you want to talk about operating systems, you create a parallel page to the hardware because it is not a sub topic of hardware. A good discussion of wiki structure vs web pages can be found here
Unfortunately, there are a large number of wiki servers. Oracle uses Wetpaint for the external wiki. Ward Cunningham has a relatively comprehensive list of wiki engines. Some of these engines use files on the back end. Others use a database as the information repository.
It looks like my next project is to get a wiki configured and enabled for internal only use to discuss specific industry verticals.