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.