To me, it's the fact that Mirth nickel-and-dimes users for "premium" features and has pretty poor documentation to push people towards support plans. It's an open source platform "kind of", which rubs some folks the wrong way.

However, the functionality of the engine itself is top notch. We've had some Mirth servers running for a year at this point without incident. It handles alot of things around the nuances of HL7 nonchalantly, which has usually been my hang-up with non-healthcare specific toolsets like Mule or Camel.

User interview protip: if you actually want to know what's wrong with your product, never tell people that it's your product.

At my last startup, we did user tests every week, and my cofounder was very careful never to let on which test items were made by us. We didn't have our name on the door or on the buzzer. Nothing with our logo was visible between the entryway and the user interview room. And when he started showing products, he'd always start with somebody else's.

It was great. We got some incredibly honest feedback (sometimes brutally so) on what we were building. It helped us kill a lot of bad directions early. Most people just don't want to tell you that your baby is ugly, but they'll happily dish if they think it's somebody else's.

Last time I used Mirth (going on 3 years ago now), it was a pretty good engine wrapped up in terrible UI/UX. The core logic and some of the built-in transformation (particularly the HL7v2 parser, actually!) was good, but any time you had to interact with Mirth through the dashboard (say, for example, building a channel) it was incredibly painful -- especially if you had to chain multiple channels in a row. No way to see the flow of data, and lots of fumbling interactions with a clunky JWS interface.