If you’re thinking about an enterprise wiki, you’ve probably heard the success stories. One noteworthy example is the manufacturer whose wiki helped it fast-track ISO certification. Unfortunately, wiki adoption seems anecdotal while low participation and lack of management buy-in feel like the norm.
People who have managed a wiki probably know Stewart Mader’s Wikipatterns. Starting as a wiki, Mader later developed it into a book. While Mader makes several good points on grassroots adoption and how to run a pilot, we have reason to be skeptical of his points on collaboration and community. His wiki, it’s worth noting, is no longer online.
According to Wikipedia, “the 1% rule is a rule of thumb on participation in an Internet community.” When applied to a wiki, 90% only view content, 9% edit, and 1% actively create. To improve participation rates, wiki supporters recommend changing the organizational culture, claiming that hierarchy is a barrier to active participation. User experience experts see complex software as the problem and recommend simplifying the user interface.
Even supporters resign themselves to participation inequality. Others set low expectations and credit poor adoption to “wikiphobia.” They say that you might win over some resistance with perfect execution, but you are fighting human nature if you strive for significantly higher numbers. Fighting human nature? Phobias? Are users the problem with wikis? With champions like these, no wonder it’s hard to find the will to invest the time and effort!
Do online communities have a fundamental usability problem? Satisfaction with enterprise collaboration and social software remains middling. Perhaps it’s time to drop the heavy-handed use of the word “community” when talking about online collaboration. Rather than hoping everyone is going to love crowdsourcing, we should be focusing our efforts on the usability issues that prevent most from simply collaborating.
GitHub has introduced an alternative to the linear version history we get with the typical wiki. While intended for software developers, it’s easy to imagine putting its branch and merge functionality to use more generally. The roles of maintainer, committer, and contributor all seem familiar. There is no need to overcome resistance to collaborative editing or awkwardly impose a foreign authorship model.
From a wiki view, GitHub looks like an anti-pattern. Wiki supporters recommend avoiding Page Ownership and Contributor for Hire. We think it’s high time that we put these assumptions to the test. We intend to bring the same many-to-many authorship model you see on GitHub to the wiki.
Is it still a wiki if it doesn’t stress community over authorship? That’s why we’ve dubbed it the unwiki wiki, formal collaboration for informal learning. Visit Manysource.com for a peek at what we hope will be a novel approach to knowledge management.
This material is based upon work supported by the National Science Foundation (NSF) under Grant No. IIP-1416066. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of NSF.