When writing about the Practical Open Source Software Exploration textbook release, I had a bunch of extra thoughts about Publican that I wanted to separate out to its own post.
My sense is that Publican is in good shape for groups to adopt and extend.1 For example, there was a recent discussion in a MeeGo developer list about what tool to use for end-user help on the device console. The first version of this help documentation for device users is going to be written using RoboHelp, a proprietary platform that has long been used for this type of capability. (The thread does a good job of explaining the reasoning. From my perspective, Intel and Nokia are showing thinking that is evolved and learned from the old days, such as when Red Hat Linux became RHEL and Fedora. It shows they are learning how to use the open source way. I’ve met and had discussions with various community facing folks from Intel and Nokia over the last few years, and they were listening and talking the open source way. Interesting to see how others handle the experience.)
It seems like a good extension of Publican to handle this sort of help output, and if the MeeGo community coughs up a Perl hacker it can probably create the functionality relatively quickly. Publican has been designed by the Red Hat Engineering Services team to support a need to deliver source documents + translated strings as multiple target outputs. I’m sure it can be made to match the i18n requirements of the MeeGo documentation folks. (I just learned that Publican has an EPUB output format, no reason it can’t be easily extended to a ‘help’ format.)
In the MeeGo thread, Dave Neary says,
Im (sic) my dream world, there would be a web application with a wiki-like interface, which would be a view to docbook sources, where changes were sent to a submission queue rather than being immediately displayed, where a maintainer could review and modify/reject/accept proposed changes, and anyone could view the review queue to see what the status for their proposed patch was. I don’t know of any such application 🙁
Dave, I think those components exist and only need a little bit of glue to work for you. Publican plus an SCM on the back-end with Beacon running as a WebUI wysiwyg front-end. In the summer of 2009 Satya wrote code that extended Beacon to support a subset of DocBook that the Fedora Docs Team identified as most used inline and block tags. You plug Beacon in to a CMS as an editor to handle a writing/editing/l10n/publishing workflow. (I think the CMS needs to handle the check-in/check-out with the SCM on the back-end, making the XML files available for edit, and probably adding a commit button in the chain so files can be saved as they are worked on without triggering a nonsense commit.)
We’re working on implementing Zikula in some CMS roles for Fedora, and I hope to see us adopting the Beacon editor there as a choice for writers. This is going to be a whole new effort, and I’m waiting on the first Zikula instance, Fedora Insight, to be running before rallying more support via the SIG.
- I have not always held this view, which is one reason for this public endorsement. ↩