It's been great to read the blog posts from CMS 2006 - I was there in 2005, when DITA had its first full track at a conference, and the excitement was building then. It's amazing how far we've come in just a year: from one or two CMS vendors with DITA support to all of them! Although I suspect that as with the editors, the level of support varies, and features will continue to improve over time: typically supporting topics first, then maps, and finally specialization. Still, the level of focus on DITA as a common standard across CMSs is amazing, and one year since the standard was published is a very fast time to achieve consensus in an industry.

It's also interesting to see the support for DITA begin to percolate up and down the solution stack: from web-based editors and CMSs up to enterprise-level knowledge management. I'm really hoping we'll see more activity on the open-source and Wiki front, to get the cost of entry as low as possible: everyone starts small, and one of DITA's benefits is that it works at any level from single writer up to cross-enterprise knowledge management.  As long as you're dealing with topics, maps, and specialization, you should be able to preserve your content and relationships from a single-person project up to a cross-enterprise one, choosing the appropriate tool for the scale of your effort as you grow without ever obsoleting or migrating your content. From an enterprise point of view, that makes the whole company more nimble, since the enterprise can combine and integrate knowledge assets as customer and organizational needs dictate, rather than following the dictates of technology. From an individual point of view, it means your content is worth more, since it can be used in more ways, and the cost of reuse is distributed to all the projects who want your content, instead of accumulating on the back of the original project until it breaks.

So what we need is a tool stack that:

1. Starts with DITA output from Wikis, blogs, and HTML-like editors (wikis and blogs in particular are naturally topic-oriented, even when they're not particularly information-typed); that gives us a ready source of reusable topics, an authoring interface that doesn't require special training, and a way to start the cycle. For example, author starter content in Wikis, formalize them in XML editors, republish on Wikis for review and annotation, and reuse in other Web sites, PDFs, help sets, and so on.
2. Then add map support, so features like taxonomies, tables of contents, and relationships/links can be exchanged across tools using the DITA map format, instead of being locked into one tool. In other words, once you've got reuse of topics/content, move up the value chain and start reusing maps/context as well.
3. Then add specialization support, so different groups can encode different rules for their content, and different rules for their output, while still sharing the information and rules they have in common with others.
4. Then add reuse management and workflow support, to help keep track of conrefs and conditional properties and stages of document development, from authoring through review to publishing and annotation.

I think there's room in that tool stack for a mix of open-source and proprietary tooling, pretty clearly: the important thing is to make the entry level cheap and easy enough to justify the initial move, and then the transition to each additional level justifiable by the cost savings and quality improvements of the previous level. That way instead of having a huge one-time investment that must be justified in advance, you can have a series of smaller investments that scale up in synch with both your requirements and your savings.

OK, someone else go make that work :-)