Moving a great story from concept to content requires inspiration, a little creativity, a lot of proofreading, and publication – or as they say in the newsroom, “Copy!” A good web content management system (WCMS) makes this happen seamlessly for the content creator. In the newspaper business where a quick content turnaround equals revenue, the last thing software should do is stand in the way.
Bricolage is well known throughout the publishing industry as a WCMS that can manage huge content repositories for organizations such as newspapers and magazines. This is a great claim to fame since an important WCMS component is often moving large amounts of content from idea to internet as quickly as possible.
At one time, Bricolage was one of the big kids on the block, set to capture a large share of the open source marketplace. Development of the product appears to have moved underground and the original core team is no longer working on the project. Pure perl geeks are sure to love Bricolage because of its total commitment to the language. Positive reviews and comments are not hard to come by. There does seem to be a niche for this product on the web if only for high volume web publication systems.
There is currently some listserv chatter about updating the platform to support Windows, PHP, and Apache 2.0 but it is hard to tell how imminent these changes are. With its future uncertain, any large investment in the development or implementation of Bricolage would be a risky proposition.
Bricolage began life as a homegrown content management system for Salon.com. Before it really got off the ground, the system was taken over by the About.com team. Then in 2001, About.com released the 1.0 version of the software under the BSD license. If you have been around the WCMS world for a little while, you may recall that Bricolage was quite the tech media darling. Its install base was quite impressive, ranging from the World Health Organization to MacWorld and even to large content providers like The Register.
However, it appears that development ground to a halt in June of ’06. No news has been posted to the home page and no code has been published since then. Even the lead developer, David Wheeler, has not mentioned the project on his personal blog in two years. For all practical purposes, the Bricolage project should be considered dead.
The most direct competition for Bricolage are packages like ez Publish, TYPO3, and now Alfresco. These are all very active, innovative projects. The core Bricolage package may stack up well against some of these other vendors but the lack of support and software releases will make IT managers think twice before going down this path.
Bricolage is built specifically for Linux and runs on Apache 1.3 and the PostgreSQL database. It does not run on Windows, MySQL, or the Apache 2.0 web server. There is new development underway that aims to address these issues however, current software restrictions limit potential new customer acquisition.
Even though there are some advantages to the PostgreSQL database, most open source WCMS packages have redirected their efforts at MySQL, Oracle, or Microsoft SQL Server. Another limitation to the widespread adoption of Bricolage is the use of perl as its primary programming language. Though perl is still in use for niche web applications, gone are the days when an entire web application is built exclusively using perl.
The Bricolage team decided to leverage the HTML::Mason language for imbedding perl within HTML pages. This language comprises the bulk of their templating engine. The system is remarkably similar to previous versions of the Interwoven publishing system where perl is used to store and generate static HTML files for publication on the web server. Unlike Interwoven, Bricolage has no virtualization module to view a site in its pre-production state.
The latest version of Bricolage, 1.10, introduced new features such as PHP templating and LDAP authentication. Users have also contributed a few novel features to the Bricolage universe. First, an interesting use of the Firefox plugin Greasemonkey allows refining the administrative and content production interface. Second, the admin screens are styled with CSS and while you cannot change the layout completely, you can perhaps improve on the not-so-elegant interface that is provided out of the box. Bricolage also includes a very well documented and robust API that allows for the development of additional modules and plug-ins to other systems.
One word of caution: Bricolage is not easy to install. Tim O’Hear, Technical Director for the Geneva-based Revelate, loves the product, but says, “It does have one flaw: it is rather painful to install.” In addition, perl geek Brian Glass confesses, “So far I really like Bricolage, but installation is a bear.” These are just two examples; there seems to be a consensus that Bricolage is not easy to install. Once installed though, administrators report that it runs smoothly.
Content Production Services
Bricolage comes out of the box with several features that end users have come to expect from a WCMS. Some of the key features include:
- A workplace landing page where content authors and approvers can see their tasks “at-a-glance”
- Version Control (with check-in and check-out)
- Web-based content creation and administration
- WYSIWYG on/off feature for content authors to control their interface
- An internal simple and advanced search to find published and unpublished articles
- Simple file upload for images, documents, and other media files
- A story event log which serves as an audit trail for piece of content or media
- Media search and browse feature which allows users to view, sort, and attach media to content for publication
- A workflow and security manager that allow administrative users to manage content approval scenarios based roles and permissions
- A category profile where administrators and authors can edit and refine an existing taxonomy
Unfortunately, there are also several important features that are nowhere to be found. Since the last update of Bricolage over a year ago, the bar has been raised in the area of workflow and business process management. What once required intervention from IT has become quite a bit easier for regular end users to configure. Although the open API could be used to hook into a third-party workflow tool, this would require a commitment to keeping the two systems up to date and synchronized.
The content creation screens, while well documented, are not very intuitive. It is not immediately clear how customizable the author interface is. Since most content authors will just ignore any unnecessary configuration options, it would be nice to be able to turn these off. The lack of an inline editing feature is also a serious drawback. Many content publishers are accustomed to making changes directly on a live page. This is one of the rare WCMS features that research has shown actually increases usability.
While there is excellent technical documentation for API development, there is little to nothing available that would aid administrators setting up the system for the first time. For example, there is no documentation on how to setup or administer workflow. A core feature for any WCMS is a workflow and approval cycle. To take Bricolage to the next level, the team will need to refocus their efforts on completing end user documentation with the same eye for detail that went into their technical specs.
Content Delivery Services
Content reuse and multipurposing was not specifically built into the core Bricolage product. Nevertheless, a competent perl developer with a basic knowledge of the Mason templating language could have database-driven content delivered to multiple platforms (cell phones, PDAs, etc.) in no time.
Delivery options that WCMS owners have come to take for granted such as blogs, wikis, and FAQ tools are missing from Bricolage. With a more active user community, these common needs tend to naturally evolve into special module or plug-in projects by members. Projects such as these pop up weekly on the Drupal, Alfreso, and Mambo web sites. This additional functionality can also be custom developed on a case-by-case basis but more demanding IT managers have come expect this as a part of the core offering.
With a language as flexible as perl, Bricolage can claim to do just about anything on the web with some custom coding. Perl does make some things simple. One of the advantages to using perl is a file parsing speed that makes even Java envious. Leveraging the speed of perl, Bricolage can stage and publish content faster than the competition. Though impressive, these speeds would only be a factor when publishing a very high volume site.
With some custom development, Bricolage can support XHTML compliant code and RSS 2.0 feeds. While focusing on the technical and administrative feature set Bricolage has sacrificed usability and front-end management. Although this is not unusual in the WCMS world, inline editing and other front-end web site management tools are quickly becoming expected.
One of the hallmarks of a healthy, open source project is an active, contributing user community. Bricolage provides several convenient, free options such as mailing lists, IRC, wiki, bug tracking, and even a user-driven template exchange. However, aside from a small, motivated set of developers kindling a dying fire, there is not much community activity here. With no community-based support, you may find that your company will require fee-based support. The only available commercial support is from a company called Kineticode. Bricolage lead developer David Wheeler founded Kineticode. Wheeler offers multiple levels of paid support, ranging from $7,500 to $120,000 annually.
If your company is in the newspaper or magazine business, there could be some valuable lessons learned and free advice in the support archives to help you get up and running. Bricolage was developed with the publishing business model in mind. On the other hand, with support cost running as high as 120k per year for a premium package, it may be a good idea to broaden your search to include vendors with more reasonable support packages or a more active open source community.
For all of its strengths, perl seems to be going the way of the dinosaur. Most new, open source talent is being funneled into Java, PHP, Ruby, and Python. Survival for an open source project relies on change and continual innovation to keep developers interested. If a project stagnates, it will not take long for developers to move on to something more challenging and exciting.
In 2001, Bricolage was way ahead of the curve and even outperformed many of the major commercial vendors of the time. Though there does appear to be some development going on behind the scenes for a 2.0 release, it may be a case of too little too late. In an already crowded marketplace, it is hard to see how Bricolage will differentiate itself and reclaim the darling status it held in the early WCMS days.
- Perl.com: Content Management with Bricolage by David Wheeler
- eWeek: Bricolage 1.8.1
- Embedding Perl in HTML with Mason by Dave Rolsky and Ken Williams
- 2000 OSCON Presentation by Ian Kallen
- eWEEK: Web Content Management Face-Off by Jim Rapoza
- Discovering Bricolage by David Wheeler
- Managing content part II: Bricolage by Tim O’Hear
- Faster, More Flexible Bricolage Challenges CM Vendors by Michael Pastore
- Bricolage-general mailing list
- Case Study: Radio Free Asia
- The Mad Penguin: Small but mighty: little Bricolage carries a huge newsfeed by Christian Einfeldt
- Portal Software: Passing Fad or Real Value? by Janus Boye
Special thanks to Tony Bryne who’s template I used and who’s encouragement has kept me writing about content management.