CMS Review: Bricolage

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.

Introduction
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.

Technology
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.

Vendor Intangibles
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.

Conclusion
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.

References

Special thanks to Tony Bryne who’s template I used and who’s encouragement has kept me writing about content management.

6 comments On CMS Review: Bricolage

  • Hi,

    Just a note to say Bricolage isn’t dead, we have a very active user and development mailing lists, with the core development team still active and adding features.

    In fact the latest version of Bricolage was released a week before this article was published.

    While it’s true that David is no longer actively involved in development of Bricolage, he is still active on the mailing lists.

    Commercial support is now offered by several companies and we’re committed to keeping Bricolage going for all the reasons you mention.

    regards,

    Paul

  • Some inaccuracies in this article:

    “Delivery options that WCMS owners have come to take for granted such as blogs, wikis, and FAQ tools are missing from Bricolage.”

    Bricolage is not a content display engine. It is completely removed from display of the final content. One can publish any blog, wiki, even another instance of bricolage through bricolage.

    “The lack of an inline editing feature is also a serious drawback.”

    A couple of WYSIWIG editing packages are supported. If you mean on the live page inline editing, you have just lost workflow control…

    “Bricolage is built specifically for Linux”

    I believe a lot of the initial development took place on Apple OSX, but I think Linux is the most popular platform.

    “For all of its strengths, perl seems to be going the way of the dinosaur.”

    Supporting reference?

    “Bricolage has no virtualization module to view a site in its pre-production state.”

    Preview publishing is built in and works fine.

  • The Bricolage community certainly doesn’t seem “dead” to me: http://marc.info/?l=bricolage-general&m=118779275913145&w=2

  • Thanks for the feedback. I’m glad it has generated some discussion. I’m also happy to have any errors corrected, so thank you.

    I think the intent of the review is somehow being overlooked though. I’m not very technical and usually work as a consultant representing the business in vendor selections. An IT Director or CIO looks for very different things than a developer might. I’m no expert but I have been at this for a little while. Obviously, these are just my views. However, you may find that a business analyst doing broad research on open source content management systems would come to conclusions very similar to mine. My job is to make recommendations and often this doesn’t allow for several weeks of in depth study of each product. These decisions are based mostly on the criteria I’ve listed above (the same criteria used in the CMS Watch Report). I had many great things to say about the product. That seems to have been missed. I hope that over time the project does grow and thrive.

  • I found the article very informative for the reasons that Matthew stated above. I am the UX Director of my firm and I often have to look at the requirements in RFPs. While it is good to accommodate what the client wants sometimes the client is being guided by a developer who, though well meaning, is a bit out of touch with the end user in terms of creating a satisfying user experience. My job is to make sure the two meet with developer and user coming away from the project feeling confident with the site they have just visited. However the user is the point. It is the user you need to satisfy first. And to place developmental issues above the user’s experience will not generate confidence in the user with your site. It is this confidence the user builds that has them returning.

    It is just a fact that the internet has democratized information. The plus is that many people wish to be a part of a community that is increasingly becoming internet based and this encourages the free exchange of ideas. The easier and more intuitive the interface is for the user the more they wish to join that community and will continue to want be a part of it. Those that place their development desires over the necessity of attracting users will find that their site will lose a users interest. And please do not bring in the argument that this is creating an exclusive better class of user because that can be accomplished through fees for usage and membership.

    Bricolage will need to adapt if it wants to keep it’s business afloat. While I will continue to write it in my firms proposals and deliver what my client wants it will come with the recommendation that they steer toward more modern tools.

  • Thanks for satrintg the ball rolling with this insight.

Leave a reply:

Your email address will not be published.

Site Footer