After my earlier comments about support for open source apps I went hunting for some other perspectives on the subject and happened across the FOSSBazaar site (a corporate-sponsored "gathering place to discuss, explore, share experiences and cooperatively solve issues related to FOSS governance").  One post in particular that caught my eye: "Not enough support? No, too many support choices!"  I'm thinking it's not just a case of more, but better.

First, the author's argument:

If you buy Quicken or Microsoft Exchange, it's pretty obvious who you are going to buy your support from. You can call them up and get a quote. And that's it. One provider, all the plans detailed and compared to each other on one piece of paper. Open source, on the other hand, has lots of choices.

The author goes on to enumerate four basic choices: DIY, hiring someone from the community (i.e., go to a guru), purchasing commercial support from the vendor (assuming it exists), and purchasing support from a consolidated support outfit.

But now that I think about it, three -- if not all four -- of those options are also available to the people who use commercial apps as well.  You can try to fix it yourself; you can go to Google, a friendly neighborhood guru, or prowl a newsgroup; you can go to the vendor; or you can go to a third-party contractor who specializes in such problems.

So what's really different with open source?  I don't think it's the breadth of the support options, but the depth that you can get from each one.  With open source, the amount of repair and support you can do, or receive, is correspondingly deeper and more comprehensive.  You're not just stuck with closed-ended black-box binaries; you can make real and substantive changes to the software so that it matches you needs.  Obviously this requires some knowledge of what you're doing, but my point again is that it's possible at all, where with closed source it's simply not.

For instance, if I'm working with a WordPress or Movable Type plugin that isn't quite doing the job, the former is written in PHP and the latter in Perl.  Since PHP and Perl scripts are totally hackable by the end user, there's a much greater depth to the changes that can be made, either by myself or by a knowledgeable third party.  In fact, this happened to me just the other week, where I did a bit of quick-and-dirty hacking on a MT plugin to get it to work properly with some federated ID components I was also using.

Again, naturally, all of this is going to revolve around how much expertise you're bringing to the table.  My knowledge of Perl is still pretty limited, but I'm a fast learner, and most of the changes I need to make are not huge.  But it's a far better situation than being stuck with a totally closed-ended application where one of the support options amounts to "Suck it up."