How Can I Justify Using Red Hat When CentOS Exists? 666
Bocaj writes "I recently spec'd out a large project for our company that included software from Red Hat. It came back from the CIO with everything approved except I have to use CentOS. Why? Because 'it's free Red Hat.' Personally I really like the CentOS project because it puts enterprise class software in the hands of people who might not otherwise afford it. We are not those people. We have money. In fact, I questioned the decision by asking why the CIO was willing to spend money on another very similar project and not this one. The answer was 'because there is no free alternative.' I know this has come up before and I don't want to beat a dead horse, but this is still a very persistent issue. Our CIO is convinced that technical support for any product is worthless. He's willing to spend money on 'one-time' software purchases, but nothing that is an annual subscription. There is data to support that the Red Hat subscription is cheaper that many other up-front paid software products but not CentOS. The only thing it lacks is support, which the CIO doesn't want. Help?"
Support them from your own money (Score:4, Insightful)
The only thing it lacks is support, which the CIO doesn't want. Help?
Then you get CentOS and stop trying to spend other people's money on things they don't want to. If you care about Red Hat getting their support, then donate to them yourself, from your own money. Red Hat sells support service, and that is their product. Otherwise, it's just a compilation of others software, just like CentOS is. It's obvious your company doesn't need the support service so CentOS suits you just fine. Pushing an agenda down others throath doesn't help open source's image either. It should come from their own willingness to help or by providing so fantastic service that people actually want it.
Update & security responsiveness (Score:5, Insightful)
By and large the CentOS team do an excellent job with the distribution - but it's a volunteer effort and there have been some notable times lately when important or security updates which have been shipped by Red Hat run late with CentOS, sometimes by a considerable amount of time.
If the CIO wants CentOS over Red Hat, he also needs to be prepared to accept the risk of delayed updates, no guarantees to updates or bug fixes and that one annoying time a particular server suffers an obscure bug, there won't be a vendor to go back to for obtaining a resolution.
Still not Windows (Score:4, Insightful)
You are lucky your CIO is not wedded to Windows. Stop complaining.
Re:Support them from your own money (Score:5, Insightful)
Linux is free if your time is worthless. (Score:2, Insightful)
If your CIO believes his bench is strong enough to support CentOS without formal support (or using CentOS consultants instead of prepaying for RHEL), then he's making the right call.
Incidentally, I have very rarely gotten paid support for any software product that was anywhere near worth the price paid; support calls would typically devolve into blame games and shit would not get done until I got out strace or ethereal and could call folks out on their shit.
If your org does not have a strong linux bench or the linux stuff is not a core infrastructure component, or if your CIO manages via powerpoint and bullet points, then outsourcing linux skills to RH could make sense.
Give Em A Call (Score:5, Insightful)
Give Red Hat a call. Seriously, if their sales department can't justify it for you, it's not justified.
What does support mean? (Score:5, Insightful)
If you can't answer the question 'what does the support buy you?', then you can't answer this. Most of the time, when people talk about support at the enterprise level they mean adding features and fixing bugs that are important to the company paying the bills. Do you have the expertise in-house to do this? If so, then there is no advantage in Red Hat over CentOS (unless it means you can make some of your in-house people redundant). If not, then it has some value. If you can do it all in house, then do: that's the main economic advantage of Free Software, that you always have competition when it comes to providing support, you never have one vendor that is the only one that can fix the bugs that you care about.
If you can do it in house, then don't try to persuade your boss to let you pay Red Hat, persuade him to let you send any fixes or enhancements that your team makes to the relevant upstream projects. This is likely to be much more valuable to those projects than your handing over a pile of money to a third party.
Re:Support them from your own money (Score:5, Insightful)
The question is not how much support costs. The question is how much is DOWNTIME going to cost the company?
When you hit a problem your team can't solve what dollar value is that? Granted, for anything using a LAMP stack it is probably just as efficient to spin up a new server and start over versus a lot of money for support that isn't going to figure out all your custom stuff anyway.
I swear by IBM System i with IBM support. It's outrageously expensive, but they will call support engineers after hours when you have a problem level 2 can't handle. Microsoft's comparible offerings require a thousand seats.. IBM will sell you support for just one server.
In my case we have three steel mills worth $10k+ per hour of downtime... Even more if downtime causes rework. If we have more than an hour down I have vice presidents in my bosses office!
I suppose it's up to poster's boss, those C.I.O. Letters make it his decision... and his ass will be on the line when you have to explain why he didn't line up something to cover for things the minions can't handle.
Linux is free if you have a brain. (Score:5, Insightful)
Since ANY system you use will require that you learn SOMETHING about it your title is misleading.
The scenarios are:
1. Your people can already handle the task
2. Your people need to learn more and do so without additional expenses
3. Your people need to learn more and do so with additional expenses
4. Your people need to learn more and do NOT do so
5. You outsource the project and dump the scenarios onto the outsourcing company.
It doesn't matter which platform you choose. So Linux is still free (and Free like speech) as long as you have a brain and can learn.
Re:Update & security responsiveness (Score:5, Insightful)
Re:Give Em A Call (Score:5, Insightful)
Fair answer... but I'd say truthfully, the SALES department isn't really the group you want to rely on if you need an honest answer. It's their job to maximize sales, so you can expect them to sugar-coat a lot of things and exaggerate the usefulness and capabilities of whatever they're hawking.
They're not bad if YOU already know you want the product and want some more ideas to make a good case for it. But what I'm seeing here is a guy who seems concerned that businesses the size of the one he's in are "supposed" to be buying Red Hat to help support the project, yet they're opting out because they feel they can get by fine with a free alternative that wasn't necessarily made available with intentions of companies like his using it to bypass paying for Red Hat.
To that, I'd say -- no, Red Hat is a commercial business like any other. They're not a charity. The CIO may be the smart one here. I haven't had to work with Red Hat support before, but my workplace pays a lot of money out in support contracts that generally get very little real use. I think they pay for them primarily as a form of insurance, out of FEAR of what might go wrong in the future. Regardless, if I looked back for the last 5-6 years at all the maintenance/support agreements we own and tried to actually cost justify them based on incidents where we used them? Wow ... that would easily average out to several thousands dollars for each hour of time spent on the phone for support!
Re:What does support mean? (Score:4, Insightful)
If you can't answer the question 'what does the support buy you?', then you can't answer this. Most of the time, when people talk about support at the enterprise level they mean adding features and fixing bugs that are important to the company paying the bills. Do you have the expertise in-house to do this? If so, then there is no advantage in Red Hat over CentOS (unless it means you can make some of your in-house people redundant).
The real question is: Have you ever used your fire insurance? If no, do you think it would be a good idea to drop it? I'd call it excessive if you used it even once a decade. Most companies I know really have support because they can't afford to have a big staff waiting around for shit to hit the fan, but if shit hits the fan they can't afford extended downtime. What if your main man is on vacation or hospitalized or just left the company? The minor features and bugs that get fixed might be perks but that's not really why they're paying. And that's why the CIO's suggestion might work fine this year. And next year. And the year after that. But when your production server just keeps crashing and the backups just keep crashing because it's hit some ugly condition and you need people that really know the system and you need them right now, that's when you want support. But it's rather hard to argue with a man that think lightning never strikes.
Re:Update & security responsiveness (Score:2, Insightful)
You're doing it wrong.
Red Hat is a stable server platform.
Ubuntu is *not* a server distribution.
Stop letting your developers (or yourself) think think that you need MongoDB/NoSQL/Sphinx/Ruby On Rails/whatever the latest trash is this week. They're all reinventing the wheel, once they mature and actually have safety/error checking they'll be just as slow as whatever they were intended to replace and the kids will be talking about the next wheel..
Comment removed (Score:5, Insightful)
Re:Support them from your own money (Score:5, Insightful)
Im pretty sure if the need arose, there are scores of companies that would love to take your money in return for supporting CentOS, either on an ongoing or onetime basis. A good starting google search might be "CentOS Consultant" or "CentOS support", both of which return promising results.
To OP:
An ongoing contract is not always necessary; sometimes it makes more sense to do one-time issues. The CIO's job (and higher executives) is to make decisions like these based on their own experience and based on the recommendations they get from others. You have given your input, and he is deciding that, however good your advice it is, he is willing to take the risk for what he thinks is a better value. I would just accept that.
As a consultant, I have met smaller clients who, for example, insist on using Norton "business" products. I give my opinion on them, tell them I think it is a bad solution, and if they say "thanks, but we want to use norton", I have done my job, and they are doing theirs. Noone wants an engineer who thinks it is his job to make executive decisions, because it is not.
Re:Update & security responsiveness (Score:4, Insightful)
I seem to recall something about that also.
I worked for a place, that was sworn to use RedHat.. Well, RedHat 6.0 through 6.2. The logic was "Our application worked on it then, we'll keep using it forever". Damned the remote exploits. Damned patching it, ever. We'll use it the way it came off the disk.
{sigh}
I showed them that their application ran fine on the current Slackware, and even Slackware64. They had 64 bit servers, but refused to consider using a 64 bit operating system. Again, "it's the way we've always done it."
A few remote exploits later, and new hardware that simply wasn't recognized (damned if they'll let me build a kernel). I had to sneak a few newer kernels on, to support hardware that they wanted. (shh, that's still a secret).
They did decide to start using newer hardware, with a modern operating system. They wanted RedHat, they wanted support, but didn't want to pay for RHEL. I asked them "how many times have you asked for support in the last few years?" The answer was, "zero". Actually, they did ask for support. The folks over at RedHat laughed at them. Well, very politely. It was something like "You're using an ancient unpatched patform. Go download something resembling modern, and we'll help you."
There was a running theme there too. They used the version of Postgresql that came on the CD. They used the version of Apache that came on the CD. Regardless of what improvements or security fixes showed up in future versions, they didn't come on the original CD, so they weren't trustworthy. I was really surprised that we didn't have a higher suicide rate. I found that talking to a brick wall while on long smoke breaks was far more rational than trying to argue with them.
The ended up going with CentOS, because it was modern, it did have pay support available, and they could get the OS for free.
I have a serious problem with RedHat and all derivatives. They patch known stable code to make it theirs. On so many developer sites, I've seen statements saying that they can't support known bugs in the RedHat tainted versions, because the changes destabilized it. Basically, if you want help from the author, go get a fresh copy, compile it, and install it. If you're allergic to compiling (sadly, so many people are), most authors have a RPM version available.
It's not just a few authors who complain. It's not just some edge cases that become troublesome. I ran into them all the damned time. In quite a few cases, I had to go compile static binaries from original author sources, on my Slackware machine, and copy them over, so basic things would "just work". They refused to accept that anything with "Slack" in the name could possibly work, regardless of the fact that I ran an enterprise network for years, fully automated, without any problems.
The fully automated part was the reason I wasn't there any more. My babies (the servers) were self sufficient. I was just a babysitter, in case something went wrong. Failed hard drive, CPU fan failure, the occasional bad network cable. You get the idea. I didn't spend every day logging into well over 100 servers, fixing things. And we were always patched up to current. If Slack didn't have a package, or if we wanted something different, we managed that ourselves. As I recall, that list was 3 things. Apache, Sendmail, and OpenSSH. Those three were customized for our purposes.
Re:Support them from your own money (Score:4, Insightful)
The question is not how much support costs. The question is how much is DOWNTIME going to cost the company?
No, the question is what is OP's job description. Arguing endlessly with his superiors about their executive decisions is not going to change their minds or endear OP to them. Sometimes being an adult and a professional means accepting that your superiors will make decisions that you disagree with, and learning to accept that.
Re:Update & security responsiveness (Score:2, Insightful)
People who suggest ubuntu over RHEL on mission critical enterprise servers because of the lack of non-security related updates are clueless noobs who are going to be severely burned one day by dependency hell on some random piece of shitware that is not required for the operation of your server.
Mission critical servers are installed and then maintained with the bare minimum of patches required to ensure continued secure operation. You install new pieces of random shitware in TEST, and upgrade software in TEST then roll out as a major upgrade after a few years - not every 2 weeks.
Re:Support them from your own money (Score:3, Insightful)
Re:Support them from your own money (Score:5, Insightful)
Re:Support them from your own money (Score:5, Insightful)
Re:Support them from your own money (Score:4, Insightful)
"Hey, if we strip all the copyrighted stuff out we can just take what we want and not have to pay RH shit! We'll save a bundle!"
Well, and the "no so nice" part is?
Red Hat decided on their own way to do business. Such a way included not developing an OS from start but instead using an OS with a license that allowed them to package it and throw a brand, a marketing campaign and a support business but it has a cost Red Hat was willing to accept: that others could do the same.
The end result is that Red Hat pushes money at it because it works for them, CentOS rebrands the software because it works for them, and I as a user have a choice that fits me. The day each respective choice works for the given agent no more is the day they'll change boats to look for greener coasts.
But that's the basis of free market, now, isn't it?
Re:Linux is free if your time is worthless. (Score:5, Insightful)
"Linux is free if your time is worthless".
This is possibly one of the most useless quotes ever. Does it take zero time to build and deploy a solution on Windows? No. Does it take zero time to build and deploy a solution on any other platform? No. Building and deploying a solution on any platform takes time. So what is the point of this quote? If it is to state that building and deploying software takes time, then it is stating the obvious, and needlessly singles out one platform, when the principle applies to all. If the point of the quote is to suggest that Linux based solutions require more time than those of other systems, then the evidence suggests otherwise, as studies have shown that the average Linux admin is able to support a greater number of servers than a similarly qualified Windows admin.
Linux is free. You can download it for free. You can run it on as many servers, with as many CPUs and users as you want, and you don't have to pay anything to anybody. That is what free (in this context) means: "Free: Without cost or payment." Nobody ever claimed that by choosing Linux you would have no work to do - that somehow, amazingly, your servers and systems would get built and deployed by magical Linux elves, who do your job for free. It's an absolute strawman argument.
Re:He's unlucky his CIO's a fool then (Score:4, Insightful)
Just a very short refutation:
counting numbers of security advisories issued for a product is an entirely useless metric when it's up to the creator of the product under what circumstances to issue an advisory. Red Hat could stop issuing security advisories for anything tomorrow, and by your metric, it would then be the Most Secure Thing Ever.
By counting advisories and then ranking on the basis that more advisories = less security you're essentially punishing good behaviour. It's not a _good_ thing to encourage companies to stop telling you about security issues.
Re:Support them from your own money (Score:4, Insightful)
Except that Red Hat does provide services people value, they're they top contributor [cnet.com] to the Linux kernel.
They're the leading contributor because the people paying for support need those features/bugfixes they are contributing.
Support contracts aren't just for helping clueless admins do their job because they're too lazy to Google.
Re:Support them from your own money (Score:5, Insightful)
My philosophy is that I'm not paid what still seems like a somewhat shocking amount of money to just do what I'm told. You can get some kid to do that.
I'm paid to do my best to understand all the issues, make a clear recommendation, and to make sure that the boss clearly understands my recommendation. If the boss disagrees with my recommendation, it's my job to make sure they understand why I think what I think.
At that point it's on them if they want to decide against my recommendation. Sometimes it works out, sometimes it doesn't. And it becomes my job to do what they decided should be done, and to do my best to make it work, even if I think it's stupid.
It seems to me that the OP is still in the "make sure they understand" phase.