
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.<p>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?<p>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](http://deeplearning4j.org) \-- and a scientific
computing library, ND4J (Numpy for Java), to power it.
[http://nd4j.org](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.

