Peter Dykstra, MetaphorX LLC
Traditionally companies considering Content Management Systems (CMSs) have had no choice but to work with a commercial vendor. A growing number of mature, standards-based open source CMS systems are now available and continue to evolve. This article reviews one company’s experience using the open source Daisy CMS.
A few years ago Donovan Data Systems (DDS), a software services company with about 1,000 staff, decided to set up a centralized library of software architecture documentation for its developers in the US and UK using open source software. The goal was to provide a central library for 10 development teams, providing common central access and a consistent format. A Java shop, DDS started by looking at Java-based open source projects from the Apache Software Foundation. (The Apache Web server is used by most web sites in the world.)
The Daisy CMS, developed by Outerthought, a small software company in Belgium, is not itself an Apache project but uses Apache components, is available under the Apache license, and is used to manage documentation for major Apache projects. Daisy is a self-contained CMS that runs on Windows, Linux, and Macs. It has two components – the Daisy repository and the Daisy Wiki.
The repository provides central document storage using MySQL, a well-known and highly scalable open source database.
The repository stores documents in a single ‘big bag’ using a simple sequential numbering scheme. Each document can have one or more fields attached to it (such as author, department, document type, status, and so on); the fields can be used for listing and retrieving documents and creating virtual document hierarchies on the fly.
The repository contains both ‘Daisy HTML ’ documents (well-formed XML) and ‘attachment’ documents, which can be virtually any file. Full-text search includes Daisy HTML and common attachment types (Microsoft Office, PDF, and plain text attachments). Other features include role-based authorization, document versioning, and a powerful SQL-like query language for querying the repository.
The Daisy Wiki is a standalone web application which provides a user interface for finding, viewing, and editing documents and administering the repository. Multiple Wiki ‘sites’ can automatically display documents that meet certain conditions; a Call Center Procedures site could show documents where Department equals “Call Center” and Document Type equals “Procedure”.
Daisy can convert Daisy HTML documents to formatted PDF on the fly. Daisy’s book publishing feature lets you use queries to pull together dozens (or hundreds) of topics into a formatted PDF book, complete with cover, page numbers, and a table of contents.
The Wiki communicates with the repository via a documented API. If desired, you can write your own applications to perform all repository functions via the API, independent of the Wiki.
Daisy’s documentation includes a step-by-step setup guide, which is clear and complete but assumes a fairly technical orientation. Setup requires installing Java and MySQL. The Daisy installation itself consists of setting several system variables, executing a series of batch files, and following the prompts. The documentation suggests that the installation can be done in an hour. If you’re not familiar with the environment, allow two or three. We installed Daisy on a production server using an LDAP password scheme so that Daisy users could use their existing user IDs and passwords.
To configure the system, we set up custom document types and a metadata scheme, a site for each work group, and a “Home” site containing overview material. We modified the Wiki skin with our logo, changed the font and the color scheme, and adjusted the page formatting.
We encouraged developers to author their own documents but also provided editorial assistance, assigning an editor to pull content together from other sources into the new Developer’s Library. The editor wrote how-to documents, offered training, and provided troubleshooting for the authors.
It was easy to copy and paste the text of Word documents into the Daisy editor with relatively minor formatting changes. If a Word document had custom formatting or graphics that needed to be preserved, we added it as a PDF attachment.
Partly because the project was sponsored by their managers, all the teams participated at some level. We built an initial library of 1500+ documents across our 10 teams. The initial library provided a critical mass resulting in awareness of the resource, word of mouth recommendations, and a consistent level of use.
In follow-up evaluations, many developers credited the library for giving them access to information they had not had before and for raising the general level of technical understanding across teams.
Users appreciated the single point of access, consistent format and full-text search, and found the multi-site structure intuitive. Our metadata was simple for readers to understand and editors to apply. Authors found the browser-based authoring tools easy to learn and use.
On the other hand, document creation/editing was done by a limited group. It was easy to train motivated authors who had basic Web/HTML understanding. It was not easy to motivate people who were not interested. We could not have reached critical mass if we had not provided editorial support; this support also raised editorial quality which made the library more usable.
Daisy has proved to be a solid and reliable system. Since it was originally designed to manage software documentation, Daisy was a natural fit for our project. The database, search engine, web front end, editor, and messaging system are seamlessly integrated. The repository architecture and the document model provided a flexible, structured platform for establishing our document categories.
The project did have a fairly steep learning curve, requiring us to develop knowledge of information architecture, content management, XML technology, and Daisy in particular. Beyond Daisy’s immediate benefits, project managers are also confident that this knowledge can be leveraged and extended to other areas within the organization.
To read the original, full version of this article which originally appeared in Best Practices, Volume 9, Issue 4, please contact the CIDM Administrator, Susie Ebbs.