Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Businesses Linux

Ask Slashdot: Paying For Linux Support vs. Rolling Your Own? 118

Posted by Soulskill from the how-to-train-your-penguin dept.
schmaustech writes: A lot of businesses pay for Linux support. But at what point does that stop being worth the money? When would a company be better served by setting up their own internal support? When does it make sense for them to write their own patches, which could be submitted back to the community? The inherit risk is that the organization is accountable and accepts the risks if a major bug is encountered within any of the open source applications they are using. What's your perspective on this, and how many major corporations are taking this approach?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Paying For Linux Support vs. Rolling Your Own? More

Ask Slashdot: Paying For Linux Support vs. Rolling Your Own?

Comments Filter:

  • In my experience (Score:5, Interesting)

    by dreamchaser ( 49529 ) on Saturday December 06, 2014 @04:45PM (#48539413) Homepage Journal

    I work with clients ranging from small business to Fortune 10 companies. On the SMB side most do support their own, though they rarely write patches. I don't know a single large enterprise using Linux that doesn't pay RedHat or whoever for support though. There are many reasons for that. SLAs are easier to hold a third party to than an internal organization. It makes the C level people feel better to have a company they are paying accountable for support. They do not have to carry the burden of the extra staff needed (that's a big one). The list goes on.

    • Re: (Score:1)

      by Anonymous Coward

      They do not have to carry the burden of the extra staff needed

      This is nonsense. It takes local admins who know the setup to get any fix working.

      • When did I say they didn't have local admins? That is a far cry from doing all of your support without a safety net.

    • Is it a question of extra staff for a large organization or the right technical talent and paying for it? I know CERN does not use support and they have a fairly large publicly known OpenStack environment. However there seems to be this idea that if it is research or academia it does not count toward a true production environment.
      • Doesn't CERN - along w/ Fermi - maintain their own distro - Scientific Linux? Since it's a spin-off off RHEL, they must have some personnel to maintain that distro, and keep checking with RHEL?

      • CERN and the like are probably an exception because they are so high profile/budget but the thing is with most academia: who really cares if your cluster is down for a week? So you have to work through the holidays to get your thesis done, or you hire another intern at $10/hr to maintain things etc. Most people are working for really low salaries and putting in way more than 40hr work weeks. It is hard to justify borrowing staff from your contractor when you can get your own people so cheaply. Instead you c

    • Re: (Score:1)

      by Anonymous Coward

      RedHat support is excellent; However you have to know how to use it. You will send a problem. They will always send some questions. You must be able to and ensure that you do answer them. When you do that clearly they will be able to fix almost anything. AC who says "It takes local admins who know the setup to get any fix working" is of course right but is missing the point. For a big scale system you should count the cost of a RedHat TAM, either by getting one or by spending the same on your own adm

      • Re: (Score:1)

        by Anonymous Coward
        I would disagree with that statement. Our TAM lacks the product knowledge in our environment and support seems to take weeks to get bugs fixed in the code. I often feel Redhat is relying on the community to provide fixes.

        • Red Hat gives good support, but it takes time. The optimum answer is to have your own support staff and to be able to escalate serious problems to your vendor, but that's not cheap.

    • Re: (Score:1)

      by Anonymous Coward

      Large companies don't want the risk and it's also hugely expensive having staff in some locations. London is something like £200k / year for an IT guy (say a bank for office/Salary/pension/support/etc). So if you are in London that £1 million+ for RedHat support doesn't look that bad. You could have 5-6 people internally and hope they know everything from C kernel coding, why Java crashes on a specific kernel through to how to configure SSL on Apache. You know RedHat has someone, if you can get

    • Re: (Score:1, Insightful)

      by Foofoobar ( 318279 )
      The silly thing is... they NEVER hold these companies accountable. When have you ever heard Microsoft pushing a patch for Windows early or an extra update merely because a customer was 'upset'. And Redhat is actually pretty bad about support; they only support a VERY SMALL set of very old releases (vs Ubuntu which keeps their releases pretty up to date). The excuse is 'it might break something' which is a pile of BS since it wouldn't be in the core supported repo. I would laugh if companies actually DID ho

      • Re:In my experience (Score:5, Interesting)

        by elbles ( 516589 ) on Saturday December 06, 2014 @06:03PM (#48539735)
        We were having a problem with a "no IRQ handler for vector" issue that was crippling networking on a lot of HP DL360G7 systems we had. We were running CentOS on some of these systems, and RHEL on others, and though we never reached out to Red Hat ourselves.

        Red Hat had a bug open for it (bug 887006 if I recall correctly), and it was interesting to see what their response was to paying customers. They did provide special kernel packages to help fix/troubleshoot the issue, but it still went on for a long time. To make matters even worse, even when the bug was visible to me (as a Red Hat customer), lots of it was redacted, to the point where it was difficult to determine key pieces of information. And while I don't have access to my RHN login right now, I don't believe that bug is accessible to anyone outside of Red Hat at this point (which is another problem itself)

        I suppose my point is even in circumstances where you can hold the vendor responsible and where they are taking action, it doesn't guarantee that the problem will be fixed when The Business(TM) wants it to be. And for problems like this, where it's affecting or going to affect a large number of people, it'll get the proper attention it needs, paid support or not.

        I get paying for support from a CYA perspective, but that's really all it is, IMHO.

        • Re:In my experience (Score:5, Insightful)

          by houstonbofh ( 602064 ) on Saturday December 06, 2014 @07:29PM (#48540025)
          The fact that "Support != Solution" is a painfull lesson for many.

        • Re: (Score:2)

          by CBravo ( 35450 )
          That should teach you to not buy HP (or Dell) anymore. Buy normal motherboards that are not created by companies with non-standard ideas on creating hardware.

          We no longer buy brand computers but have them assembled by our specs. We do not buy support, nor do we have SLAs. We do have enough people who understand and can solve operational issues (i.e. 5). We do tend to replace more stuff that fails to work when updated or has operational issues (like network cards that freeze when under full load, that is

          • Re: (Score:1)

            by elbles ( 516589 )
            To be fair, if I remember correctly, the problem was with hardware provided by Intel, and could be worked around by a BIOS update (supposedly), but it would have affected a white box as much as it would a Dell or HP.

            There are plenty of arguments for using white boxes or boxes from big brands, but this was wasn't one of them.

      • The silly thing is... they NEVER hold these companies accountable.

        Define accountable? Your support contract outlines what can be expected. You have problems, they try to resolve the problems. That's one kind of accountable. Outage causes millions in losses? That's a different accountable, and they legally will fight any attempt to collect on that. If you pay for support, and never hold them "accountable" i.e. never contact support, then that's stupid.

        When have you ever heard Microsoft pushing a patch

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      I work for a company with probably 150k employees. I'm guessing total staff approaches half a milllion if you count the onsite contractors.

      I would be horrified if they brought the linux support in-house. That's not our job. We have a very specific job, and working on linux is not it. *Using* linux is definitely it, but but developing it would be a huge distraction.

      I've been using Slackware at home since 1996. The company I work for has thousands of Suse boxes, but the company I work for makes luxury goods,

    • they also do it for legal protection.
      and they generaly deploy commercial software that is only certifified on enterprise Linux editions. so most companies can't roll their own even if they wanted to. and if you look at cost of the os license, it is nothing compared to the commercial sw last licenses.
      and it is not just about rolling patches.
      in a crisis, they need to be able to lean on a vendor.

      • A lot of people minuderstand this, and make up nonsense about "being able to sue somebody if something goes wrong," which of course they can't.

        Others make the mistake of thinking support = solved problems.

        Corporate support means documentation that proves you Did Everything Reasonable and according to Professional Standards.

        Small or privately owned shops don't need that, and don't even know why other people do need it, so you get a lot of know-it-alls on here hooking their thumbs in their suspenders yacking

  • Linux Support is Rarely Worth The Money (Score:2)

    by Anonymous Coward

    I work in pretty homogenous networking environment: Linux, BSD, Windows, Mac. I NEVER, EVER call for support, even if I work for a place that has paid for it. Why you ask? Pillars of intransigence is why. All vendors, to a man, do their best to give you the least. I've found that by understanding the problem, using Google, and pinging others in the shop, we can usually figure out the most complex stuff within a day or two. Linux support is for shops with people who don't really understand Linux at all. Linu

  • It really doesn't make sense for large organizations who are supporting mission critical apps. There probably aren't any managers on the planet who will willingly make the decision to support it themselves because one critical issue and it's their job. Instead, they'd much rather have a 3rd party to strangle if and when they have a critical issue

    • Re: (Score:1)

      by Anonymous Coward

      Exactly this, and also, if it were brought in-house, eventually someone would notice how rarely the staff is used for mission critical stuff and they'd be assigned other responsibilities in addition and then when there was a real problem, there'd be a political fight.

    • Re: (Score:3)

      by dbIII ( 701233 )

      they'd much rather have a 3rd party to strangle if and when they have a critical issue

      However when you have goals other than giving your lawyers something to do it's not so clear cut.

      • Your lawyers will advise you that you can't really sue software vendors when you're mad at them. Bugs happen. Having somebody to "strangle" means "having somebody outside the company to blame when talking to your own boss." That is all it means.

        And of course, lots of companies do have a different management dynamic than that.

  • "The inherit risk is that the organization is accountable and accepts the risks if a major bug is encountered within any of the open source applications they are using. "

    There's no liability for patches (except for intentionally malicious ones) to an open source application. If there were, nobody would submit one.

    • Re:Risk? (Score:5, Insightful)

      by Kjella ( 173770 ) on Saturday December 06, 2014 @04:56PM (#48539459) Homepage

      There's no liability for patches (except for intentionally malicious ones) to an open source application. If there were, nobody would submit one.

      In this context I think it means "nobody to pass the buck to", if Windows crashes you blame Microsoft, if RHEL crashes you blame Red Hat, if CentOS crashes you take the blame. Then again my impression is that very, very few have the kind of ultra-platinum support where the vendor will jump all over you to solve your problem, it's mostly your problem to solve anyway. It's just a blame shifting exercise, how badly you need it depends on how much shit is going to roll downhill. The technical merits of support is often secondary.

  • Stupid question (Score:1, Insightful)

    by Anonymous Coward

    Run the numbers for your particular business, dumb dumb, and stop asking for vague, qualitative, subjective responses to validate your biases.

  • inherit risk? (Score:3)

    by quickOnTheUptake ( 1450889 ) on Saturday December 06, 2014 @05:01PM (#48539475)
    Seriously? Who TF is editing this?

    • Re: (Score:1)

      by Anonymous Coward

      Seriously? Who TF is editing this?

      From where it says, "Posted by Soulskill," I'd say that it's either Soulskill or no one.

      I'm leaning towards no one. Hey, you have to expect to inherit some risk.

    • It was likely voted in or some other means. Not all submissions go straight to front page. It is a slow day, so why not have group discussion to kill the time until we really have something to talk about.

    • Seriously? Who TF is editing this?

      Inherit risk is defined as the risk of manifold deleterious effects on an online community after it is acquired by some crappy company whose goal is to "monetize" the "audience".

  • Linux support (Score:4, Informative)

    by Lando ( 9348 ) <lando2+slashNO@SPAMgmail.com> on Saturday December 06, 2014 @05:02PM (#48539481) Homepage Journal

    To maintain and support an entire OS takes a lot of work. We aren't talking about just development here, but checking to make sure things run properly and making the changes needed to ensure stuff is supporter. The point I would start looking at rolling your own distribution and supporting it is the day you decide to start selling your distribution.

    For internal use, sure you might have to have a team to do internal work to modify certain sections in order to make the OS work for you, but they are relatively minor compared to ensuring an entire distribution works as needed. Let another company do the heavy lifting and just have your company modify it and submit changes back through the system as desired. Feedback works as well.

    To run an entire distribution and all the subsystems takes billions, look at IBM donating to Linux as a whole they give value back to the community rather than trying to extend and embrace for their own purposes. Redhat does the same and they do distribution and sales. Other companies are the same. I guess you can make the decision on your own but personally I suppose the time to switch is when you have support fees in excess of what it would cost to maintain an entire distribution. I'd assume someone around a thousand people focused on the project would be about right. A thousand people's salaries would buy a lot of support. A better idea might be to hire developers for the subsections of the OS that you need and have them work with the community.

  • The college I work for (not in IT but in academic technology) has a support contract with IBM for Linux on the p-series boxes that have replaced the mainframe and zVM. Needed too due to some network issues.... Of course, since there was a support contract for the mainframe, not much has changed as far as the bean counters are concerned.... Note that while they use RedHat on some x86/amd64 boxes, they don't have a special support contract for those - just for the "new mainframe replacement systems".

  • For IBM, yes. They do, but only for the parts they support. They buy support for the rest.
    I work for a software manufacturer. We internally support the libs that we ship with our products. Usually this just means getting the latest source drops and building them. When there's been a problem we could solve it in our code, but being able to debug into the lib code was the only way to find it.
    For major system components, and packages that aren't part of our product, we buy support.
    For the average compa
  • The only issue is that certain employees have the knowledge and should something happen to them, the business may be in trouble. By paying for support, you place the burden on an entity, which is responsible. It all comes down to question for CIO/etc if they should lose an employee, how will that impact the business.

  • Shoemaker, stick to your last. (Score:3)

    by westlake ( 615356 ) on Saturday December 06, 2014 @05:38PM (#48539631)

    A lot of businesses pay for Linux support. But at what point does that stop being worth the money? When would a company be better served by setting up their own internal support? When does it make sense for them to write their own patches, which could be submitted back to the community?

    The core competence of most businesses does not lie in the internals of an operating system.

    It can make perfect sense as well to "outsource" clerical work to Microsoft and Office 365, accounting to specialists in corporate accounting, and so on.

    Contributions to open source that build on a deep investment in what you are really, really, good at, and perhaps better at than anyone else in the world, are far more likely to be enduring and influential.

    Open Source [disneyanimation.com]

  • skilled staff in this area are expensive, it is almost never cost effective to do your own support. The exceptions maybe if you have some very niche requirements that make paid support difficult, but for the average business small or even large enterprise it doesn't make sense, a support contract is far cheaper than the staff needed to do it yourself.

  • The inherit risk

    The inherent risk

  • 1) Many hardware vendors, especially storage, will give you trouble or refuse to support their gear if you're running an OS they don't bless

    2) It can make business continuity easier; you'll find more people who claim RHEL/CentOS support than Debian (though Ubuntu is pretty wide-spread these days).

    The rest are pretty minor. Some C level tools want to feel like they're magically protected by vendor support.

    The reality is I've pretty much always had to do my own diagnostics, RCA and come up with a resolution.

  • I don't think your perspective on this is right. There is no hard cut-off between fully depending on support an doing everything yourself. At the very least you will need someone to talk with support. You will always have someone who is acting as an administrator and who will solve problems. Sooner or later you are going to run into problems that can be fixed without support. If you don't want to keep fixing the same problem over and over you are better of sending the fix upstream. With or without the help

  • Ask yourself: What is our business model? (Score:4, Informative)

    by msobkow ( 48369 ) on Saturday December 06, 2014 @06:48PM (#48539877) Homepage Journal

    You're asking the wrong question. The question is "what is our business?".

    If it's not your business, you hire experts to take care of it.

    My guess is "producing a Linux distribution" isn't in your business model.

    • Re: (Score:2)

      by Kjella ( 173770 )

      Unfortunately that question should be split in two, "Where do we add value?" and "What is essential to be able to deliver that value?" I've seen quite a few cases where I feel they've signed away too much of their processes that aren't core business but is ruining it because it's not working well. Outsourcing development is an easy example, the core business is usually serving some particular market or function, not developing software as such. But no matter how much smart business functionality you've adde

      • Re: (Score:3)

        by CBravo ( 35450 )
        The question should be: What are the risks and how do we keep them in balance (by maintaining control).

  • I Highly Recommend Paid Support (Score:3)

    by theManInTheYellowHat ( 451261 ) on Saturday December 06, 2014 @07:10PM (#48539949)

    I have managed Linux servers in a professional environment for 20 years and for "production" environments I highly recommend paying for support.

    I have had the good fortune of getting a tech on the phone to handle issues that were solved by the people that know the software the best. Red Hat and SUSE both employ top notch support folks. I have not experienced any others, I would expect they are also quite good. Talking to another tech on the phone that you can trust is totally worth it to you and the business that you are working for.

    Contrast that with hoping that someone has had the problem you are trying to solve and has solved it and has posted to a forum you search is just not the route to go. In my opinion, you should not allow a business to make this choice. It is insurance and not a guarantee of success but that is why the business pays for it and other types of insurance.

    Also these paid support contracts help fund the open source world and are, again in my opinion, the responsibility of a business using open source software.

  • Risks (Score:3)

    by thecombatwombat ( 571826 ) on Saturday December 06, 2014 @08:34PM (#48540289)

    "The inherit (sic, seriously editors?) risk is that the organization is accountable and accepts the risks if a major bug is encountered within any of the open source applications they are using."

    I'm always surprised by this being raised as a contrast to proprietary software. As pretty much anyone who has ever relied on proprietary software for their business and had that threatened by a major bug will tell you, there's no magical protection brought about by the license agreement being closed source. I've created massive complex workarounds for bugs in software we were paying tens of thousands of dollars while waiting literally years for the vendor to acknowledge the issue, let alone fix it. I won't call out my specific employers or vendors, but I can't help but assume a lack of experience on the part of the writer when I read something like that.

    In my experienced opinion the best scenario to stake your business on is open software with strong commercial backing. That way when something goes wrong, you've got a third party with incentive to help you, a community of eyes, and access to fix it yourself.

    • So in fairness I realize I started to respond to this, got distracted, came back and did not exactly respond to the question being asked.

      I stand by part of what I said though "support" is not magical, a combination of both is what's desired. It's best to have both your own in house people and external sources with a commercial interest you can fall back on. There's no substitute for internal knowledge though. Staff that knows how your apps interact with your systems, with your usage patterns.

      My point in bot

  • In most companies the question is not whether they do or don't pay for support but rather what systems are supported to what level. No company has the technical depth to deal with the entire Linux stack, with the possible exception of IBM. Low criticality systems can have problems but because they are low criticality the company has time to find resolution so they tolerate greater levels of mistakes in exchange for lower costs. As you get closer to the center support becomes more important because they w

  • how many major corporations are taking this approach?

    I can think of a few companies that support Linux in-house. In no particular order: Red Hat, Novell, Canonical, Oracle, Google. I'm sure there are others.

  • It's pretty much the same as insurance. (Score:3)

    by BlindRobin ( 768267 ) on Sunday December 07, 2014 @05:42AM (#48541641)

    Tis question is not exactly but largely analogous to the question : 'Do we self insure or purchase insurance'? The risk evaluation is complex and the answer is dependant on the a number of weighty factors not least of which is the amount of liquid assets available to address a catastrophic failure. Hire a risk analyst.

  • "The inherit risk is that the organization is accountable and accepts the risks if a major bug is encountered within any of the open source applications they are using".

    In order to use the software, the end user must accept the license, which in no-way-shape-or-form makes the organization accountable for any such defects.

    Limitation of Liability. [gnu.org]

    "In no event unless required by applicable law or agreed to in writing will any copyright holder, or any other party who modifies and/or conveys the program
  • When I first started out my business I had a shoestring budget, if that. I could not afford conventional Microsoft software like the OS and office suite, anti virus, graphics design software, accounting software and so on. GNU/Linux seemed the best route to go. However, I knew very little about GNU/Linux either. For a small fee, I paid for GNU/Linux support and had someone there to hand hold me through crucial moments when I did not have time to research problems on my own or when I got stumped by a bug. It

  • Shouldn't this be a problem for a fifth grade economics class?

    When the cost of external support for n machines exceeds the cost of an in-house IT contractor, then it's time to shop around for a contractor. It's really that fucking simple!

  • This only makes sense if you have contributor(s) in house. And i mean the plural, because just having a kernel contributor in house is not enough.
    If this is not the case, don't even think about it.

  • They all would have been harder to fix if we didn't have Red Hat support. And because we had Red Hat support, it made explaining to our customers and vendors that we had patched the security holes so much simpler.

Slashdot Top Deals

Work is the crab grass in the lawn of life. -- Schulz

Close