Now, we have larger projects where it is rare for one people to have a complete understanding, and the main value is a person to reviewing patches and bugs to make sure the changes align with the larger goals/path for the project. There is little incentive for a maintainer to do this, aside from wanting to limit forks.
Paying for that review might be the way to keep this whole model sustainable.
“Here is my pr I attach x$ payable when it is merged” and allow me to add $ to other prs.
I have been waiting year + for multiple feature in some projects that have open prs and for one I would easily bid 100-200$
I'm not sure why I seem to be in the minority on this. Maybe I've just had bad luck in that most of the issues and PRs I've submitted to open source have been ignored. Hell, I'd prefer a "thanks but no thanks" or even "fuck you" over radio silence. The typical response to this frustration of mine is "just fork the code, bro", which is absurd because forking should be a last resort for software that thrives from having a community.
Does it? I think a lot of software projects which are not as huge as the Linux kernel etc. thrive best with a tight core development team, and not from a "community" if you mean that word beyond "users".
Look at it from the point of view of a maintainer. Not sure if you've ever tried. People want to pull your software towards a million incompatible directions. They write some big patch and then get angry if you don't merge it.
My advice: consult the maintainers first whether they agree with your idea and whether they are open to considering your submission. You still won't have a guarantee that it will be accepted, because that's their final say. But at least you won't spend effort coding up something that they could already tell you they don't want to have in their software.
This is true, of course, but having a community is completely orthogonal to whether software is open or closed source.
But you can very much allow bug reports and feature requests in public while developing proprietary software and you can also very much work on a project alone or with a small group without being open to random patches, contributions or requests and be open source / FLOSS.
The key definitional question is the license, not any of the cultural stuff.
In fact, github is arguably a poor substitute for a community. Look at how communities such as the ones around the linux kernel or cPython communicate. It sure as shit isn't through issues or pull requests. Or rather, perhaps, the limited technical communication that an issue tracker is good for is not a valid large community consensus building mechanism.
> The key definitional question is the license, not any of the cultural stuff.
For direct modification, certainly. For customization, maybe. For ignored issues like the parent to my original comment was bemoaning? Maybe LLMs are good enough that we are almost ready to say "Make me a custom version of Photoshop" and then it doesn't matter.