Sadly the article neglects the single biggest problem in open source: very few people, or companies for that matter, are actively willing to contribute in any way, whether it be contributing with code or financially supporting a project. Even big and popular open source projects are most often self-funded and it's people dedicating their own resources and spare time to support them. All of the things in the article are more than valid but creating an open source project that can potentially pay your rent is arguably just as hard as adding another letter to FAANG. As a matter of fact the letter might very well be an easier task.
That's not always true. Turning an open source project into a stable business is difficult, but making a bit of money on the side isn't if you do something important and do it well. If you make the best breakfast in the morning people will come; If your library is the solution for (say) embedding python in COBOL and businesses use it, chances are they won't mind being able to pay for support. The first customer is the hardest to get but even relatively niche programming languages can have hundred dollar bug/feature bounties.
Slightly unrelated: I think the best way to encourage people to contribute is to have a well documented, time-specified, friendly path for contributors.
For example: (I won't name the project) I recently made a PR to a (definitely well known on HN) programming language's library and there was a fairly counterintuitive CI failure. A bunch of people turned up to provide completely useless advice that I had already tried, and promptly disappeared - it's now one of a 200 hundred ish PR queue that is largely full of things that people have wanted to work on but can't because the maintainers (as well as being busy) are dancing around doing a new thing every day rather than deciding whether to close or merge.
PR-hell is a situation where a process obviously helps, like in corporate projects (Look at how Microsoft deal with GitHub issues for example) where someone will actually go through and decide.
I said most cases. What you are describing are the exceptions, not the rule. I don't remember how he phrased it exactly but about a year or two ago Andy Mueller tweeted that his biggest wish is that scikit-learn would eventually receive enough support to be able to have the maintainers work full time on scikit. Think about this for a second: I can't recall seeing a single ML project that doesn't rely on scikit to a certain degree and the core maintainers are 8 iirc. That's pretty sad if you ask me.
