The DXC Blogs – Paying for Linux
Originally posted internally 22 Sep 2016, and it’s another post where I took an email reply to a broader audience.
I got an email question about switching from Red Hat Enterprise Linux (RHEL) to Oracle Linux in order to save cost, and I thought the answer would be worth sharing more broadly:
With Linux it’s important to be clear that you’re paying for curation of the distribution, support, and the patches/updates that go with that. Although there is a key used on the OS to provide access to updates, it’s not really a license in the traditional sense.
What Oracle have done is copied the Red Hat Enterprise Linux (RHEL) distribution, and they’re selling a support contract at a lower cost to Red Hat. They’ve also done a pretty good job of making the process of switching from Red Hat’s update infrastructure to their update infrastructure fairly painless – so the in place switch is more than a license key change, but not much more. I’d also not be too bothered about Oracle ramping prices later – firstly switching back would be easy, and secondly Oracle seem much more interested in undermining Red Hat than they are in building their own open source based business.
It’s also important to be clear on what the value proposition of a distribution is, which (beyond support/updates) is generally tied to the certification of third party software that will run on top of it. This is where things get tricky for Oracle Linux, as most software vendors (beside Oracle themselves) certify RHEL but not Oracle. It shouldn’t matter, given that the only change is around where updates get downloaded from, but it’s this sort of petty detail that can cause unnecessary noise and problems when faced with an outage.
Personally I’d question the value of paying for Linux support at all, particularly as paying for Linux often becomes a cost barrier to other changes that would otherwise make sense. When did this customer last have an incident with Red Hat, and how did that work out for them (is the myth of software support at play here)?
If you look at the cloud most people use Ubuntu (without paying Canonical for support) or CentOS (a RHEL like distribution).
I’d also highlight the the Canonical support model is much more cost effective than Red Hat. This is something that I wrote about in ‘Banking on Ubuntu‘ a little while ago after meeting Ubuntu/Canonical founder Mark Shuttleworth.
We have standard operating environments (SOEs) for Ubuntu.
Retrospective
Before moving the infrastructure as code training to Katacoda it was run out of Docker containers on AWS. Since RHEL is the most common Linux in our customer environments I went with a CentOS Amazon Machine Image (AMI )to keep things similar. This was painful, because there are no official public AMIs for CentOS (like there are for Ubuntu), just marketplace AMIs, and if you build an AMI from the marketplace you can’t make it public. I wanted to have public AMIs so that staff could run the training materials in their own AWS accounts, and that initially drove me to the unofficial Bashton CentOS. But I fear there might have been a vulnerability in those AMIs, as any VM left running too long turned into a compromise notification from AWS. Only later did I realise that I could just use AWS Linux, which is also EL/yum flavoured.
I’m still shocked by how many organisations think that (for ‘insert specious regulatory reason’) they must pay for Linux support, and generally in a way that has them coughing up by the socket like the bad ole days of proprietary Unix like SCO.
Original Comments
NS
Paying for Linux support is not a technical decision, but purely a commercial one. In a support contract you have to ask who is ultimately responsible for fixing a bug in the Linux kernel – CSC or a vendor? Are customers happy with a CSC reasonable efforts approach or do they want some certainty? It’s the latter approach that the commercial people often insist upon.
CS
It’s not a black and white question of pay or don’t pay – it’s a question of who do we pay, and how much in order to get the right level of risk mitigation?
NS
It might be an interesting option for some customers if we could offer a global Linux support offering around CentOS and Ubuntu.
Filed under: DXC blogs | 2 Comments
Tags: Linux, RHEL
Subscribe
Recent Comments
Tim Coote on Ross Anderson RIP iain on Skiing in Espace Killy (Val… Chris Swan on Getting more from a British Ga… Murray Cowell on Getting more from a British Ga… JL on AI MacGuffin 
Pinboard.in bookmarks- Open Source Security (OpenSSF) and OpenJS Foundations Issue Alert for Social Engineering Takeovers of Open Source Projects
- AI isn't useless. But is it worth it?
- Pluralistic: The true post-cyberpunk hero is a noir forensic accountant
- Subaru battery drain due to missing 3G network
- Paying maintainers: the HOWTO
- SARS-CoV-2 airborne infection probability estimated by using indoor carbon dioxide | Environmental Science and Pollution Research
- An unbiased evaluation of environment management and packaging tools
- Computer says no: British judge refuses to cancel divorce resulting from computer mistake
- Philosophy Museum
- Royal Navy offer must improve to attract and retain staff – you can't motivate an empty chair
Chris Swan's Weblog 
Hello Chris,
You semi-answered your own question above when you talked about using a distro that led to consistent compromise. It is becoming nearly impossible to know and review every bit of code we deploy. When you consume code with support and a team of people who are reviewing it you get that consistent value add. It’s a bit like purchasing pre-engineered and architected kit. If the bread and butter of your business is something else, while you could develop that capability in-house, it probably makes the most sense to consume those value added services from providers of scale who provide those services as their “core business” at a speed you couldn’t in-house.
I don’t doubt the value of distros, but I am questioning the model used to compensate that value. A per X fee doesn’t scale elegantly (in terms of cost/reward), whilst freeloading is corrosive to open source communities (and particularly those doing the hard work to assemble, review and curate distros).
Something I’m frequently having to say about DXC is that we’re not an Enterprise in the traditional sense, because we’re larger and more diverse; I sometimes use the term ‘meta Enterprise’. This means that many things intended to work for Enterprises don’t work well for us, and the cost (as scale) to benefit calculus is a big part of that. Much of the IT industry looks like insurance, and at scale it can make sense to self insure. I really like it that we have engineers that can fix open source for themselves, not because it saves us from paying for support contracts (though that’s a nice benefit too), but because we can move (iterate) much faster.