Rug pulls, forks, and open-source feudalism

It absolutely does; the article discuses this, and at no point did anyone describe license-changes as "destructive". The community/competition also has the right to fork the project when there's a change they don't like (with no assurance of success).

> Realistically, what license do you pick on day one that doesn't doom you to failure?

That's my point exactly! If I have a slice of cake, I can either eat it now or save it for later - not both. You have to pick a poison: AGPL or a custom license will prevent hyperscalers hosting your service, but will slow adoption. MIT or BSD will juice your growth and leave you vulnerable to SaaS alternatives. Switching licenses after achieving popularity leaves you vulnerable to forking - this strategy has been popular lately, but valkey proved that it carries a major risk as well.

AFAICT, there's no license that assures one can maximize adoption, and capture most of the projects value, because these two objectives are in tension. Continuing with the cake theme: the options for project authors are growing the cake and likely capturing a slice of it along others, or having the entirety of a much smaller cake.

edit: the article does outline a strategy that maximizes upside for project author: make outsider contributors sign CLAs, and ensure your org is responsible for most of the contributions.

I wouldn't really consider that a separate strategy. When using AGPL and accepting outside contributions in this for-profit scenario, having a CLA (or stronger e.g. CAA) is essentially mandatory. Ditto when using some non-OSI source-available / Fair Source licenses with similar protections against competing SaaS use.

Otherwise, without a CLA, even the project creator effectively can't sell access to an improved/modified hosted SaaS version: each third-party contributor is licensing their code contribution under AGPL, and they are afforded the exact same anti-SaaS protections. So with third-party contributions and no CLA, even the project creator would need to provide the full source code of their SaaS to users, which typically makes the business non-viable.

But meanwhile many folks in the industry are extremely hostile to CLAs, for whatever reason. There are several examples on this page, including one commenter claiming AGPL + CLA is "open-washing". And folks are even more hostile to Fair Source and other non-OSI source available licenses, again several examples on this page, or any time this topic comes up here.

> You have to pick a poison: AGPL or a custom license will prevent hyperscalers hosting your service, but will slow adoption.

IMO the issue is more severe than just slowing adoption; in many cases, using a non-permissive license from day 1 outright kills adoption. And that's really unfortunate, because a few decades ago there was a robust market for software written by bootstrapped independent software vendors, without widespread dogmatic demands for specific license terms. The current status quo is going to lead to a lot less independent software creation, because there's no obvious path to financial self-sufficiency (let alone profit) for such projects.

So with that context in mind, I think the commenter at the top of this subthread is 100% correct. There's currently no way to thread the needle between community licensing demands, and the risk of larger companies capturing all the profits. Logically the only solutions would be to convince users to lessen their dogmatic licensing expectations, and/or to shame cloud vendors into more sustainable behavior regarding FOSS projects, but both of those seem fairly impossible.