Not at all, but we are talking on a submission about getting open source work paid. I've done my fair share of unpaid open source work and it was a ton of fun. I've had a lot of very good experiences with the community coming together to resolve an issue, but I've also had bad experiences, mostly with larger entities consuming said projects and not willing to contribute in any way, shape, or form.

With that premise, recently I've experienced more and more release engineering asks popping up around open source: SBOMs or other compliance reports, regular dependency updates (dependabot and friends), regular releases, support cycles, supplying a DEB/RPM/APK repos, shipping on Snap, Homebrew, Winget, Chocolatey and who knows where, sign with cosign, GPG, x509 and so on. You get the picture. I have yet to meet an engineer who likes to do release engineering in their free time. It's hard to test, it's hard to automate and is super sensitive because if you mess it up you leak keys or compromise user systems.

This is something I believe the poster needs to address, otherwise their platform will be full of projects doing feature-driven development with important safety and maintenance concerns left by the wayside. Although I have seen a few working models, I don't know the solution for all of open source. I believe that if we are talking about viable funding models, funding needs to address both feature and maintenance work and not tip the scale too far in one direction.