4 ms·

> nobody would pay for support That is really, really not the case. You don't pay for someone holding your hand. You pay for support because you either simply

> nobody would pay for support That is really, really not the case. You don't pay for someone holding your hand. You pay for support because you either simply have the resources to do so or your business requires you to pay for the things you use. If you need help setting up Kubernetes, glusterfs or something else you get help from a third party contractor. That's what we do. You pay for support because your want someone to keep sending out security patches even if upstream should roll over, and you pay for Red Hat specifically because you want to have an upgrade schedule your business can adhere to (as opposed to when upstream feels like it). Put another way, you pay for the privilege of having someone to sue.

AzMoo_ 8y ago
You also pay for support so that when your senior engineers all pack up and start their own business together you can ring somebody to keep your infrastructure running while you find more people with the right level of knowledge.
- kikoreis 8y ago
  Except that's not really what break-fix support covers. Specifically, support doesn't typically touch your infrastructure; it provides advice, documentation and patches which a local team needs to actually implement.
  - AzMoo_ 8y ago
    Advice is the key here. If you're in a situation where literally your entire team goes then you've probably got bigger problems, but when you lose some key people having professional support available to guide your juniors is beyond useful.
TuringNYC 8y ago
>> you pay for support because you either simply have the resources to do so or your business requires you to pay for the things you use. A nuance: many big businesses require that you pay for software you use, and part of what you are paying for is an indemnification via the vendor, which makes sense to purchase for big businesses with deep pockets https://www.scl.org/articles/3030-indemnity-and-limitation-of-liability-provisions-in-software-product-licensing-contracts https://www.scl.org/articles/3030-indemnity-and-limitation-o...
vmh1928 8y ago
Companies also pay for support because after a few years the version of the open source product has moved on and nobody realizes the true cost of ownership does not end with the acquisition cost the company doesn't have the budget to upgrade. Thus they're 5 levels back and nobody in the Open Source community is interested in fixing old software. As an example, RedHat offers up to 9 years of support for Openshift. That's why companies pay for support. https://www.ibm.com/support/knowledgecenter/en/SSC623_11.7.0/com.ibm.nex.optimz.tdm.doc/topics/productoverview_tdm_z.html https://www.ibm.com/support/knowledgecenter/en/SSC623_11.7.0... edit: clarified acronym
- gaius 8y ago
  Exactly this. A dev comes all bright-eyed and bushy-tailed and says we can save a week on the project if we use this open source library instead of writing it ourselves. But he or she doesn't see that they are committing the organisation for the lifetime of the project for someone to keep on top of patches, resolve any breaking API changes, even fully maintain it if the original developer loses interest - or ditching it and writing our own anyway. There is a lot of great open source around, but it is by no means "free" when you look at the big picture. This is one of the key differences that marks a senior from a junior engineer. You can see the junior's eyes glaze over when you try to explain it and you know they'll be back next week begging to use something else they read about on Twitter or HN...

AzMoo_ 8y ago

You also pay for support so that when your senior engineers all pack up and start their own business together you can ring somebody to keep your infrastructure running while you find more people with the right level of knowledge.

kikoreis 8y ago
Except that's not really what break-fix support covers. Specifically, support doesn't typically touch your infrastructure; it provides advice, documentation and patches which a local team needs to actually implement.
- AzMoo_ 8y ago
  Advice is the key here. If you're in a situation where literally your entire team goes then you've probably got bigger problems, but when you lose some key people having professional support available to guide your juniors is beyond useful.

TuringNYC 8y ago

>> you pay for support because you either simply have the resources to do so or your business requires you to pay for the things you use. A nuance: many big businesses require that you pay for software you use, and part of what you are paying for is an indemnification via the vendor, which makes sense to purchase for big businesses with deep pockets https://www.scl.org/articles/3030-indemnity-and-limitation-of-liability-provisions-in-software-product-licensing-contracts https://www.scl.org/articles/3030-indemnity-and-limitation-o...

vmh1928 8y ago

Companies also pay for support because after a few years the version of the open source product has moved on and nobody realizes the true cost of ownership does not end with the acquisition cost the company doesn't have the budget to upgrade. Thus they're 5 levels back and nobody in the Open Source community is interested in fixing old software. As an example, RedHat offers up to 9 years of support for Openshift. That's why companies pay for support. https://www.ibm.com/support/knowledgecenter/en/SSC623_11.7.0/com.ibm.nex.optimz.tdm.doc/topics/productoverview_tdm_z.html https://www.ibm.com/support/knowledgecenter/en/SSC623_11.7.0... edit: clarified acronym

gaius 8y ago
Exactly this. A dev comes all bright-eyed and bushy-tailed and says we can save a week on the project if we use this open source library instead of writing it ourselves. But he or she doesn't see that they are committing the organisation for the lifetime of the project for someone to keep on top of patches, resolve any breaking API changes, even fully maintain it if the original developer loses interest - or ditching it and writing our own anyway. There is a lot of great open source around, but it is by no means "free" when you look at the big picture. This is one of the key differences that marks a senior from a junior engineer. You can see the junior's eyes glaze over when you try to explain it and you know they'll be back next week begging to use something else they read about on Twitter or HN...