At work at the moment, we're using a commercial Rules Engine product (that I will not name for obvious reasons1). Rules are entered through a Graphical User Interface that obviously looks really nice when you're giving a demonstration: “Look! With a few clicks you can add a new business rule. All the available objects and methods are in these convenient drop-down menus. It's so intuitive!” The rules are then saved in a set of XML files that are, like most machine-friendly XML, totally opaque to a human author2.
There are a number of really annoying user-interface glitches. It's incredibly inconsistent. Some simple things (like cut/paste, or multiple selection) are broken in various subtle or less-subtle ways. As a result while the UI is perfectly passable for adding one or two rules, or making minor modifications to existing rules, it really really really sucks when you need to input two hundred or so of the bastards.
I'm not making a particularly controversial (or new) statement when I say that when developing some project, having the development team “eat their own dogfood” is a very useful technique. If you are writing an email application, have the developers adopt it for their email. If you are writing an IDE, have the developers use the IDE to write its own next version. Nothing focuses a developer more than the desire to fix something that's annoying them personally.
When you're writing a commercial rules engine product, you're not likely to be eating your dogfood. You're going to be testing it, you're going to be demo-ing it, but you're not going to have that day-in, day-out experience where every problem becomes a personal annoyance, rather than an abstract bug report.
This is an advantage Open Source can have. The successful Open Source frameworks are those that the authors wrote to use themselves as part of some larger project, and then released to the outside world. A commercial product is more likely to have been written specifically for the purpose of being sold commercially, and not used in-house (of course, many commercial products can be both). While this may sound like you end up in Open Source with something that was a by-product, an after-thought, the truth is that what you get is some very well-chewed dogfood3. You get the John West Seal of Approval: the product that the developer wanted to use personally.
There's a flip-side, of course. One example of this is JBoss, and its mass of thinly documented XML configuration files. Of course the developers know exactly how they work. They know where to find everything so they don't find the complexity annoying4. Find that a problem? It's Open Source and you can fix it yourself. However, by the time you know enough about a product to fix a problem like this yourself, you know enough not to be experiencing the problem any more. Hence it falls down the back of your priority list. Catch-22.
1 except to say, since some people might assume it from the fact I'm primarily a Websphere consultant, it's not an IBM product.
2 for God's sake. If you're going to use XML as a serialisation format, design your schema to be human-readable and human-editable. Otherwise what's the point of using XML? A binary format would be so much more efficient.
3 the great thing about this supposedly approving metaphor is how disgusting it is when you really think about it.
4 insert your favourite theory about wanting to sell documentation and/or consulting here, if you like.
