Now, I have some reservations about this process: in my experience not only (as Matthew points out) customers are interested in just a specific piece of the picture, but also it’s incredibly difficult to provide generic support. Middleware is nasty: without knowing how the different pieces have been glued together, what is the desired outcome and how are the different components cooperating, it’s just impossible to provide real second-level and above support. Unless you have trivial problems (tipically the ones that can be found with a “I feel lucky” Google search), it’s nearly impossible for a support person to nail the problem down and provide a solution.
So, how do you support Open Source middleware? Well, I can imagine two different ways: the first option is about providing what I’d call “stock” support. That is, on the other end of a phone line you have a smartish operator going through a knowledge base and trying to answer your questions. Basically it will be installation/upgrade issue, or generic questions that, once again, can probably be found on Google. The added value here is that the operator will answer you right away, is committed to solve your problem, can probably escalate the issue to more knowledgeable people and so on.
That’s a good start of course, and I can certainly see it happening for infrastructural software such as a web server. I wonder though how this process can solve a problem with your message-driven bean who all of a sudden doesn’t work anymore: at a very least you have to fly code back and forth, assuming that from small snippets taken out the real context the support team can figure out what’s going wrong. At a very least this requires that on the other side of the phone line there is a very knowledgeable person