What we both are are power users that don't really need their support. Our company has an entitlement so we can use the KB articles (to our benefit) and view/submit bug reports to them (which is to their benefit). I have no problems telling them that (and for the most part did last week), and if someone on the call were to argue me on that point, I'd have happily gotten into it with them. I know they're adding a lot to linux and open source, and pay for a lot of developers to maintain and add to projects (including Linux itself), but that's just the point, they're adding to something that already exists that they use. They don't own it, and they can't expect to require payment for it. They aren't Microsoft, and the only reason they've ever been able to compete in that space is because they're standing on the shoulders of what the open source community has made possible.
It's a symbiotic relationship, and they can mess with it at their peril.
"freeloaders"
Most Active Linux 6.1 Employers [1]
By Changeset
[...]
7. Red Hat 672 4.8%
By Lines Changed
[...]
10. Red Hat 24073 3.1%
Most active employers, 5.16 through 6.1
By changesets
3. Red Hat 4916 5.7% (behind Google and "Unknown")
By lines changed
8. Red Hat 202698 3.3%
It's dishonest to leave that conditional off the quote. The work and risk/stress involved in running a supportless shop is quite high. So if they are freeloading by using Rocky then Red Hat is also freeloading.
I do think it's funny that they weren't even number 1 on that list though. Guess they are at least getting a lot of volunteer work from other companies!
One of the major differences between buying a support contract with RH and buying one from literally any other vendor is that RH doesn't sell support for things without having someone active in that project's community.
AKA, there is a good chance the gatekeeper that your !RH support provider is talking to is a RH employee or funded by RH. Put another way, rocky can't afford to hire 1k engineers to maintain all those packages, nor can anyone else so your trusting that the bug you want fixed can be fixed by a drive by contributor. This is part of the reason that RHEL has such a small package list too, just about every single package in that list has someone working upstream.
So, you won't get stuck like i did 15 years ago with a glibc bug that the company your paying a support contract to can't fix. Sure that distro patched their own version, but the change got dropped a couple years later during a rebase, and it was the only distro with the fix. Meaning our product only ran on that specific distro + version until we reopened the bug with RH and they actually got it fixed upstream.
Also to be clear, I'm wasn't making a case abovec that Red Hat doesn't provide a lot of benefit to the open source community, just that Red Hat could not exist without that same community. I do not begrudge Red Hat making money. I do think they're being extremely shortsighted if and when they shut off the larger open source community's uses of their core OS product. They're making their whole ecosystem much harder to get talent for if they do that, and it's not like entities running Rocky or Alma are just going to spring for RHEL. We trade on our staff's skill as System/Linux Administrators, and the core OS is not as important as all that. It's like if Python started requiring licensing fees. You'd get some short term return on that and some larger entities will just pay, but you'd see python usage in the general community plummet, with all that entails about its future.
Maybe to their eyes it makes more sense in this current world of startups and VC to just exclude the smaller players, since those companies that grow organically to a size where Red Hat's pricing makes sense are much rarer?
Depending on who you're talking to, this may not be a good thing.
While it may technically be legal (ie crafted by lawyers to make sure of it), that still seems like a pretty shitty thing to do.
We've just about finished transitioning to 100% Rocky, coming from a 50/50 setup with many of the bare metal installs being Ubuntu. But Ubuntu left a real bitter taste in my mouth with the snap enforcement (I can't even start this snap thing in my Ubuntu Docker container? And you took away the native apt? Wow.), so we started a migration to 100% Rocky.
Telling my manager that we'll have to work something out after we just about finished working something out will be my own peril as well. Let's see where this will end.
We're only about a quarter migrated though, so still have a few hundred Centos 7 boxes to eventually get off of, and we'll see if that ends up being Rocky or something else.
I will note that this episode of The FOSS Pod[1] with a Debian lead actually made me think switching to Debian itself way back in the past (since we've been doing this for almost three decades now) would have been a safer path. I highly recommend it, it cleared up a few misconceptions I had as a Red Hat/CentOS user about what Debian is really attempting and why, and how that would fit with our needs. For example why their goal of pure open source licenses isn't an ideological choice, but a choice to benefit the Debian ecosystem, since the goal is to make downstream distros of Debian easy and without problem (e.g. no extra legal review needed based on licensed included).
1: https://fosspod.content.town/episodes/debian-linux-with-jona...
I have to admit, while I share a lot of the values of Debian, I never really liked the product. Especially the apt package mangler, err, manager. They've also carried some Debian in-house patches that really caused me some grief in the past.
I've started running FreeBSD on my personal servers. Unfortunately it's not an option at work.
Our director loves FreeBSD, and we actually use it for firewalls, so it's not a spectacularly hard sell. I'm not sure it's significantly different from the problems of Stream to make it worthwhile, at least not without some external patching and support entity in addition, but it's been a long time since I looked at the specifics of their packaging and ports systems. I don't actually mind something like Stream for a personal server actually. It's just when trying to manage a fleet in the tens and hundreds when it becomes a real liability and increased possible admin support load IMO.
Honestly, having built some packages and maintaining a derivative provided me more insight than a regular user, but even before that I was using Debian without any problems.
BTW, Ubuntu is not Debian with a different UI. They're pretty different on fundamental things, even.
So yes, I made that comparison. If you think a company using a RHEL derivative product is freeloading, I'm not sure how you can believe Red Hat isn't also freeloading on the open source community, but feel free to explain you position.
I, for one, think neither is freeloading, but just making use of the open source community to provide extra value for ourselves and our customers.
This is a two-way street. It's not all on Red Hat. I don't know to what extent Red Hat has or hasn't tried to do a deal with Digital Ocean but it's not as simple as Red Hat just deciding to do it. There's a fair amount of certification work that DO would have to do as well as hammering out the legal / business agreements.
The "comparable" part exists with many cloud providers, so if you're not married to Digital Ocean then that part should be doable. Red Hat also has some programs around subscription portability.
However, I do get it that the subscription process introduces friction and for small shops that have a patchwork infrastructure as you describe, it's going to be difficult. Some of that is on Red Hat to solve if they want your money, but not all of it. They can't do it all themselves by fiat if Digital Ocean isn't willing to meet them halfway.
How exactly do you think those companies even came to exist again?
I think they do this on AWS and Azure (and maybe GCE?). DO may just not see enough of their enterprise customers asking for it for them to dispatch the lawyers and negotiators to make this happen.
Disclosure: Ex-Red Hatter, but never got anywhere close to anything related to sales or licensing.
I'm in basically the same boat, currently using Linode. At other companies I've made decisions to buy RHEL and OpenShift, and would again because I've been pretty happy (we'll see how this current thing shakes out).
I also went to work for Red Hat (and took a pay and title cut) largely because I had so much love for them. I'd been using Fedora and CentOS (pre-stream) for many years. The expertise that I gained from the experience also let me hit the ground running in my new job, and I made them a lot of money. Had CentOS not existed, I would never have learned their ecosystem and certainly wouldn't have gone to work there. That's profit that is hard to measure, and it is hard to directly tie it to somebody's commission or KPIs, but I'm sure it's not unsubstantial. Many of the people I worked with had a similar backstory!
I would also say (at least when I worked there) I didn't know anybody (who wasn't a sales person) who would have called us free loaders. Quite the opposite, they considered us part of the community.
We've tried to make deals with RH in the past, but they will only let us sell RHEL VMs with licenses if it's running on a RHEL hypervisor... which none of our platform is using at all.
Now that said it's a bit dumb because with most things it's not hard for support to tell your customer, "yep that's a problem in the guest" and help, or "that's a problem with the host, contact DO" or whoever.
But in general, when Red Hat says something is "supported" they are guaranteeing a lot about it. They'll literally fix the code if something is wrong. There's also a culture internally of "be careful helping with something that is 'unsupported'" because customers have previously accused RH people of messing stuff up and demanding they fix it. I helped with stuff like that most of the time when I worked for RH, but I was always very clear with the customer that "this isn't Red Hat, this is me helping as a friend and fellow Linux nerd" and the rapport with the customers was always good enough that I wasn't worried.
Having exact versions is not a problem (any version of RHEL guests are supported on any RHEL hosts past and future, almost). Plus Windows, ESX, Amazon and Google clouds, and a few more.
Rather, the problem is having _up to date_ versions; with RHEL you can often ask the customer to reproduce on an up to date host if possible, with other distros the support machinery isn't there and you need someone to talk to at the cloud provider, so that they can debug stuff that breaks only in their environment and can't be reproduced. Otherwise you cannot guarantee the level of support that you mention. Very few cloud provider can provide that, I am not even sure that IBM's cloud made the short list.
This is exactly how you consume Windows on AWS and it's a huge incentive to do it that way because it takes licences management out of consideration.
> This is exactly how you consume Windows on AWS and it's a huge incentive to do it that way because it takes licences management out of consideration.
It's also how you consume RHEL on AWS, GCE or Azure.
And we'd have to figure out what to do with the bare metal instances and containers, too.
It is a big motivator for people transitioning from your state to becoming a customer.
Most of the major clouds have this pre-existing capability to charge more and revenue share the extra through their marketplace services etc; and they're in active use by other vendors. It's often a good source of revenue for both the cloud company and the vendor, and helps the customers by providing them with prebuild solutions that they don't have to build themselves (e.g. web application firewall vendors can/do provide closed source images that customers can use that way). It's not like this is expecting cloud companies to build whole new services from whole cloth just to support Red Hat.
This 100% already exists, but I don't believe Digital Ocean is one of the supported vendors.
These guys are also power users and developers who need no support.
This is a massive blow by RedHat, and I'm not sure that they're aware of the size of the install base they are attacking to.
This exists, but probably only for the larger cloud providers and not e.g., DigitalOcean: https://azuremarketplace.microsoft.com/en-GB/marketplace/app...
First things first: we're a Rocky Linux shop. About 100 instances, some bare metal, some VMs. A few local, a few at cloud providers like DigitalOcean. Held together by Ansible and kickstart installs.
Too often the discussion about RHEL clones like Rocky paints a picture of people like me as freeloaders. And some of the folks with a similar setup might be. But most small-time Linux admins I know are real open-source believers. I would really like to funnel some money into the platform we're using. First and foremost because it's the right thing to do, the people writing all that source code deserve it. But also because we need platform continuity, and being able to open a support case from time to time would also be great.
But it's really hard. I don't have the time and nerves to deal with the RHEL sales department, deal with the licensing, produce my own cloud images because DigitalOcean can't provide them, deal with our own internal purchasing process, deal with convincing my superiors that we need to.
Please, dear Red Hat, just give me a DigitalOcean VM (or something comparable) that costs a few dollars more and has automatic RHEL licensing. Make deals with the VM providers, work something out.