In part one of this series about online collaboration I wrote about several Do’s and Don’ts to keep in mind when using wikis as collaboration tools. I covered these key points:
Now we’ll take a look at three ways to help structure online collaboration in an enterprise environment. I found these principles in Steven Weber’s The Success of Open Source, which describes the open source software movement from its origins in the development of the UNIX operating system in the early 1980s. Weber offers several principles for collaboration. I find the following three to be especially relevant for large-scale organizations interested in using online collaboration tools:
These principles have become apparent as groups working on open-source projects have collaborated over the years. You will need to create policies, guidelines, and work practices to ensure adherence to these principles in your own documentation process.
In a truly open collaboration environment, contributors to a project choose what they want to work on. Volunteers can gravitate toward aspects of a project that interest them—this is one of the main reasons why so many people are willing to volunteer their time at all. On the other hand, they can also leave the project at any time, and that kind of freedom may not be practical in the workplace. But if you want to harness the power of your hive, you should look for ways to make the process of contributing as interesting as possible for your worker bees.
Weber describes this principle as “scratching an itch.” What he means is that developers often contribute to open source software projects because it helps them solve a tangible problem they have been dealing with.
Maybe it’s a hobbyist at home trying to build the ultimate personal video recorder, or maybe a programmer is looking for a dynamic way to display database contents for a project at work. In cases like these, the person may work on an open source project that helps solve a problem, and they are happy to share the solution with others. In a documentation setting, there may be people in your organization who repeatedly answer the same kinds of questions and would love to help document the answer for everyone.
Another way to put this is, “Talk a lot.” This is one of the keys to the success of the Linux operating system. Disputes take place in public. Anyone is welcome to weigh in on an issue. Discussion is not always calm. And the records of the discussions remain available for anyone to refer to.
In open source development, this can lead to bruised egos and can even contribute to software forks (where a group of developers leave their fellow contributors to take the software in a different direction). Again, in the enterprise environment, complete transparency may not be an option. But the more you can keep decisions and discussions open to the all of contributors to a project, the more those contributors will feel they have a voice and stake in the final product.
In the end, collaborative documentation in an enterprise environment may never be able to follow the same chaotic development model that has made truly open source projects so successful. In fact, much of the strength of Linux, Firefox, and other free software lies in the flexibility and openness of the GNU General Public License agreement, which allows anyone to take the material and reuse it for any purpose. (The main restriction is that derivative products must also be distributed under the same licensing agreement.) Clearly, this kind of free distribution may not be an option for all organizations.
However, to the extent that you can create a structure to help mimic the kind of emergent collaboration that has evolved around these open-source projects, you will be able to tap into the wisdom of the crowd in your organization.