Collaborative authoring – tools and costs

I’ve been working on some collaborative authoring scenarios for our Agile teams – we’re going from 5 people to 47 people in total who could author external or internal documentation within our two week sprints. Turns out, we likely represent some trends in the enterprise – Forrester just released a report about benchmarking your collaboration strategy.  A quote from the abstract does describe our need to broaden our collaboration to more and more people.

A companywide collaboration strategy was once a nice-to-have. No more. Even in the current economic climate, 37% of organizations surveyed in Forrester’s Q4 2008 enterprise and SMB software survey consider implementing a collaboration strategy important in 2009. Two broad trends are driving this: 1) There’s a critical need to drive information worker efficiency and to manage the unstructured content artifacts they produce; and 2) while the value of improved collaboration is clear, the path to success has become more complex.

Also, I’m finding that we have broader considerations than just the technical publications department for serving up the best content for customers. While researching some solutions, I discovered that most enterprise-level solutions would require a jump from four-figure annual costs (less than 10,000 USD) to five-figure annual costs (greater than 10,000 USD). Or, to go from four-figure costs to four-figure costs while still meeting the author requirements may require an open software solution.

I’m blogging about it because it seemed like an interesting phenomenon. I don’t usually like to write about tools, because I don’t want to seem like I’m endorsing a vendor. And I’m not endorsing any vendors, especially with the new FTC guidelines. But I thought by sharing this on the Internet, I might get some clarity on whether there is a true trend in the field of technical communication towards collaborative authoring environments, and perhaps discover what are the collective forces that are pushing us towards collaborative authoring.

First, some requirements for the system we need.

Consumer requirements

  • Must get a known version of the docs that were delivered with a particular software release
  • Must output printed books – PDF is fine, previously we used Word .doc files delivered in electronic format however
  • Must enable draft content to be available internally for review every week (even though we are on two-week sprints, three of six teams are on alternating sprints so once-a-week publishing, really once a day or on demand publishing would be required)
  • Many other items like syndicated content, comments, ratings, web analytics, but these are not “must haves”

Author requirements

  • Must fit into budget constraints (this amount is four figures currently)
  • Must meet the existing server and client system requirements (Windows-based, with a SQL Server installation available)
  • Must be supportable by three tiers: author community of practice, then the members of Agile teams, and then the corporate IT team
  • Must enable two authors per Agile team minimally (12-14), ideally allowing all 47 members of production teams to create content
  • Must enable concurrent use by authors in two different versions of the product

Possible collaborative authoring solutions

This list is not comprehensive, and I’m sure people would like to jump in with suggestions – feel free to do so. Remember that I’m in the “less than 50 users” category, and that the goal is company-generated user assistance articles, not community-generated articles. Authoring happens behind the firewall, but the content should be freely available once “published.”

Five figures:

Author-it Live: $30,000 (although their website is currently saying there are pricing discounts which make it about $15,000)

Sharepoint 2007 server: $40,000

Author-it to Sharepoint plugin: $25,000

Alfresco (compare to Sharepoint): $20,000 (blog entries hint at the cost)

Four figures:

Confluence: $2200 for 100 users or $800 for 25 users, annual cost (migration could be free depending on what tool you use to migrate content)

MediaWiki: free (migration would require WebWorks ePublisher)

WebWorks ePublisher: Server version $2000/year

Drupal: free (migration could be free depending on the method)


Migration is completely possible, when given the time to do it. We have over 4,000 HTML files on our helpsite currently. Interestingly, DITA could play into the migration scheme because it offers a universal “translation” like a Rosetta Stone, giving content some fluidity.

1. DITA2Wiki

This is an open source project that takes DITA output and transforms
it to Confluence Wiki, and it could be automated with builds. Download
it from

2. WebWorks ePublisher

This is a proprietary software tool that has an annual cost, available at I have a free version that I am using and it works, with lots of customization work in the designer we could get nice output, but at a cost. The Express version is $300 a year, but it would not give us the customizations on output that we would need. The Pro version is $800/year, giving us design, but not ongoing builds with the tool. The Server version is $2000/year which gives you designer plus a command line interface that could automatically build wiki output every time the product is built. WebWorks outputs to MediaWiki, Confluence, and MoinMoin. I have only tested output to Confluence, which works great.

3. Confluence DocImporter

This tool, Doc Import, is built into the Confluence wiki itself and offers a manual web-form-based import of Word documents. The pilot work I did worked really well. After we worked on a sidebar table of contents, however, no additional Word docs can be imported due to some setting where it won’t override existing pages. I would do more work on this method because the results are at first glance even better than those from WebWorks ePublisher. But, this method does not offer automation (unless we find an API that automates using  DocImporter).

4. Drupal’s HTML Import

This method is as-yet untried for our content, but the idea is that we could take our existing HTML output, which is pretty well-structured, and use the Drupal Import HTML module on the entire site, a section at a time. I think this method would work, although it is more than a bit labor intensive for over 4,000 HTML files and all the links and images involved.

Topic-oriented, web content

There are two other options that come to mind when mentioning collaborative authoring. They are at $390/year and Google Docs, with no price. But those options do not offer a topic-oriented content management system that you could use to output web content – instead you get bundles of PDFs or Word documents. I’m not sure either of those are viable for our requirements. But maybe I need to be thinking outside of the box?

What are some of your favorite collaborative authoring tools, and why?


  • December 1, 2009 - 11:26 am | Permalink

    While Drupal is “free”, it’s also a mix of potent and complicated, therefore you very likely need a PHP programmer at hand for the customizing. I’m working on a large Drupal-based Intranet solution and have first-hand experience with it and trust me – it’s not easy and out of the box like e.g. WordPress 🙂

  • December 1, 2009 - 11:33 am | Permalink

    you forget booki
    cost : 0

  • December 1, 2009 - 11:46 am | Permalink

    @Birgit I agree completely about Drupal! We’ve also got the additional complication of a 4.7 installation that we need to migrate to 6.x. Ouch.

    @adam Hurrah for Booki! Here’s a link to the description of it.

  • December 1, 2009 - 12:07 pm | Permalink

    Collaborative authoring is great. But how about publishing it? In many cases it might be enough to have the content in a wiki, but in many cases it is required to re-publish it to paper, pdf, win help, etc.


    PS: I might be a little bit biased here as I develop the Scroll Wiki Exporter, which is a Single Source Publishing solution for Confluence.

  • December 1, 2009 - 1:38 pm | Permalink

    Thanks for the nice summary, Anne. It gives us a lot to think about as we move into more collaborative environments. I know that Just Systems has a number of pieces that can provide an environment to help you collaborate (including a fairly nice Reviewer) but the final assembly and production are always the big hurdle, aren’t they?

    It’ll be interesting to see what other solutions you dig into and what else you come up with.

  • Pingback: Alan Porter’s Weblog » Going Agile with ePublisher? – Let’s chat.

  • December 2, 2009 - 4:49 pm | Permalink

    Do you mean Alfresco ( It is open source, but may require extensive customization, much like Drupal. As ever, free doesn’t necessarily mean cheap (but has other benefits).

  • December 2, 2009 - 5:03 pm | Permalink

    @Janet, ah yes, thanks! Sub o for a. 🙂

  • December 2, 2009 - 6:25 pm | Permalink

    Having participated in any number of collaborative authoring efforts, from technical documentation through policy development and commercial document creation, I find that the project management aspects and ability to track component status is really key. Collaboration is a process, not a product and no product ‘makes’ people collaborate. Having said that, you need flexibility in the process to enable people to work the way they best work or you lose a lot of the benefits of the process.

    I think the publishing issue is also a key one. The tools you choose need to be able to deliver the output you need. One of the key benefits of topic and component authoring is your ability to publish to multiple formats with out rework.

  • December 4, 2009 - 8:10 am | Permalink

    We use Alfresco Community Edition, which comes with a decent collaboration offering, Alfresco Share, built on top of it. My users have taken to it pretty well, and I’d recommend it for searchable sharing of documents and collaboration at a document/wiki page level.

    Lots of people sell Alfresco with other things on top – custom document management portals, Liferay, and such – and these sort of things may well cost a significant amount. For example Alfresco+Share won’t publish for you out of the box. Wiring in DITA or suchlike is the sort of thing that a consultant would have to do.

  • December 10, 2009 - 5:30 pm | Permalink

    Cool post, Anne. I think you showed me a preview of this research at the WebWorks conference. I’m currently pursuing the Mediawiki route.

  • December 10, 2009 - 6:55 pm | Permalink

    Great points Anne! At Embarcadero our programmer docs are now all developed and distributed w/Mediawiki, and the Help2 system is generated from the wiki. We have a fulltime developer to handle the administration and plugins and scripts, so it’s not free. It’s been definitely worth it, as our writer/reviewer productivity quadrupled over previously using DITA/Epic. On the other hand, we lost the ability to output nice PDFs, and have to do more custom development for that. Also, versioning is not built-in. It’s definitely a work-in-progress.

    Another option is SocialText, who seem to have solved the versioning and workflow problems, but they charge by the number of users. That pricing model was a non-starter for our situation, but could work for others.

  • December 10, 2009 - 9:21 pm | Permalink

    Wow, thanks for the comments everyone. I had previously only shared this report with a handful of people and hesitated to post it – but by posting it I’m learning much, much more! Now there’s something to be said for collaborative authoring but also for freely information sharing. I’ve been paid back multiple times.

    Yep, Tom, it’s a revision of that the printout I had at the RoundUp.

    Good point, Dee, about fulltime wiki developer. I also haven’t taken a serious look at SocialText so thanks for the pointer!

    And not to post to another wiki post from this one, but Rahul Mehrotra left an interesting comment just today about their wiki implementation on a separate post at Ironically, “…we won a company award for innovation right before our collaborative documentation environment got us outsourced” yowsers.

  • December 11, 2009 - 12:18 am | Permalink

    Dee, I’d love to connect with you to ask about your mediawiki strategies. If you see this msg, shoot me an email at

  • December 11, 2009 - 12:14 pm | Permalink

    Very useful information, Anne. Thank you.

    I’m very interested in tools that work with Confluence and MediaWiki, as we use both of those wikis at the National Cancer Institute. I welcome hearing from anyone with comments or recommendations.

    We’re also considering XMetal as our DITA authoring tool, so I’ll talk with our JustSystems rep about their collaborative authoring options.

  • December 11, 2009 - 3:22 pm | Permalink

    I have been involved with both implementing, developing and supporting content management systems and collaborative authoring environments for a decade and your post and approach is dead on.

    Listing your requirements, as you have is absolutely essential to producing the desired/required system. The big question then becomes ‘Build or Buy’ (or a mix of both)? Each has it’s own set of issues to then overcome. ‘Build’ would nowadays involve one or more open source solutions, with possible tie-ins to proprietary systems. ‘Buy’ involves reviewing the numerous proprietary or commercial CMS/Collaborative systems now available; SharePoint, Author-It, Documentum, etc. (I think your cost estimates are a bit on the low side though.)

    For those systems I have developed most recently there are less requests for printed media and more for online output formats; HTML, (X)HTML and XML. One hurdle concerning open source I see in your requirements was the need to use “Windows-based, with a SQL Server installation available”. Entirely possible but with additional effort required since many don’t well have documented support for it, yet.

    I also slightly disagree with Birgit’s comment; “While Drupal is “free”, it’s also a mix of potent and complicated, therefore you very likely need a PHP programmer at hand for the customizing.”

    I feel what you will really need when considering robust CMS/Collaboration frameworks such as Drupal is a Drupal implementation expert, not necessarily a PHP module developer or programmer. Drupal implementation experts have in-depth knowledge of which Drupal modules can provide the desired functionality with minimal customizations. Contacting the Drupal module developer can also provide the ‘short path’ to customizations too. The same is true of any other open source web application. Finding and including those experts during an initial system definition is also essential and can save you from countless hours of aggravation, frustration and unneeded customization.

    “I’m working on a large Drupal-based Intranet solution and have first-hand experience with it and trust me – it’s not easy and out of the box like e.g. WordPress”

    Of course not! Comparing WordPress to Drupal is like comparing MS Word to FrameMaker. Word is a word processor Sherman tank on steroids and Framemaker is a true document processor. Drupal is a CMS framework; you build what you need with functionality via modules. WordPress has it’s roots as a single purpose, that being blogware, NOT as a ‘true’ CMS or framework, although it is now moving in that direction.

    Some other considerations when approaching projects such as yours are MySQL and other database experts, as it can be fairly easy for them to just ‘pull-convert-and-migrate’ existing content to your required formats and newer system implementations. Also concerning conversion/migration the free opren source phpMyAdmin is also a tool to look at as it can among others things export ‘content data’ in a number of useful formats; CSV, CSV for MS Excel, MS Excel 2000, MS Word 2000, LaTeX, Open Document Spreadsheet, Open Document Text, PDF, SQL, XML, YAML.

  • Pingback: collaborative authoring trends and costs « host spy

  • Pingback: Problems with Collaborative Authoring Projects « For the Technical Writer

  • June 16, 2010 - 2:34 pm | Permalink

    I’m rereading this post and finding it very valuable. We’re trying to find an enterprise collaborative authoring platform at our organization, so this info is right on target.

    On a side note, I have some style feedback. Is there any reason to use 11px size subheadings? If you go Appearance > Editor and add .post h2 {font-size:16px;} at the bottom of your stylesheet, this display would look a lot better. 🙂

  • June 16, 2010 - 3:12 pm | Permalink

    Ah, yes, I’ve been meaning to change the headings! Done. Oddly, it wasn’t inheriting from .post h2, it’s in a separate tab.css for this particular theme. Here’s hoping I didn’t break the tabs (doesn’t look like I did.)

    Glad this post is useful to you still. Another collaborative authoring platform I’m using lately is MindTouch, and I’m pretty excited about their next release. Add them to the evaluation list for sure.

  • Pingback: New technology in technical writing | Insights about technical writing

  • Leave a Reply