Why Bricolage Rocks

The Wall Street Journal has a fascinating Online Article about why Windows Vista had to be rebuilt from scratch. The problems it faces are the sort of problems that I work very hard to encourage developers to avoid. They even mention how testing used to be done by hand instead of being automated. Testing by hand when you can automate is stupid, stupid, stupid.

What's more interesting to me is how the story was published. Take a look at the URL:,,SB112743680328349448,00.html

If someone emailed you that URL and said "take a look", would you? If you're really busy, you might not. That URL conveys no information to you other than the fact that this is an article on WSJ's online version (and if you don't know what WSJ is, that's just as useless). The problem is in the document name:


What the hell is that? That tells me right off that bat that WSJ uses Vignette's "StoryServer" to publish their Web site. StoryServer is what is known as a "Content Management System", or CMS for short. Content management systems allow you to manage huge Web sites. As for Vignette, a long time ago someone apparently decided that they would build URLs based upon information in their database. As a result, though many search engines use URLs to help index information, you cannot take advantage of this with Vignette. It's also very difficult, when debugging, to just look at a URL and get a sense of what's going on.

Compare that URL to how Bricolage might create one:

Now if someone emails you that URL, you can actually figure out if you want to read it or not. You can figure out if it's timely or some story published a few years ago. And more importantly for those who manage Web sites, search engines can figure this out too.

Other differences between StoryServer and Bricolage, my employer's flagship product: StoryServer typically forces you to have their software running on the server that's handling your site. We don't. As a result, they have to deal with numerous security holes. We don't. Our server pushes content out to the main servers and you can use any technology you want to serve it. We don't tie your hands. You're free to pick and choose the technology that's most appropriate for your needs.

Interestingly, because we don't force you to use a proprietary front-end solution, this also means you can do something with Bricolage that other content managements systems usually don't allow: use it for something other than Web sites. For example, one organization talked to us about using our software to management a bank of monitors in their lobby. You could use our software to manage magazine production. You could use our software to manage just about anything you would write software for to manage content.

Of course, there's the little question of price. We're free. We're also open-source. You can take our product, use it, change it, manage huge Web sites and not pay us a dime. Of course, given how huge the product is, it's still more cost-effective to hire us for installation, training and consulting. We also have great support contracts. These are things you have to pay for with Vignette, too.

However, given that our core product is free and open-source, what about Vignette's? Well, try and find a price on their Web site. Just try it. They don't want you to know. One person contacted us after he discovered he needed a more scalable solution than Plone (another free, open-source content management system). He initially contacted Vignette. Apparently, the first question they asked him was who was authorized to sign purchase orders. After going back and forth a few times, they kept asking him who could sign purchase orders but they wouldn't name a price. After they finally did, it turned out to be a rather large six figure sum.

We, of course, are free. While I can't name the gentleman who described this horror story with Vignette's sales team, I can say that he's one of the world's largest distributors of a very popular product.

My father, on the other hand, asked an obvious question: if Bricolage is so good, why is it free? Well, to those used to developing something and selling it, the open-source business model seems strange. It's tough to describe how we benefit from people and companies all over the world adding new features and giving them away, thus increasing the value of this product immensely. By giving away our product we increase its userbase in a way proprietary software can't. Training and consulting is where the true long-term money is.

And we are good. Just read what eWeek has to say about us:
Bricolage is quite possibly the most capable enterprise-class open-source application available. The Web content management application features excellent administration capabilities, and it is highly extensible and capable of managing even the biggest and most complex Web sites.

And who are the companies using Bricolage? Try RAND Corporation. Or the World Health Organization. Or the Congressionally funded Radio Free Asia. The latter uses our software to maintain a Web site published in 10 languages including Mandarin, Cantonese, Lao, Khmer, Uygher, amongst others. (Heck, have you even heard of Uygher?).

And as an added bonus, we just added the ability to write Web template pages in PHP, not just Perl. I don't know of any other CMS which allows more than one language to do this. We rock :)
  • Current Mood: working working
And as an added bonus, we just added the ability to write Web template pages in PHP, not just Perl. I don't know of any other CMS which allows more than one language to do this. We rock :)

Have you taken a look at Drupal? It's what I'm using for Project:Lucidity, and it supports multiple program languages. Actually, each of its templates are based on different programming dynamics (they're not just different colors or theme layouts).

So far, I've been pretty impressed with Drupal's versatility.

I might take a longer look at Bricolage, though... I'm always open to something new.

Just glancing through the Drupal site, I don't see anything about managing workflows (it might be there, but I don't see it). Workflows are a very important part of large-scale CMSs. Let's say I'm a reporter and I write a story. Does it get published? No. Many organizations require a copy editor to make sure the spelling and grammar are correct. They might require a style editor to ensure the content and "style" of the article are appropriate for the Web site. Many even require a legal department to vet all articles to avoid any chance of libel.

As a result, you might have four "desks" the article has to pass through and an order in which it must pass:

  1. Author
  2. Copy
  3. Style
  4. Legal

Large-scale CMS systems allow this type of workflow to be enforced. Could you imagine a company allowing a libelous article to be published and having a lawsuit put them out of business because they forgot to double-check the article? You won't see the Wall Street Journal making that mistake any time soon.

In working through their demo, I see that they also don't encourage the separation of presentation and content. For large scale systems, this is a disaster. Since Drupal appears to encourage using HTML directly in the story body, you can't just take the information and reuse it for plain text (such as if you're sending email), creating PDF documents, producing LaTeX (if you want to manage magazine content), or similar things. Also, their demo encourages people to use PHP. PHP doesn't work too well in those other formats, either :)

Of course, Drupal is probably just fine for your needs. Bricolage is designed for large systems. Once you learn it, it's easy to use. However, our competitors frequently charge more than a quarter million dollars for similar functionality. You can imagine that it takes a while to learn.

I'd suggest looking at their modules.

Their core system is just that... a core. Most, if not all, of what someone might need can be found in the Modules section. For example, the "Workspace" module might be what you're looking for in regards to workflow.

There's also an "Evaluate" module, mainly for students and teachers (to upload and evaluate reports). Plus, there are roles & responsibilities for posting... such as a group of "Editors" being given evaluation of posts priviledges.

There is a LaTeX module, as well as an HTML to TEXT translation module.

As far as "separation of presentation and content", I'm not really sure of what you are referring, so I can't really give any info.
BTW, as far as a publishing platform with some of the issues that you described, The Onion uses Drupal.
Sorry for the multiples here... LJ doesn't have an "edit" function for comments...

Regarding the "Workspace" function in Bricolage, the Administrator function in Drupal has exactly what you're talking about. Viewing posts and entries, editing, monitoring rules and responsibilities, etc.

BTW, I was wondering if you'd like to be a contributor to Project:Lucidity for your political articles. I could set you up with various priviledges for posting.
It seems I'll have to pay more attention to Drupal. It does sound interesting. However, I'm skeptical about any functionality to "translate X to Y". It's much easier to have a canonical format and write one service to transform that format rather than have to parse an arbitrary format (like HTML) and then translate. Still for most people's needs, that's probably a non-issue.

As for contributing to Project:Lucidity, I would like to but I'm concerned about over-committing myself. With my grant committee work my free time is sparse right now.
RE: Contributing. I totally understand over-commitments.

If/when you do some political writing (or economic, sociological, philosophical, etc), I would be pleased if you'd consider posting on P:L in addition to wherever you also post.
The site is only about a month old. In just the past few days I've started to market it at various forums and blogs (I wanted to get some content up before putting my neck out there).

Checking my stats, I had about 60 unique visitors a day for the past 3 weeks. I figure most of those are bots, though.

I do have a counter up on each post to let me know how many unique reads there are for each article.
small shop vs enterprise
To use a line from my favorite enterprise-level CMS, "perhaps you need a bicycle" ( - halfway down). I've used Drupal, and I've used Bricolage and there truly is a huge difference in their target markets. Drupal is fabulous for small organizations, blogs, etc., but it just isn't designed for large installations that require arbitrary workflows, sites with subsites with arbitrary presentation styles, etc., etc., etc. At the enterprise level, there are features (and complexity) that Drupal just doesn't have. The flip side of it, is that Bricolage, and (to a lesser extent) Typo3, are much more difficult to install and administer, simply because of the sheer amount of configurability they offer over (say) Drupal.
If it's a system that you work on, then how can I trust you to be objective in discussing it? ;) jk

But seriously though, I'm actually glad you've posted this. I'm most likely going to start doing some work for an up-and-coming non-profit organization that wants the abilities that Bricolage seems to offer. We'd looked at using things like Drupal (as mentioned in another comment) and wound up settling on Mambo, but at an initial glance, Bricolage seems like a better solution that's enterprise-level without looking too daunting.
So who uses it with AxKit?
I don't know of anyone who does, but that doesn't mean they don't. All you would have to do is have Bricolage publish stories as XML and publish to an AxKit server.
Sorry for the anonymous comment, I forgot to login.

But what about dynamic content, I know for the CMS content is somewhat dynamic through the template system then XML (or other formats) are generated that in turn can be handled by an AxKit provider.

I don't know how one would manage XSP content with this system, which is my case is what my company needs since we don't really publish "articles" per say so much as dozens upon dozens of small CGI (xsp) applications for internal use.

I'm still a cp skeleton <application>; vi <application>. it would be nice to find a system to cut the fat off the of building all of this little disposable tools.

God, I wish I had a "flow" to "workflow" manage, but it's just me and doesn't look like it is going to change for a while ;)
If you look at and, you'll see two sites where we do produce a lot of dynamic content. We have Mason code that simply writes out the PHP to that the front-end server can use.

Also, despite those two Web sites looking fairly different, they reuse much of the code and templates. We use CSS to alter most of the look and feel.
Check out XIMS
XIMS is specifically designed for working with AxKit, and was originally built for large enterprises (a University). I think you can find it on sourceforge.
Re: Check out XIMS
Actually now that you mention I was just reading their website (XIMS) and it seems pretty nice.
"And as an added bonus, we just added the ability to write Web template pages in PHP, not just Perl."

You *know* what question I'm going to ask next, right? ;)
Database support...
Do you think having only one database supported (Postgresql) is a good thing? You would then force me to use the RDBMS in my company when we have Oracle across our enterprise? I do see that there is an Oracle adapter but you also note on your site it is "woefully" out of date. Backend storage should not be forced either.
Re: Database support...
Easier said than done. Bricolage was originally designed for Postgres for (actually, they used a precursor). Because of this, there wasn't much need to create a system flexible enough to support multiple databases. You are not the first to complain about this, but so far it's not been too much of an issue. There are two reasons for this. First, those who adopt open-source products generally don't want to pay for Oracle licenses in the first place. Second, no one has wanted to pay for Oracle development and they don't mind the fact that Bricolage can stand alone and doesn't need much Postgres expertise once it's set up.

Currently I am working on Bricolage 2.0. This version currently supports Postgres and SQLite. The latter is so that a user can create a single person install for demo purposes. However, because we're developing it for two databases at the same time, this means that we know we have a flexible architecture which can support any database anyone wants to write a module for. Fortunately, writing such a module is very simple. (We also wanted to support MySQL out of the box, but even the latest versions of MySQL are too primitive for us. Still MySQL is getting better, so we have hope.)
Re: Database support...
I look forward to seeing the 2.0 version. MySQL...don't get me started now that Postgresql is native on Windows I wouldn't bother but I am the one who questioned not having a neutral backend scheme. Ah well...

I might not have been clear. We have Oracle. I would be integrating Bricolage into our Oracle setup but you answer makes that pretty much a moot statement any way but I state it for clarity.
Re: Database support...
Well, if you folks wanted to do some work on the Oracle adapter, we'd be happy to include it with the next version in order to ensure that folks can use it/support it.

By the way, may I ask who you work for? Just curious. (Also curious to know if I know of you)
Re: Database support...
I am a contractor for Northrop Grumman and I am currently working on a project for the Coast Guard. My name is Robert Hicks and I would be "sigzero" where I leave postings.
Well, try and find a price on their Web site. Just try it.,2097,1-1-30-72-616-4213,00.html

Yup 6 figures for entry.

Very interesting. I like their lead-in quote:

Vignette is not moving down the food chain by releasing a suite with an entry price of about $125,000. Rather, the company is responding to "new realities" of the software marketplace that dictate starting small.

A $125,000 entry price? This is "starting small"? The reality is, they have moved down the food chain. They used to be big players but I understand they've been losing market share. Open-source CMS's (and not just Bricolage) are kicking their tail.

Who cares about the URL?
Honestly, I can't remember the last time I've typed a URL that wasn't the home page. I get to pages by other links - either in web pages, emails or bookmarks. I see this gripe about Vignette URLs a lot, but frankly, the only people who care are CMS purists. The general public doesn't care...
Re: Who cares about the URL?
Who cares about the URL?

Many of our customers care about the URL. Many search engines care about the URL. Tim-Berners Lee cares passionately about the URL.

Those who fail to understand the beneficial nature of reasonable URL structure should read what the W3C and Tim-Berners Lee have to say on the topic.

Just because you don't care doesn't mean that others don't. There's a reason well-thought out URLs are important.