Open source support stories: the same as closed source?

I’m working on a little post about the nature of “open source support.” What I mean here is support that’s paid for, i.e., the sort of support commercial open source companies provide.

While I’ve got a head, several mind-maps, and a post draft full of thoughts, I wanted to see if ya’ll, dear readers, had any stories about support you’ve used (as a “buyer”) and/or support you’ve provided (as a “seller”).

What I’m interested in is the type of support people are getting and providing.

Closed Source Support I’ve Provided

For example, reflecting on the type of support I provided for closed source software, we were often helping customers:

• Bugs – plain old bug discovery. The more ongoing support here was beyond the first discovery of the bug: creating a patch, and then providing that patch to others came across the bug. Of course, a large part of providing the bug to others was diagnosing that they had the problem.
• Scale the software – in IT management software, people were always trying to pump an ever growing amount of data at a faster rate into the system and…breaking it.
• Configure the software – enterprise software isn’t always the easiest thing to figure out how to setup, so we’d spent a lot of time simply telling the people how to use the software for their “business needs”…and, of course, how to fix the misuses they’d come to on their own.
• Upgrades – the more customized, complex, used (more data), and old any given install was, the more trouble upgrades would go. I’ve spent countless hours — probably days — trying to help people recover from failed upgrades.
• Finger pointing – perhaps the most frequent type of support I encountered was “prove to me that your software isn’t at fault” requests. Again, in IT management, this is a natural thing to get support for: IT management is (or can be) all about tracking problems in IT and then assigning blame for that problem, indicating who should fix it and get their act together to prevent the problem from occurring again. Thus, when the IT management software tells you that some server is down, and you (the customer) think the server is up, call up support and ask them to prove that your software is right (that the server is down).
• Re-setting expectations – closely akin to finger-pointing, and just about as frequent were support calls to (re-)educate the customer on what our software could actually do. That is, the customer/user would think the software could do much more than it actually did, found it didn’t do that, and call us up to get the bad news. In IT management, this often had to do with things like the granularity of historic data (we couldn’t give you ever 5 seconds of CPU ticks from 4 years ago) or scaling up the software.
• Your million dollar nightmare – there was a special class of support calls from what I like to call the “they paid us $10 million dollars so do whatever they want” customers. This was the nut of enterprise software for me. These support calls were always related to supporting non-standard features and usage of the software. When it came to non-standard features, we’d either provide custom patches or kick off a whole new requirement and feature for the next version of the software. The worse type of support we provided for the million dollar nightmares was supporting old, old versions of the software that we no longer “officially” supported.

So how’s about you?

I’m curious though what you, dear readers, have to say about support for open source. I suspect it’ll largely be the same, but I’m curious to hear instead of just suspecting.

An implicit question, of course, is what if any support you need beyond Google ;> I’m also interested in what kind of development time support people might use, that is, support when using open source for software development vs. running open source.

(Thanks to jdub for some answers already in #redmonk!)

Technorati Tags: support, enterprise