Comment by sfRattan

> When the next version of redis comes with a more restrictive license, or if features are removed, I just stick to a previous one. Maybe I fork it myself if it's really important for me. Probably, we will be many doing so, we will regroup, share our modifications and improvements. I've experienced this kind of colaborative maintenance of some dead project a couple of times in the past, and all te governance that was ever needed was a mailing list.

This situation is a one kind of sudden, unplanned migration. You seem to assess it as less stressful than I would. I'd also be concerned about security generally, duplication of effort to maintain the private fork, and potential retaliation if total secrecy isn't kept by the fork's maintainers.

Your reasoning makes sense for choosing software to use as an individual, but not when choosing software as an organization or when choosing software to integrate into software you distribute for others to use.

Your reasoning also makes sense for maintaining software that has a relaxed threat model (i.e. typically runs or can be made to run in isolation from any network). But the examples you pick (n8n, redis, elastic search) are most often used on perpetually networked computers where security a larger concern and I don't know that I'd trust a private, ad hoc group to keep a secret fork (in potential violation of a "fair" source license) up to snuff.