Developer's Perspective on Wasted Time With Proprietary "Support"

One of the most agonizing IT troubleshooting pains is when you experience problems with a black box technology, then find yourself held hostage by the proprietary vendor's support system. In an interesting blog entry, one of the core developers in the open source Mule project -- Travis Carlson -- outlines his frustrations with proprietary support in a previous job, and explains the immediate support upside that a customer experiences when they go open source:

"Before I discovered high-quality open source software like Mule, vendor support had always been a sore subject for me. I had been working on a large application integration project for a network backbone provider in Latin America. Our IT department had purchased a "market-leading" very expensive proprietary integration software, with a hefty ongoing "support & maintenance" fee attached to it.

Of course, our first big support issue with the vendor surfaced as soon as we went about implementing their solution in our environment. It turned out that their JDBC connector did not fully support Oracle LOBs, which was an absolute necessity for our implementation. We filed a support request, and they eventually acknowledged the issue, but would not be able to provide a serious patch for about 4 months. Our system needed to be in production within 3 months, so we ended up developing an ugly workaround ourselves, which then, by the time the patch finally came out, remained in production for fear of "introducing entropy" into a system which had already gone through the Acceptance Testing phase (sigh).

And then there was the issue of wasting developers' precious time dealing with our vendor's support personnel.

If you've ever dealt with support from a large-scale vendor, you know how it goes. The first-level support guy often actually has less knowledge of the product than you do since you've been working with it day-in and day-out for weeks. Then the second-level support guy might have the same amount of knowledge about the product as you, but of course has no knowledge of your organization, IT environment, or business use cases. And then the third-level support (engineering) is generally inaccessible ("those guys should be insulated from support requests"), so you're left with filing an issue. At some point in time the engineers will eventually work on a patch, but the whole process (like the software itself) is a black box.

Once I discovered the alternative: enterprise-class open source software, which for Application Integration means Mule, the whole story changed.