But to the point you were making - it's not impossible that browsers could evolve to the point where our current version of React is unusable and it's been long relegated to the buzzword graveyard. Of course in that situation we'd have to maintain our own React branch or rewrite in whatever was a popular front-end framework at the time.
My point is that getting stressed out about the front-end JS framework churn isn't helpful to anyone. Pick a stack and stick with it, and only move when it's simply not productive to stay.
What form would the transaction take?
I am low-key building a marketplace for this, because this really should exist. The problem, as a marketplace, is identifying projects both important enough that people will pay for it and aren't* already functionally owned by a company that has a vested interest in their own project management.
(Are you a maintainer who's interested in something like this? Are there projects you would pay for this for? I want to hear from you. com dot edropple at ed)
You always allow people to move forward their subscriptions, but never backwards. You provide migration paths for each supported release.
People will pay for it.
It's a little much to ask from an unpaid open source maintainer, and if you really want it that bad you should be willing to pay for it. Companies like Red Hat have made a living off of people willing to make that tradeoff.
I mean, you could have separate bugfix and feature releases for a relatively low cost, but that would only alleviate the problem for the duration of a release cycle.
Ah, the optimism of youth. Frameworks don't rust if you don't mind sticking with the security bugs of 10-year-old kernels. If you need to upgrade your OS, you need to upgrade your programming languages, which means you need to upgrade your frameworks.
Everything rusts pretty quickly. Maybe you don't need the new features, but you definitely need the new bugfixes.