Skip to main content

Fredrickson Communications

Josh Welsh

Josh Welsh has a variety of experiences writing and editing scientific and technical documentation, and he also works on usability and user interface design projects for Fortune 500 companies and the public sector. Before joining Fredrickson Communications, Josh worked as a technical writer and a public radio reporter, and he has taught English to German high school students.

Josh is finishing an MS degree in scientific and technical communication at the University of Minnesota. His research interests lie in the nature of asynchronous, “low-structure” online collaboration. In his research, he asks questions such as, “How do contributors to wikis and open-source software projects work together?” and “How does the changing relationship between author and audience affect the work of technical communicators?”

References
  • Social Learning Technologies Matrix(.pdf) – A concise guide to social learning technologies and their applications.
  • Weber, S. (2004). The Success of Open Source. Cambridge, MA: Harvard University Press.
  • The GNU General Public License agreement, or GPL, is most widely used open-source license agreement. It was created by Richard Stallman in 1989 to facilitate the sharing and development of open-source software.

Tapping into the Wisdom of the Crowd: Making it Work

by Josh Welsh, Usability Analyst

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:

  • You can’t expect large numbers of collaborators to solve everything.
  • You will need to provide structure for your collaborators.
  • Eighty percent of the work will be done by twenty percent of the contributors.

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:

  • Make it interesting.
  • Make it meaningful.
  • Make it transparent.

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.

Make it interesting

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.

Make it meaningful

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.

Make it transparent

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.

Conclusion

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.

This site occasionally provides links to websites operated by other parties. These links are provided for your convenience only. The presence of a link does not imply any endorsement of the material on the websites or any association with the website's operators. We do not operate, control, or endorse any information, products, or services provided by third parties through the Internet. We are not responsible for the content and performance of these sites. Use of linked sites is strictly at your own risk including any risks associated with destructive viruses.