Notable by its absence [LWN.net]

Notable by its absence

Posted Jan 3, 2025 6:08 UTC (Fri) by alison (subscriber, #63752)
Parent article: Some things to expect in 2025

Inspired by reading Corbet's ever informative report about contributors to each kernel, the looming question is what effect Intel's evident difficulties will have. As has oft been noted, many companies will support developers who write device drivers for their own hardware or contribute to arch/ for their processors. Fewer are employers who are willing to underwrite more fundamental, hardware-agnostic improvements and innovation in kernel/, tools, and tests. Among the latter group, the long-term principal contributors have been Intel and Redhat. Samsung, Google, Meta and Huawei among others have been stepping up, but filling a hole left by a diminished Intel contribution would be painful indeed.

to post comments

Notable by its absence

Posted Jan 3, 2025 15:40 UTC (Fri) by willy (subscriber, #9762) [Link] (6 responses)

I think you missed at least one employer who makes significant contributions to mm, fs and other core functionality ;-)

It's interesting to watch where the contributions come from; originally it was mostly distros (RH, SuSE, etc). Then the traditional Unix vendors (IBM, HP, SGI, Sun, Digital, etc). Then came the consumer HW vendors (as you say, Samsung, Huawei, etc). The big employers right now are the cloud vendors (Google, Meta, Microsoft, Oracle, Huawei, Alibaba).

We survived the Intel layoffs of 2016. Anyone good got snapped up immediately, and I can promise you there is no shortage of demand to hire people who already have dozens of kernel commits. People will undoubtedly change their focus when moving to a new employer, but the pace of contributions will not slacken.

Notable by its absence

Posted Jan 3, 2025 22:55 UTC (Fri) by cschaufler (subscriber, #126555) [Link] (5 responses)

I can't agree that the pace of contributions will not slacken. Think of the maintainers of IA64, who's specific skills may not translate well to other architectures. Maintainers who leave one job frequently find reduced support for their projects in the next. Some maintainers who are let go decide to leave the open source community entirely, either by taking unrelated positions or retiring.

Notable by its absence

Posted Jan 4, 2025 13:45 UTC (Sat) by willy (subscriber, #9762) [Link] (4 responses)

Yes, when Intel laid me off in 2016, I had a good long think about whether I wanted to continue working on the kernel and indeed in open source at all.

Ultimately I decided to keep working on the kernel, but not on DAX. Which decision has been vindicated, unfortunately, by Intel's inability to bring a successful product to market.

But I disagree that the hypothetical ia64 maintainer would have few transferrable skills. An architecture maintainer must be a jack-of-all-trades. They typically know a fair bit about mm, fs, firmware, and device drivers.

Anyway, my point is that kernel hackers remain in high demand and are only out of work for as long as they want to be (modulo other constraints like work visas and so on). You really have to try hard to be an unemployable kernel hacker.

Notable by its absence

Posted Jan 4, 2025 18:30 UTC (Sat) by alison (subscriber, #63752) [Link] (3 responses)

willy notes:
>kernel hackers remain in high demand and are only out of work for as long as they want to be

Clearly! But a kernel hacker's next gig might be writing out-of-tree scheduler extensions for fintech, or supporting a private fork of bcachefs. We can't count on new employers being as generous with core-kernel support as the biggest code contributors have been historically.

Notable by its absence

Posted Jan 4, 2025 19:54 UTC (Sat) by willy (subscriber, #9762) [Link] (2 responses)

That absolutely could happen! It's happened before; one could include the Lustre folks who, while not closed source, are out of tree and make few contributions to the mainline.

I certainly have had offers to do closed source projects ... and haven't accepted them. I used to get offers to be CTO at various startups which is hilarious from multiple points of view (I would be a terrible CTO). I was also offered the opportunity to work on NVMe firmware.

I'm not saying I can't be bought, but it'd have to be a lot of money or a really interesting project for me to find it worth doing. I did take close to three years off from kernel contributions while I was at Intel to work on NVMe, and I think we can all agree that worked out well for everyone.

There are still a lot of companies who are interested in hiring kernel developers to contribute to upstream. Anecdotally, that seems to be the largest pain point -- they want to get their changes upstream but don't know how to do it. Hiring someone with a track record of getting patches upstream is a good way of solving this problem with money.

Notable by its absence

Posted Jan 6, 2025 4:41 UTC (Mon) by tim-day-387 (subscriber, #171751) [Link] (1 responses)

Slightly off-topic, but Lustre is still working (perhaps slowly) towards inclusion in mainline. The code is in much better shape compared to when the client was kicked out of staging. Of course, there's still a lot more to be done. But I'm optimistic Lustre could land in mainline someday.

There's a tracking ticket in the Lustre Jira and an update from James Simmons at LUG24 about the ongoing work for those curious.

Notable by its absence

Posted Jan 6, 2025 16:47 UTC (Mon) by joib (subscriber, #8541) [Link]

Seems the big mistake last time was that the in tree version was more or less a fork occasionally maintained by a few people, whereas users and developers ignored it and continued with the out of tree version.

If they want to make a success of it this time, I think they will need to adopt an upstream first approach.