Projects with bigger problems

> given that the maintainer can log off forever, a solution based on "maintainer takes action" is not enough.

If the sole maintainer "logs off forever" (or a very long time), then there is a much "bigger problem": the project is just orphaned which means any discussion in release delays or other lifecycle questions is pointless.

> This requires us to all accept that BigCorp will fork a lot of interesting projects, and that we have to consider "hostile forks" by big companies as "normal" - it's just BigCorp taking on responsibility for things they depend upon.

I miss what there is to "accept" or "not accept" here... The ability to fork is intrinsic to software freedom. As is the freedom to pick the fork you prefer. Forking is pretty much the essence of free software and it happens frequently, that's just the way things are. BTW "hostile" is a very binary: forking has many shades of grey.

BTW any decent BigCorp has internal mirrors of most of their dependencies (to avoid outages if nothing else) and how they update those is effectively implementing "private cooldowns" already. The richest ones implement all sorts of human and/or automated reviews and inspections on updates already (which other "cooldowns" can happily rely on, as already noted in the main article)

These internal mirrors often have extra commits too, which may or may not be submitted upstream. So I guess you could already call them "forks" depending on some artificial set and personal thresholds.