Slashdot Mirror
Ask Slashdot: Paying For Linux Support vs. Rolling Your Own?
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?
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.
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. Linux networks, even machines running mostly Linux, is usually pretty easy to sort out with a little understanding of the issues. CentOS is popular largely because people can sort it out without paying the exorbitant costs associated with Red Hat support. I've used Red Hat support in the past. I don't plan on ever calling them again.
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
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.
Live today, because you never know what tomorrow brings
Seriously? Who TF is editing this?
Mod points: Guaranteed to remove your sense of humor.
Side effects may include gullibility and temporary retardation
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.
/* TODO: Spawn child process, interest child in technology, have child write a new sig */
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
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.
I do not fail; I succeed at finding out what does not work.
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.
Except there's support included when you get a Microsoft product. If you're beyond that and don't have a support contract, its $250 to pass the buck over to them if their shit goes kaboom on you.
Once, I was at a company where we ended up with a critical bug in SharePoint ( ::shudder::...that was a long time ago...) auditing.
After going through the support monkey, we eventually had something silly like 12 microsoft engineers and PMs on the line in a conference call debugging the issue with us a few times over a week. In the end they gave us a fixed up DLL, and things were good.
Net bill: ~$250 (give or take).
But if you actually read your license and EULA, it won't do any good.
It does when you are talking to your boss. "We bought support, but even they can't figure it out."
"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.
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.