11 ms·
(Note: I work for Red Hat) I'm constantly amazed that people still don't understand why Red Hat makes money, and this article won't enlighten you as it doesn't
by rwmj 4y ago
(Note: I work for Red Hat)
I'm constantly amazed that people still don't understand why Red Hat makes money, and this article won't enlighten you as it doesn't understand it as well as being full of other incidental mistakes (like their description of CentOS is way off the mark).
Red Hat takes Linux and certifies it against all kinds of government, safety, privacy etc standardards, such as PCI and FIPS and numerous local ones. As a result if you are a government or many large companies you simply cannot download Linux and YOLO it. You are legally required to use the certified software so you take the path of least resistance and buy RHEL. That's it. It's why Red Hat makes piles of money, and Canonical or your SaaS does not. Understand what your big customers are required to have and provide it to them, even though it's boring and expensive to do.
- AniseAbyss 4y ago[dead]
- gbraad 4y agoAnd note; it is written by Sid Sijbrandij, who is the CEO of GitLab.
- rwmj 4y agoThanks, I didn't make that connection. It explains a lot about why Gitlab are losing money hand over fist at the moment.
- gbraad 4y agoThe name is very obvious to me; quite a 'unique' Dutch name, and he used to be the classmate of a colleague of mine. While he doesn't mention the name in the article, the Open Core references align with their own offering.
- hahnchen 4y agoDoes redhat have customors who don't need government compliance? If so, why do they use red hat?
- rwmj 4y agoOnce you are the default choice that has other network effects, so yes. For example if you are a software vendor who needs to ship a proprietary kernel module - think something like software to control a lab instrument - only Red Hat has a credible kernel ABI scheme with the required scale (because of the reasons I gave in GP). So every ISV in this situation specifies RHEL and requires that you run your software on a purchased copy of RHEL for support reasons. And usually the ISV software costs many multiples of the cost of a RHEL license, so it's lost in the noise.
- vetinari 4y agoAnd this is something that CentOS Stream breaks and that makes it not an alternative anymore. RHEL did ABI or kABI breaks only with minor releases. CentOS Stream can do them randomly, just like any other distribution.
- Conan_Kudo 4y agoConsidering that CentOS Stream represents the between state of RHEL minor releases, it's not "randomly". That said, the CentOS Kmods SIG generates reports on how the kABI churns in CentOS Stream[1] and RHEL[2]. [1]: https://sigs.centos.org/kmods/kabi/c9s/ https://sigs.centos.org/kmods/kabi/c9s/ [2]: https://sigs.centos.org/kmods/kabi/c9/ https://sigs.centos.org/kmods/kabi/c9/
- vetinari 4y agoRandomly as in any dnf update can bring the breakage that you might not know upfront. With minor releases you would read release notes, check your modules and knew, whether you can update or not.
- ilyt 4y ago> only Red Hat has a credible kernel ABI scheme with the required scale (because of the reasons I gave in GP). Other distros also don't change kernel version during stable phase so I don't even know what you mean by that. Hell, RHEL kernels have more changes than say a Debian kernel over lifetime of a version. What Red Hat uniquely does is to backport features into older version of the kernel, so statements like "you need kernel x.y.z for this to work" don't really apply, you need to find whether they backported that feature or not. We've also experienced some "fun" with how they manage it and versions in general for example: * Driver bug was backported from newer kernel (they backported "performance improvements" not bugs) in rhel5, so we lost VLANs on our upgrade canary * Same bug was backported to rhel6 with same disastrous result 6 months later * One of servers stopped booting because they changed version of LVM in STABLE DISTRO (think it was rhel6), and new LVM version deprecated/renamed some flag that we used, that made it fail on boot. So yeah, we're very happy we migrated off it. And in Debian distro upgrade works too!
- mr_toad 4y agoIt makes me cynical when most certifications and compliance involves a lot of paperwork and not much in the way of changes to software.
- helmholtz 4y agoGreat, so you won't make the piles of money that RHEL does, but maybe you'll enjoy your work more.
- pas 4y agobecause compliance is mostly about documentation. glorified checklists. but checklists work (you might have heard about surgeons leaving medical tools in patients, and checklists eliminating this problem, seemingly the dumbest simplest technology, yet it's very powerful compared to the default of nothing) of course the quality of answers matter, but that's on the environment (auditors, regulators, industry best practices, trade groups, client expectations), see the absolute total shambles of the state of IT sec in South Korea, the 1000 year old COBOL systems in finance/insurance, the reservation system in air travel, the sorry state of TLS before LetsEncrypt, SMTP servers (how SPF, DMARC, DKIM and ARC and MTA-STS are all needed to signal that you really prefer TLS, really don't want to be impersonated, you really vouch for forwarded stuff, etc). also there's the BeyondCorp step-up. nobody bothered to really segment the internal network. nowadays the default is zero-trust.
- orbifold 4y agoNext level of the game is to invent the certifications in collaboration with regulators and then sell software that is certified.
- AmericanChopper 4y agoThe real next level game is to get a patent you own into a standard.
- mordae 4y agoThat's what M$ does with Azure, is it not?
- tyingq 4y agoIt's interesting to see this in play at different companies. Some of it is "real"...that is those requirements really do apply. In many places, though, it's just inertia. Like, back when the companies had SunOS or HPUX, they made internal standards about regulations, or support contracts, etc, to match. Then when Linux came around, RedHat fit their view of the world well. It's also interesting to see what happens there in some places over time. The older group that manages on-prem is able to hold the "RedHat only" line. But, other groups decide what goes on it, so everything running there is running in non-Redhat containers or nested VMs. It turns into a bulky, extra hypervisor-like layer.
- mnahkies 4y agoWe use https://cloud.google.com/container-optimized-os/docs https://cloud.google.com/container-optimized-os/docs for our kubernetes nodes on GCP, as I'm sure most companies that use GKE do. Your comment made me want to say "but COS is certified too!" however now I'm unsure - a quick Google certainly doesn't bring anything up. Why have Google not done this, is the demand not there? Or have they and they just don't document it prominently? (Note we don't have any PCI requirements as we offload those to the likes of stripe etc)
- eitally 4y agoVanilla options on GCP would not be certified for specific regulatory requirements. You would need to be -- in the cases of government regulations -- need to be running Assured Workloads. https://cloud.google.com/assured-workloads https://cloud.google.com/assured-workloads As to your question of why: maintaining compliance is expensive, especially if you're accustomed to pushing prod code changes hundreds of times per quarter.
- dboreham 4y agoRegulatory capture.
- rwmj 4y agoYes and no, it very much depends on the country and regulation you're talking about. Not every regulation is uncompetitive red tape. I'm quite happy that airline and medical software is heavily regulated, or to give a more recent example that we've been working on, that in-car software is required to have minimum response times to user inputs.
- HPsquared 4y agoThat's the real Red Hat model. Certification.
- parasubvert 4y agoThis is partly true. It’s worth noting that Canonical/Ubuntu has the same certifications such as DISA/STIG and FIPS, and runs quite a bit in highly sensitive environments, often bundled by ISVs, such as VMware or Pivotal, where I’ve worked. Red Hat makes more money because they’re an enterprise software company and everyone thinks they’re just an OSS services company. They’re that too, but they are far more sophisticated than these articles claim. At the core is that Red Hat’s distro is perceived as more of a standard by the ISV community that certified their software against it. Red Hat does a masterful job of playing both sides of openness - open copyright, closed trademark. They’re pure open source… but they fork most of the upstream with their own branded project version, and convince companies to certify against the proprietary trademarked offering. Automated upgrades and most documentation are behind a paywall. But they also have some of the best security responsiveness and extended support (up to 10 years?) in the industry to make up for it. Beyond Linux, they also meet customers where they’re at by watching the competition and customers, and pivoting when they need to. Customers seem to like a competitors product more? They find the next leapfrog angle and invest years in it, dumping the old. OpenShift was rewritten 3 times before hitting paydirt! That’s good business sense. OpenShift trying to take on vSphere, Ceph evolving into an enterprise storage player, etc. These aren’t simple moves. This dance of subtle open/closed aspects a great business model, and hard to replicate: open in code, but closed in the direction the money must flow. Most business folks don’t have the patience to weave this narrative, which takes years of reputation building. And it’s required alongside all the other “build a product people want” difficulty. IBM also loves this model: “WebSphere” certification over “Java EE”, for example. Hence “OpenShift” certification over Kubernetes, or “RHEL” over Linux.
- rwmj 4y agoCanonical don't have the heft to compete against Red Hat, and especially not IBM + Red Hat. If Wikipedia's figures are right, Red Hat employs more people maintaining the kernel and RHEL packages than Canonical employs in total. This matters a lot for government and other large customers. The companies that do have the scale needed to compete are the cloud vendors who are rolling out various certified cloud instances, and in the case of Microsoft/Azure, AMD-based confidential computing.
- dmd 4y agoThe thing I don't understand about Red Hat is how the support is so bad. I (a customer at a medical/educational site) pay for Red Hat, and on the few occasions I've requested support, that support has never, not once, actually solved my problem. In every single case, I eventually solved it myself after weeks of back-and-forth with one support person after another consisted solely of "solutions" like "reinstall the OS", "we won't support you unless you update [completely and utterly unrelated minor package]", and "please give us [piece of information that was included in the original ticket". In several cases I finally found the right answer ... in access.redhat.com/solutions .. but the support person was never able to find it. We purchase it because we're required to, but we get absolutely no value for the money.
- warner25 4y agoInteresting to hear this. My last job was in a shop that ran RHEL servers and I always felt bad for not using the support that we paid for. Like after working through a problem, thinking, "Oh, we should have called Red Hat." I guess we weren't missing much. We got support instead from upstream IT folks internal to our organization who packaged the applications together with RHEL (and that level of support was similar to what you describe).
- ossusermivami 4y agoI had that same experience, some time there is a lot of back and forth with junior support people that doesn't seem to have a clue what's going and only follow a script, it gets better when it gets escalated but that's painfully slow to get there if you are not a marquee customer.
- anothernewdude 4y ago> As a result if you are a government or many large companies you simply cannot download Linux and YOLO it. Experience begs to differ
- hodgesrm 4y agoI'm really surprised that the article does not highlight cloud services as a way to monetize open source. This seems like the most obvious way to get revenue from back office open source projects, especially databases. RedHat itself invested in relationships with cloud vendors from early on.