[acdha]

That's the value pitch for RHEL, where it's understandable — whether or not you like the enterprise IT model of avoiding upgrades as long as possible, there's a ton of money in it.

I think the gap is the question of how many people there are who want enterprise-style lifetimes but don't actually want support. If you're running servers which don't need a paid support contract, upgrading Debian every 5 years is hardly a significant burden (and balanced by not having to routinely backport packages). There's some benefit to, say, being able to develop skills an employer is looking for but that's not a huge pool of users.

I think this is the reason behind the present situation: CentOS' main appeal was to people who don't want to pay for RHEL, and not enough of those people contribute to support a community. That lead to the sale to Red Hat in the first place and it's unclear to me that anyone else could be more successful with the same pitch.

[ghaff]

>who want enterprise-style lifetimes but don't actually want support

But lifetimes are support. Support isn't just, or even primarily, about making a phone call and saying "Help, it's broken." After all, there's nothing keeping someone from taking a snapshot of a codebase and running it unchanged for 10 years. Probably not a good idea if you're connected to the network, but certainly possible.

[acdha]

I was thinking more about _why_ people want that. If you're changing the system regularly, upgrading is valuable because you don't want to spend your time dealing with old software or backporting newer versions. Most of the scenarios where you do want that are long-term commercial operations where you need to deal with requirements for software which isn't provided by the distribution, and in those cases they likely do want a support contract.

I'm not sure there are enough people left who have the “don't touch it for a decade” mindset, aren't working in a business environment where they're buying RHEL/SuSE/Amazon Linux/etc. anyway, and are actually going to contribute to the community. 100% of the people I know who used it were doing so because they needed to support RHEL systems but wanted to avoid paying for licenses on every server and they weren't exactly jumping to help the upstream.

Red Hat bought CentOS in the first place because they were having trouble attracting volunteer labor and I think that any successor needs to have a good story for why the same dynamic won't repeat a second time.

[ghaff]

>I was thinking more about _why_ people want that.

I think there are two primary reasons.

1.) A developer wants to develop/test against an x.y release that only changes minimally (major bug and security fixes) for an extended period of time.

2.) The point release model where you can decide when/if to install upgrades is just "how we've always done things" and a lot of people just aren't comfortable with changing that (even if they effectively already have with any software in public clouds or SaaS).

I largely agree with your other points.

[acdha]

Re: point 2, I don't know how different that is for stable distributions — e.g. if you're running Debian stable you're in control of upgrades and you can go years without installing anything other than security updates if you want.

Re: point 1, I'm definitely aware of that need but the only cases I see it are commercial settings where people have contractual obligations for either software they're shipping or for supported software they've licensed. In those cases, I question whether saving the equivalent of one billable hour per year is worth not being able to say “We test on exactly the same OS it runs on”.

[stjohnswarts]

Have you worked in banking or aerospace? 10 years of needed support/stability/predictability is nothing unusual. The old if it ain't broke don't fix it mindset prevails.

[acdha]

If they need that for their business are they really not using Red Hat?