Krishna was on Norges podcast a while ago and mentioned that Red Hat would be (not his words) brought to heel with the rest of IBM. IMO, it is a version of the Broadcom/VMware playbook, boil-the-frog style.
Redhat underpins many low-visibility, very important Linux projects, and most have no idea they are doing it. For example, look at kernel committers:
weighted by market cap, the disparity is even more severe imo.
There is more visible projects (eg Ansible) that are great, but with very lackluster monetization and little impetus for IBM to GAF.
These guys are pursuing the wrong strategy, they should be using super popular, high-mindshare projects to drive new wave of tailored business solutions leveraging existing consulting teams they already have (IBM revenue to hugely reliant on PS, 33%). Basically the largest "forward deployed eng" transition ever, backed by existing very strong open-source software and tailored (with Watson, dear god) as the "AI powered" engine to appease the shareholder gods. You would run over so many startups with poor penetration at the F2000 level.
One thing I hope IBM understands here is that healthy F/OSS projects aren't really the kind of thing you can buy and proprietarize even by "forking"/re-licensing your own code. Ages ago, Oracle learned this when they bought Sun, particularly with the birth of The Document Foundation and LibreOffice. More recently, Hashicorp is facing the same phenomenon with the departure of the chief maintainer of Terraform to work on OpenTofu at Spacelift.
Many F/OSS maintainers care pretty deeply about things like software freedom, taking good care of our digital commons, and leaving their mark on the world in a public way. I imagine that's especially true at Red Hat. You can buy the company, you can change the relationship to the community of "outside" contributors, and you can even release new versions of the software under a proprietary license. You can create upheaval for a lot of people, including the users. But you will often not only fail to walk away with key maintainers on your team, but watch them go on to form your competition on a new fork.
I don't personally know anyone who works at Red Hat, but even from the interactions I've seen recently in issue trackers and PRs to projects maintained in part by Red Hat engineers, I'm inclined to have a bit of faith. The upstream-first culture there still seems pretty strong and pretty quality-oriented to me. I don't think you can reliably keep engineers like that and turn them into drones who don't care about the craft and their impact on users and developers.
Hasz · · focus · HN ↗
Redhat underpins many low-visibility, very important Linux projects, and most have no idea they are doing it. For example, look at kernel committers:
<a href="https://insights.linuxfoundation.org/project/korg/contributors?timeRange=past365days&start=2025-10-01&end=2026-10-01" rel="nofollow">https://insights.linuxfoundation.org/project/korg/contributo...
weighted by market cap, the disparity is even more severe imo.
There is more visible projects (eg Ansible) that are great, but with very lackluster monetization and little impetus for IBM to GAF.
These guys are pursuing the wrong strategy, they should be using super popular, high-mindshare projects to drive new wave of tailored business solutions leveraging existing consulting teams they already have (IBM revenue to hugely reliant on PS, 33%). Basically the largest "forward deployed eng" transition ever, backed by existing very strong open-source software and tailored (with Watson, dear god) as the "AI powered" engine to appease the shareholder gods. You would run over so many startups with poor penetration at the F2000 level.
whimblepop · · focus · HN ↗
Many F/OSS maintainers care pretty deeply about things like software freedom, taking good care of our digital commons, and leaving their mark on the world in a public way. I imagine that's especially true at Red Hat. You can buy the company, you can change the relationship to the community of "outside" contributors, and you can even release new versions of the software under a proprietary license. You can create upheaval for a lot of people, including the users. But you will often not only fail to walk away with key maintainers on your team, but watch them go on to form your competition on a new fork.
I don't personally know anyone who works at Red Hat, but even from the interactions I've seen recently in issue trackers and PRs to projects maintained in part by Red Hat engineers, I'm inclined to have a bit of faith. The upstream-first culture there still seems pretty strong and pretty quality-oriented to me. I don't think you can reliably keep engineers like that and turn them into drones who don't care about the craft and their impact on users and developers.