Wikify Documentum already

“The companies that figure out how to harness the power of open platforms while providing adequate incentives to all stakeholders are poised to reap great rewards.” -from Wikinomics

A few months ago, I blogged about this thought-provoking book. Around the same time I began to promote the idea of taking aspects of our product documentation (e.g. development guides) and “wikifying” them. I contend that it’s better to replace the current delivery model (i.e. a PDF drop per release) with a new model that harnesses the power of the web and the energy of the Documentum community. Better for writer (uptake, feedback), better for all cross-functional product team members (accessibility, performance, quality, functionality, architecture, usability), better for the overall community (collaboration, connectedness).

The Django Book is an example application (user experience) of what I’d like very much to see become of the DFS Development Guide content—Wikibooks (e.g. this) is another example.

As you might expect our Technical Publications group leverages XML (DocBook to be more specific) as the underlying markup for its deliverable, which are released in PDF form. This is great news, since XML to wiki markup format transformations are fairly straightforward. By taking the underlying XML content and projecting it into a wiki–for example, off the EMC Developer Network (EDN) web site–rather than a PDF document can open up documents like the DFS Development Guide to our developer/admin/user community. By doing so, I believe that such documents can be revised, extended and planned more effectively. For example:

  • I find a gap I can fill. So, I simply create the missing wiki page(s)–I don’t have to wait until the next release of the software or the PDF document.
  • I find a gap I don’t know how to fill. So, I add a topic to the wiki’s “wish list” page, and someone else with the ability to author the missing content gains my respect and builds his or her reputation in the DFS community.
  • I can share how I took an existing code sample and tweaked or extended it to satisfy a new requirement.
  • I can talk about how DFS did or did not work with my existing IT environment–and expect more timely, specific/targeted response in return.
  • Etc.

Once the wiki exists, it can (and IMHO should) become the truth of its subject matter. In fact, PDF documents simply become the output of convenience (e.g. Atlassian’s Confluence wiki allows you to quickly rendition any wiki page as a PDF or, via a plugin, an entire wiki space as a single PDF document–links and all). Snapshots are just snapshots, and the current state of information is open for all to access and contribute.

To quote one of my colleagues: “The idea that we can control and perfect the quality of the information internally and shield it from possible inaccuracies introduced by customers is pretty flawed.”

When I talk with developers, partners and customers in the Documentum community to explain the idea of such wikis, the universal response is, to paraphrase, “sure…and yesterday would be great!” To trim it down to a single word: “Duh!”

So, to quote Jerry Maguire, “Help me help you” by posting a comment here, sending an email to the good folks at EDN and/or posting to the EDN forums, or call your main EMC point of contact to make your voice heard and your vote count. Thanks! :-)

Update 12/27/2007: Thanks to Anne Gentle’s link to my post, I found Wiki Patterns, which offers an open catalog of patterns and anti-patterns concerning people using and adoption of wikis (e.g. a WikiGnome versus a WikiTroll).