IT Troubleshooter | Harper Mann » Developer's Perspective on Wasted Time With Proprietary "Support"

December 19, 2006 | Comments: (0)

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

TAGS: Open Source

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.

With Mule, you have all the source code, and not just a periodic "export" of it, but the actual, bleeding-edge development tree. In addition to this, you have the JIRA database of outstanding issues, tasks, and new features. What that means is that if you want to know if any progress is being made on an issue, you can "watch it" in JIRA to see anyone has assigned it to him/herself, whether it's currently "In Progress," you can read comments by developers or other users on the issue, and comment on it yourself, which means a direct line of communication with the developer who is/will be working on the issue. You can check out the source code from Subversion and get updates as often as you want to see if anything has changed. And if you run into a deadline like we did with the Oracle JDBC issue, you can just fix the issue yourself in the actual source code, avoiding bottlenecks in your project timeline, get it into production, and then submit the fix to be incorporated into the next official Mule release, which will help make Mule a better product, make other Mule users happy, and generally make the world a better place.

To people new to open source development, the idea of delving into the source code often sounds daunting, but if you already know what is going wrong, you'll often find that the fix is simply adding an "if (var != null)" check. Now why should you have to speak with 3 levels of support and wait months for that???

And speaking of users, you have a whole community and "ecosystem" of Mule users and integrators to tap into when you get stuck. Chances are, someone in that community has already encountered the same issue as you and can offer some advice. Of course, no one has more knowledge of a piece of software than the team who actually wrote it, which is why the community is not a replacement for the level of professional expertise MuleSource can offer you, but the community does provide orders of magnitude more feedback than any proprietary vendor ever could. And since Mule can be used to integrate just about anything under the sun (not Sun, but yeah, that too :-), if you have a very obscure use case (trying to use Mule to integrate your old DEC mainframe with load-balanced web services using a custom TCP protocol via the serial port, eh?), the user community is going to be your best resource (try getting feedback from a proprietary vendor on that one!)"

Posted by Harper Mann on December 19, 2006 04:04 PM

RATE THIS ARTICLE: