Supporting old releases of infrastructure software becomes more and more expensive over time. Thats why upstream generally set time limits. E.g. Python M.N will be supported for X months. And then we'll review. The higher up the stack you go, the smaller the user base, the less resources to do long term support, and often the smaller the codebase - so it hard to draw a predictive line... but nearly everyone eventually says 'No, I won't fix that bug in that old release: you can use a new release.'
The challenge then, is when that new release depends on a lower layer component that is not available to the user. For instance, recent Sphinx no longer runs on Python 3.2. There are four things a user can do: 1) suffer the bug they wanted fixed. 2) Fix it themselves [perhaps by backporting from a fix in the new release]. 3) Upgrade the dependency (e.g. from Python 3.2 to 3.3). 4) Complain at upstream that this change has occurred.
Red Hat provide engineering services to their users to do 2) for them for a range of software that typically goes about half way up a stack. E.g. Linux, libc, Python, not-Django, not-sqlalchemy etc etc.
Customers of Red Hat then will have one of two discussions with the top of the stack: a) We're willing to help support our old dependencies, please just keep it in CI and we're there with you. E.g. 2) above. Or b) we're using your software but we need Python 2.6 [Now, until recently it was 2.4 :).] - e.g. 4) above.
Now a) isn't all sunshine and roses - supporting 2.6 means not using anything new introduced since it was frozen, unless there's a backport of it... if a backport can even be done. I support backports of The Python stdlib modules traceback. linecache and unittest - and for all of them I support 2.6 because users tell me they still use 2.6. Thats a bit of column a) and bit of column b) - I don't deeply care about 2.6, but I'm willing to ensure at least syntax compat and tests passing: deeper analysis or effort I'll push onto folk that directly care.
I think Alex intends to take aim mostly at b) above, but he appears to blame RH for that existing. RH are not the only organisation offering long term support for infrastructure, merely the most successful (AFAICT). Aiming at RH specifically is IMO unreasonable: they're merely enabling folk to ask the question about the next layer up. AIUI all RH's patches are publically accessible. We can
criticise RH for how readily accessible they are: See https://lwn.net/Articles/430098/
for context on that.
There is no onus on open source projects to say 'yes' to a) above: its entirely reasonable to say 'hey, your dependency is no longer supported upstream, we're not going to try and support it downstream.' There's also a half-way house: "If you have a patch that doesn't detract from our code base, sure we can incorporate it." Or "You're welcome to run a branch of off master for your needs, and to share the bugtracker."
And for b) projects need to learn to say "no" more. Supporting unsupported dependencies has real costs that hold code bases back: they make them unclear, hard to support and fragile. Upstream can't take on the job of supporting everything that once was.
So - push users towards the half-way house a: a branch of their own... and if thats too much effort, and there's not enough interest to spin up a consultancy around it... well thats a pretty clear sign that its not really needed.https://alexgaynor.net/2015/mar/30/red-hat-open-source-community/