That might be right for side-project in the beginning but what happens when they grow and thousands or even millions use them? There might come a point when you have too much work and not enough time to fix the bugs or develop new feature requests.

You don't owe anyone a bug fix. They can fix it themselves and merge request.

Sometimes, the OSS (a popular) owner can't even care to merge pull requests. Because it also takes time to read the code too and make decisions to merge.

What you're saying seems like a potential false dichotomy; developing open source software can be as profitable - sometimes more profitable - than developing proprietary software.

It can be. But you shouldn't expect it to be if you don't offer support, a product, etc... Lots of these recent threads are basically people who just release something into the wild, put no effort into monetizing and then wonder why they're not getting paid...

Yep, ok. I sorta feel that the 'lean financing' approach is to not add any monetization at all -- because it may introduce externalities -- until a project is producing significant value and has (necessary) infrastructure/runtime costs.

Roughly speaking: focus on producing something of value, and then the monetization strategy should follow naturally if the project succeeds.

At the same time, I think it's important to focus on reducing total cost of infrastructure, because doing that increases the size of the audience who can participate and reach a sustainable value threshold.

(and one caveat to that: long-term cost is often minimized thanks to high-quality, durable systems that often have high associated price points. it may be necessary to have entry-level alternatives available too, although I don't think that's an excuse for providing poor-quality systems, or for entrenching high price points on legacy trusted systems)