Ask HN: Do companies need commercial support for open source software?

OS support is either so bad it's not worth the cost, or so good it makes your in-house crew look incompetent and so the advice is thrown out the window in the interest of protecting silos.

There could be a market for on-demand support, perhaps. Get a marketplace of engineers with very deep knowledge of a bunch of domains, and price them as 24x7 support for some crazy amount of money.

Practical problems in enterprise: on-demand engineers will have 0 access to the client network and won't anytime soon without a full onboarding process, destroying the nature of the "fix this quick" benefit. Spending decisions go up a long and slow tree.

The nature of the open source market has changed, and I've found that most people conflate free as in speech with free as in beer. As a result, people are picking up open source projects specifically because there's no cost involved, making support - or any kind of license or subscription - a very tough sell.

The only predictable way of selling services on top of an open project I've found has been to hold a piece back and make it commercial, which I think cuts against the principle of the thing. Nonetheless, eating and paying rent are important, so that's the way it goes.

One-off customizations are another matter, but the expectation is that because you gave away your code to begin with, you're going to work for a below-market hourly rate.

Disclosure: I've cofounded two end-user open source projects (elgg.org and withknown.com). At this point I could not be more jaded. It's possible the dynamics are different for infrastructure projects, but the state of OpenSSL et al suggest not.

In my experience, when companies pay for commercial support, it's ultimately about paying for the comfort factor of knowing that somebody is "on the hook" to fix things if the shit hit the fan. There's a certain level of "CYA" in there as well. If you approve a project using an unsupported OSS project, and it falls over, and the company loses money, then you may suffer some serious repurcusions. OTOH, if their is a vendor behind the product, and they are called in the fix the problem -- and even if the company still loses money -- the vendor absorbs the blame.

Like others have said though, it depends on how complex the software is, what it does, whether or not the firm has deep knowledge of the product already on staff, etc.

Beyond that, a few more thoughts: subscriptions for OSS software, ala the way Red Hat work, are desirable in many ways. For example, with a subscription, you know you always get the latest version as long as your subscription is up to date, so no "big bucks" version upgrades are required. You're also paying with future, inflated, dollars as opposed to todays dollars which are more valuable (assuming the economy doesn't go delfationary). It also aligns incentives between the vendor and the customer, as the vendor has to continue to provide a solid, functional, operational product, for the company to keep renewing their subscription.

Of course all that's true even if the software is proprietary, but the subscription model seems really popular for OSS stuff.