[janosdebugs]

I'm not saying it's right, but a lot of people feel like open source means they are entitled to everything from getting binary releases, documentation, their bugs fixed on time, their feature requests implemented or their (sometimes deficient) PRs reviewed and accepted. All in need of careful communication which is easy to mess up.

A project that finances their development through getting paid for features will have to balance how much time they spend on paid vs. unpaid work. Getting maintenance work paid is hard.

[carlosjobim]

I'm interpreting that you're comparing paid open source work vs closed source work, am I understanding it right? Between those two options, closed source is always the better option.

[janosdebugs]

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.

[carlosjobim]

I still don't really understand the point of view. If the open source programmer don't want to do all these boring things you mentioned, they don't have to. If somebody has a problem with that, they can fork and fix it themselves, or offer to pay the programmer to do it. The unpaid open source programmer does not have any responsibility towards anybody else. Safety and maintenance is not his responsibility, it's the responsibility of whoever is using the software. If security is crucial, then they should inspect the code or pay for audited code, for example some closed source software.

I imagine a paid open source model to be where I and other users can offer money for features or bug fixes we need. The best implementation would be that users could each pool a small amount – "pitch in" – for features. Honestly, it wouldn't even have to be open source. Let users who are willing to pay developers have their say and make independent programming more sustainable. There are endless good consequences. For example, backwards compatibility might not be interesting for the open source programmer. With a bunch of users willing to pay for this, then it might become worth his time. Or language support, different platform support, special integrations.

And if the original developer is not interested in any paid work, then other programmers could fork and implement. Honestly, I think that users shouldn't even be allowed to raise an issue on Github or such places without offering monetary compensation. Fork or pay or die should be the motto.