When open source software is talked up in the enterprise, one of the debates falls along these lines:
"Open source is free - no licensing costs"
"But there's no support, either"
"The mailing list and forums are very active"
"We don't have a way to
make them help us"
"Our vendor support sucks"
"So does your momma"
The support question, i.e., how to get quality support for an open source application, is a valid question. Sure, the source is available, but then you have to ramp up on the source, and if you modify it, managing a fork.
It is true that the quality of support for any application, proprietary or open source, is uneven. You really don't know what you're going to get. The "nice" thing about proprietary software is that there is has been a readily quantifiable measurement for how effective the support "should" be: how much you are paying.
With some exceptions, the open source model doesn't offer the same so-called assurance. In typical enterprise binary fashion, since you can't pay for support, support isn't available.
The misconception for open source first-timers is that they should be able to post to a mailing list, and get a good reply. Heh. Let's just say that first impressions can be varied.
Support in the open source world isn't purchased with money, it is purchased with credibility. For a large chunk of the open source world, it is very much about community, and credibility is the only currency that any community respects.
There's a flip side to support for proprietary software, too. Once you
stop paying for support, you stop getting it, just as quickly. The investment in a community is cumulative and durable; the more you participate, the more you benefit, and the longer you benefit. Look at IBM: from considered as evil as Microsoft to "not so bad".
Contributers to open source projects get more respect from the community. This doesn't necessarily mean contributing source, although that is significant. Writing documentation, being an active helper in the forums, contributing hardware, and outright donations are all valid means of building one's reputation.
It doesn't even need to be for the same project for which you are asking help. The more active your organization is the overall community, the more credibility you have across open source projects.
The hard part about this is that there's no real faking it. You can buy immediate attention from a community, but maximum effectiveness requires regular participation over time. Not just the big things, the little things. You really have to be a part of the community for the community to be effective.
Okay, so how should your typical enterprise go about this?
Well, first commit to a long-time goal, and recognize from the very beginning that the effect will be hard to quantify. It is a lot like marketing, and in fact, it may be appropriate to involve marketing (but not too much).
Pick an open source project in which to participate. The size of the project doesn't matter, although there will be an optimum proportion of project size and influence within that project (if you can make major contributions to the Linux kernel, the payoff is significant). Better yet, take over a "stale", but still useful project.
Hire somebody to act as the "face" of your company. It isn't enough to say that "Bob will take care of it in his spare time", it has to be part of the job description. If there isn't much going on, it would be "Bob's" job to make something happen. They should be able to write to a technical audience.
Then, participate!
Actually participate, no fakeys. Treat the members of the project as what they are: a part of your world. You may not control them, but that isn't necessary for them to contribute to your own success.