> why would a company ever do this?

Distro kernels are general purpose and include a lot of stuff you do not need.

A custom-configured kernel is much smaller and (consequently, theoretically) more secure.

Not sure I follow. A custom kernel doesn’t need to based on master.

I was thinking of Red Hat (for example), that pays kernel developers and regularly tests and backports features for its paying customers. That means having a finger of the pulse of the kernel tree, and trying changes to decide whether it might be worth to port them to their supported kernel branch (which lags behind master).

Ah, Red Hat is indeed a good example. Thanks for clarifying.

If you have 100000 servers it's in your interest to test HEAD on 100 of them to be able to catch and bugs before they hit a release. That's how open-source should work!

Why not run 1-2 releases behind and test/qualify a later release?

A commenter below gave a good example of a company that would need to run a bleeding edge kernel (Red Hat). The vast majority of companies would never need to do that though.

> Why not run 1-2 releases behind and test/qualify a later release?

This may work for most people, but not all. It's easier to get things fixed while developers still work on something, than weeks/months later. Also if you have not most-popular hardware/software configuration, testing done by others isn't necessarily sufficient for you.

Maybe your company needs that super duper new feature that's on master. Or you're Google scale and that 0.5% improvement in IO throughput would save you millions a year. You wouldn't want to wait until it hits the stable branch if possible.