Hacker News Reader

Krishna's words on the podcast you cite were: "Red Hat has not been integrated... yet. [...] Engineering in Red Hat, I actually believe given the open-source nature of Red Hat, is going to have to be its own function. So, engineering I will likely not integrate because working at their scale of open source, maybe that is one where IBM learns from them, and things that are open source should belong much more in the Red Hat methodology than ours".

Operations (HR, finance, legal, IT) has already been integrated into IBM and that's what the post is talking about. Not engineering.

Full video:

https://www.youtube.com/watch?v=IxqrSXiRja4, 6:37 starts discussion about integration, so you can judge exactly what he says.

"The only one we have not fully fully integrated yet, and I will emphasize the "yet" is RedHat".

"on the go to market side, I really believe in full integration".

you already mentioned the engineering teams, and I do think your framing is mostly right. However, I think it unrealistic to say I am going to fully integrate back-office, fully integrate GTM, and somehow engineering is totally untouched.

They are not fully integrating go-to-market. In the podcast Krishna says that the size and organization of Red Hat's GTM was larger than every other acquisition, and they were looking at partial integration only. Since then they actually have moved the sales teams for smaller markets to IBM. Red Hat kept the 20 or so largest markets and the verticals.

Right now operations is employed by IBM but still mostly working as they did at Red Hat. We'll see how that changes over the next couple years, as that would be the first look at Red Hat integrating into IBM.

When we were purchased by IBM (admittedly it's been a while), our separate HR, finance, IT and legal groups were gone before we knew it. Engineering got integrated over the first year (when I left), but with a pretty light touch, and AFAIK took into the second year to complete. Apparently things got increasingly more "IBM-ified" over the years, but a suprising number of the core folks have stayed, so it can't be all misery. Maybe RH won't be completely crushed.

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.

> For example, look at kernel committers

Microsoft 12 places higher than Canonical.

Going back in time 25 years and telling someone that would have been met with Doc Brown's "who's Vice President, Jerry Lewis?"

Yeah - between that, WSL itself, and VS Code being free and actually pretty good would have been hard to imagine.

Of course, we’re in the timeline where Biff won twice.

Until you hear Gates rag on those nasty unregulated and dangerous Open Source LLMs last week when interviewed by Ezra Klein. https://www.nytimes.com/2026/09/29/opinion/ezra-klein-podcas...

> For example, look at kernel committers:

> weighted by market cap, the disparity is even more severe imo

What does "weighting commits by market cap" mean? Counting commits from people who work for companies with larger market cap more? Why would that be a useful metric?

I think the interpretation is that red hat devs are over-represented in terms of ratios compared to market cap weighting of all companies contributing to linux or similiar

basically. Comparing a company with google resources (and needs) is not really the same as RH resources (and needs). Basically, what percentage of rev/resources/profit/engineering headcount are you spending on linux?

I don't feel like this answers the last part of my question: why would that be a useful metric? If the claim is that I should be concerned with the future of kernel development because of the future of Redhat, why should dollar amounts matter rather than directly inferring from proportion of the development they do independent of dollars?

Because percentage of investment indicates how central Linux is to their business. If Linux disappeared overnight, Google would find another way to sell ads, but RedHat would disappear.

It's a reasonable proxy for things like long-term commitment and commits across the stack (e.g. audio and video, not just network and disk).

The premise of the discussion is that someone is claiming RedHat will disappear on its own, not because Linux disappears. There's no long-term commitment from an entity if it "phases out of existence". Linux disappearing because RedHat disappears is the concern.

> tailored with Watson

I think you mean built with Bob

> Redhat underpins many low-visibility, very important Linux projects, and most have no idea they are doing it

Not sure why that would have to be an issue, IBM have their own history of significant contributions to the Linux and FLOSS communities. They're not pre-acquisition RedHat but they're not far behind either.

IBM won't entertain your recommended strategy. IBM wants deep-pocketed institutional money: the sort of broad-based popularity you hope for has no value at IBM. Governments, banks and monster health care operations are the only customers IBM really cares about for their computing products.

I know IBM has been employing a large number of people to work on Linux. I'm not as concerned about the eventual wind-down of that as I might otherwise be: Linux is the global lifeblood of enterprise computing, and there are a lot of other existing and potential sources of wealth in this world to employ Linux developers. A dispersion of this talent, with the inevitable shift in focus to things that are not strictly IBM's prerogatives, might have a real benefit for Linux.

Past that, software development has suddenly become cheaper in any case: Linux is in the optimal position to benefit greatly from the good parts of that, largely due a legacy of good leadership, so perhaps employed developer headcount doesn't have the importance it has always had.

In any case, I have every faith that Linux's future is not tightly coupled to the fate of whatever Red Hat withers into: there is too much at stake for too many well-resourced entities to permit Linux to suffer at the hands of IBM. If you need evidence for this, consider the outcome of the IBM's attempt to tighten their grip on the RHEL distribution, and the stampede to rapidly established alternatives this induced. If more of that is in Linux's future, so be it.

> IBM wants deep-pocketed institutional money

Well that's the funny thing, the deep pocketed institutional money is by and large using common and popular open source projects (increasingly so).

IBM is hoping for the old mainframe days to come back, but those are long gone. The tech IBM has which companies want to use by and large comes out of redhat today.

I'm reminded of IBM's opposition of C++'s removal of trigrams [1] all because it makes their character encoding system, EBCDIC, incompatible with C++. That's the sort of lock in that IBM is hoping for and it's lock in that no (sane) business tech leader would subscribe to.

[1] https://isocpp.org/files/papers/N4210.pdf

Yes, I don't argue that IBM's ways are advisable. The revenue of the top ten big tech companies are all 2-10x greater than IBM, which is ~21 on that list.

You should update yourself on how those mainframes power z/OS UNIX, Aix and Linux workloads, alongside their older OS personalities just like VMS/Windows have done, including cloud workloads with containers even, at the usual traditional customers.

Those customers aren't going to place containers on Amazon for their systems.

The interview I linked higher in this thread specifically calls out targeting non F2000 type customers with point solutions and not taking their traditional sales motion everywhere. I think this will be quite difficult for them to do, but will see.

I am not too worried about Linux specifically. RH is a large committer, but a lot of those commits are down to a handful to very talented individuals. One of the other BigCos will sweep them up if RH culture falls apart, imo likely Qualcomm (see their large open source push recently), maybe Linaro (although I dont know much about them).

I think this approach of integration is the mistake in IBM's strategy -- they are squeezing some very slippery customer hard, and IMO this was Broadcom's mistake. The integration must go very deep, be multi-threaded, beyond a single app, OS, whatever, and it has to be a slow noose, not a hard jerk.

If I am IBM, I continue to invest in core, open source, deploy my army of PS people to build custom business solutions around that core open-source (but tailored to their specific issue), use "AI" and very strong core product engineering to reduce risk/time-to-effect, and keep pushing their entire ecosystem (rhel, hashicorp, confluence, whatever else) to customers.

Integrate deeply, then put those annual increases at 9% and build a very healthy, strong moat on a premium brand, experience and level of trust. Better to not give anyone a critical event to justify walking away from you.

> this was Broadcom's mistake

Broadcom likely disagrees, lightly snickering all the way to the bank.

Broadcom has pretty famously gone back and offered vSphere standard. I don't think the strategy works long term, and I still think it was shortsighted play to juice #s in the 2-3 year timeframe.

https://itdaily.com/blogs/datacenter/broadcom-makes-a-u-turn...

We'll see how that works in a world where someone/something with enough cash/tokens can say "hey there little AI buddy...why don't you code me up something that works exactly like Linux without all those pesky licensing things while I grab a beer". Personally, I think that's going to be kinda inevitable in the corporate world since I could say thing like "...oh, and add these 5 things Linux doesn't do, and don't reimpliment anything that isn't in this widget we want to sell. And write it in rust, because I heard that's cool." and instantly get a slimmed down, bespoke chunk of software that I/the corp/evil people can (so far?) claim ownership of.

Should be an interesting decade coming up.

...and have it fail spectacularly when deployed in an environment that requires reliability performance and high availability. Yes, I honestly can't wait to see those horror comedies unfold, but hopefully far away from me. :)

If they can vibe code that then so can anybody, it makes it a valueless exercise.

If they can vibe code that then so can anybody

Yes...that is exactly the point I'm making.

GP is saying (paraphrased) "I'm not worried about Linux because even if IBM (or Qualcomm, or ...) decides to close down their Linux efforts, the Linux devs will go someplace else and still contribute", which is true as far as it goes. My contention is it might not matter, because the big player can just as easily pay far fewer people to vibecode their own Linux workalike and take back control by displacing OG Linux in their tech ecosystem. When I can leverage all the previous work done to create Linux (aka The Hard Part), leave the licensing behind (not tested in court yet) and have my very own OS that I can vibecode/iterate any way I want independent of the Linux dev community, why would $BIGCOMPANY not consider doing that? How would it be it 'valueless' to one of these players (most of whom chafe at being in bed with the OSS community anyway)? On the contrary, what value would the Linux devs still have? Why would I even consider taking any contributions not from my own little AI playpen, since I'd be able to trivially say "hey AI...those crusty old Linux devs look like they got themselves a good idea...why don't you add that to our own private OS in the next spin. Think of a nifty marketing spin to advertise it and come up with some commercials to promote it. In the style of Micheal Bay this time".

Mantaining a private vibecoded Linux clone sounds like a source of expenses and headaches, not value.

What’s the point?

It will be easier than Android.

> they should be using super popular, high-mindshare projects to drive new wave of tailored business solutions

Could you expand a bit more on what you’re describing here? Interested to hear more.

Offer paid support for $(whatever redhat project), do all the support stuff, but also cross-sell IBM business solutions.

Yes indeed, that's pretty much what parent poster wrote.

This part:

>$(whatever redhat project)

is what I would like parent poster to expand upon, though.