Most enterprises don't want to buy servers with Linux, they want certain applications that run on certain capable hardware. They want certifications and guarantees. They want 24/7, guaranteed response times, and some party who takes full responsibility to fix problems, preferrably in a guaranteed amount of time. Giving this kind of guarantee requires a massive cut-down in configuration options. Therefore almost every HW and SW vendor supports only a very limited set of OS flavors.
It is pointless to say that vanilla systems can be very stable, have a high uptime, and perform nicely. The question is who is willing to guarantee that for a certain customer application on a certain hardware.
Check out the major HW and SW vendors and see which Linux releases they offer support for. In most cases, you will see RHEL and SLES, and quite often, nothing else. The HW and SW vendors spend engineering + QA efforts to ensure compatibility with distributions. The upgrade-compatibility guarantee of the enterprise distributions helps them save efforts: certify once, and keep certified until end-of-life of the distribution. This upgrade-compatibility implies a commitment of the distribution vendor to ensure API and ABI stability, a commitment that the community deliberately refused to make, as every LWN reader knows. This stability, plus availability of bug fixes and security fixes, is what makes enterprise Linux attractive (new hardware enablement is less important, it can be achieved with virtualization as well).
For a HW or SW vendor, certifying and releasing a product for RHEL5/6 and SLES10/11 is considerable effort, but it's manageable. For many vendors, anything else isn't, unless backed by a very large customer with a very specific demand and highly skilled own staff.
"Never Change a Running System" is a very important paradigm in the commercial Linux world as I know it. Customers can be extremely conservative. When an enterprise Linux distribution finally reaches end of life after 7 or 10 years, customers start requesting support for that distribution for another 5 years or more. The rapidly moving code base of the community distributions is out of the question for these customers, and so are vanilla kernels. A company trying to make money with Linux may consider this irrational, but it would be good advice to be careful telling that to a potential customer.
The enterprise distributions receive QA not only from their vendors, but also from partners and IHVs / ISVs around the globe. That adds up to considerable efforts, and considerable efficiency in finding and squashing bugs. In this way, many bugs have been found in code that had already been reviewed by two upstream communities (upstream project and Fedora/OpenSUSE, and no, it's not always the back-porters and "Frankenkernel" engineers who are messing it up). The superior quality of the upstream community releases is a myth. More often than not, the "thousand eyeballs" turn out to be just two. The upstream review/QA process is good and extremely important, but it's not by definition superior to everything else.
Last but not least, even if that's unpopular on LWN, the KABI commitments of the enterprise distributions make it possible for customers to deploy third-party kernel modules without risk.
I used to think along the lines expressed by many commenters on this page. I even tried to convince my bosses to support vanilla kernels (couldn't figure out .config, though). I had to realize I was wrong. At least the market segment my employer is addressing is served very well with the current "Enterprise Linux" model.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds