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

[bestan]

Millions of open source projects don’t have a vendor that provides commercial support (i.e. RedHat). The best support comes from developers who built the software (project maintainers), and many of them need funding.

What is the best way of connecting them? Would companies pay for support from project maintainers to improve quality and speed of their development? Would they prefer support contracts or on-demand support based on developer’s hourly rate?

I’d like to get a deeper understanding of requirements that businesses have. Any insight is very appreciated!

[exelius]

I work with many big companies that use open source software, and the answer (as usual) is it depends.

If we're talking about a well-understood open source product like Apache -- probably not. Most companies will just have people on staff who understand those tools very, very well. Same goes for libraries (or really anything in the software dev toolchain). If the codebase is small enough for a single developer to understand reasonably quickly, there's no value in support.

But if we're talking something like a database server or operational software -- absolutely. You want an expert you can call who will help you fix your problem within a certain amount of time (SLA). Customers really only need support for production outages: assume your customers are at least as smart as you are, and given enough time they can figure their problem out. But they don't have time, which is why they want to be able to call you.

[vonnik]

I'm part of an open-source project commercially supporting two main libraries, a deep-learning framework, Deeplearning4j -- http://deeplearning4j.org -- and a scientific computing library, ND4J (Numpy for Java), to power it. http://nd4j.org.

The amount of support companies are willing to pay for depends on how much they need the open-source library, and how complex it is.

There is a perverse incentive, of course, for some open-source projects to become overly complex so that users will end up having to pay them. A certain large open-source e-commerce platform comes to mind...

Companies can and do pay project maintainers for support and additional features all the time. We see this in the world of Java-based scientific computing, for example. I think you'll find that Java projects, because of their role in enterprise software, are more likely to become commercial than others.

Most open-source projects have enterprise distributions that vendors commercially support, like RHEL or CDH4... Those distros often include additional features. In Red Hat's case, they added a security layer that was a compelling value prop. In Cloudera's case, they often include supplementary packages like a management layer.

Support contracts usually indicate that there's a lot of demand and a company large enough to serve that demand. Hourly fees tend to correlate with a sole maintainer, and they can be very high.

[sytse]

At GitLab we see a lot of customers that need 24/7 support because our application is central to their delivery pipeline. In the beginning we had a lot of consulting engagements too to perform upgrades. As GitLab became better and the upgrades easier there was a shift to organizations paying for features in the form of GitLab Enterprise Edition.

[modoc]

One data point: What we use our open source commercial support contracts for, and what we'd love to have offered by more open source packages, is 24x7 emergency support and break-fix diagnostics and patches.

When a big website running on JBoss starts falling over at 2 AM, and initial triage points to JBoss, being able to get a Redhat engineer involved immediately and get a custom hotfix created if needed, is worth the money we pay.

The problem with this model for a lot of the smaller open source projects is they aren't setup or staffed to be able to provide effective 24x7x365 support.

[yardie]

It depends. I've paid for a support contract for our frontline loadbalancer (loadbalancer.org). It's too essential to our operation to be down for any extended amount of time.

We have many other OSS applications that don't need that level of response. If I can't fix it or tweak it myself I'll pay the developer or the consultant to do it for me.

[mindcrime]

The answer, as always, is "it depends". Certainly many companies desire to pay for commercial support for many OSS projects, but by the same token, it's obvious that there are some projects that nobody is paying for support for.

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.

[ShakataGaNai]

In my experience (and depending on the cost/product) a lot of open source commercial support gets bought for "peace of mind". The larger the organization, the more the higher powers want to be able to say "We've got vendor support" to assure everyone around them that everything will be "OK". The trench workers end up wanting the same vendor support, not because they think they need it, but because it gives them someone to blame if everyone goes sideways.

In the past I've paid for pfSense gold because it was only $100/year and it made my bosses feel more secure. We never needed it, never used it, but everyone slept better. Of course, that also goes back to how important the product is (which others have mentioned). If you're talking about support for OpenOffice (or whatever it's called these days) the likelihood of that getting bought is minimal.

[eldavido]

This is one of those classic "caught in the middle" problems. Small companies won't be able to afford decent support contracts, big companies will vertically integrate by developing/hiring in-house expertise.

The last place I worked was a medium-sized software company (60 people, $xx mil ARR) and we paid about $8k/month for MongoDB's enterprise support (generally quite good) as well as for AWS Enterprise support, which provided faster escalations when getting limits raised (EBS sizes/counts, EC2 instance counts, etc), as well as advance notice of upcoming features and architectural guidance on building our app. I probably wouldn't pay for AWS's service again, to be honest it feels like Amazon built it because bigco enterprise wants to pay for support, whatever diagnosis they did invariably pointed right back at our own configuration/operational error when dealing with AWS (gotta love those security group rules...)

I've long wanted a service where we could sponsor roadmap items for open-source projects. Not sure how putting $ into the equation would interact with an existing open-source product roadmap, but it's de facto what happens today, when fb/yahoo/etc. staff projects with their own developers, who they pay to develop features relevant to their own businesses.

[benwerd]

In my experience a lot of firms don't necessarily want direct support - but they may want an SLA.

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.

[Domenic_S]

There be dragons.

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.

[bliti]

I explored this not too long ago. The basic gist was to offer a managed service that did everything for small businesses (run, host, update, upgrade open source software) for a low monthly price. The technical side was simple. Using docker on top of amazon servers to run whatever software was needed. But I was unable to sell it properly. Dunno where I failed. I moved on. :)

[fijal]

I'm running a small company supporting pypy (baroquesoftware.com). I would love to somehow outsource the bizdev for my projects.

[andrewsyoung]

Has anybody looked at BountySource.com? Seems like an interesting model for funding targeted features / bug fixes in oss.

[mindcrime]

They have a new feature called "Salt" which is based around generating recurring crowd-funded revenue for OSS projects. We have been looking into the possibility of giving it a spin, but haven't committed yet. But yeah, it definitely looks interesting.