Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and you reject it because you want me to pay you first, I'm dropping your software without a second thought.
You have a point. On the other hand, considerable part of maintainers burnout comes from arguing with well-meaning strangers that come with PRs that are (usually) useful, but don't fit the established codebase well. By only accepting PRs from members of a collective, the amount of drama is reduced.
If someone is going to just close these questions, then I will drop them as it’s not open source I want to be a part of.
I am okay with paying for software. not okay with paying to find out my feature request will get denied
The requirement to be a member of a collective is a filter. For popular projects it will likely do more good than bad. For niche projects, it might be worse than no filter.
They were explicitly talking about PR for a bug, not unwanted feature.
Yeah, sure, there is occasionally low quality bug fix that's problematic issue (bug should be fix but the code to fix it is garbage and nobody wants it) but I think that's rarer problem
Ha, it sounds like more work to replace a free piece of software with something else than to use your own patched version. Especially if you have to replace it with something inferior or proprietary. If there are better-maintained alternatives, why did you adopt it in the first place?
Pull requests take work to review and test. You shouldn't take that for granted and assume everything will be merged for free.
If you manage to review and test fixes faster than the original, or if you're willing to add features and maintain the code yourself, go and promote your fork!
Nonsense. You think signing yourself up to maintain a patched version of someone else's code for eternity is better than using someone else's code? You have to sign up for upstream CVEs, keep updating the upstream base and rebasing your patches on top.
>Especially if you have to replace it with something inferior or proprietary. If there are better-maintained alternatives, why did you adopt it in the first place?
False dichotomy. A library is measured in various dimensions - how well-maintained it is, what features it has, OS / hardware dependencies, performance, etc. Something that is better in one dimension might be worse in another dimension, so that there's no single objectively better library.
>If you manage to review and test fixes faster than the original, or if you're willing to add features and maintain the code yourself, go and promote your fork!
I have my own work to do, not maintain forks of other people's code.
> It may seem unfair to expect people both contribute PRs and also financially back this project. However it is important to remember the effort in reviewing and merging a PR is often similar to that of creating the PR. Also the project maintainers are committing to support that added code (feature or bug fix) for the life of the project. Pull Requests from non-Patrons, that are of significant value to the larger Fody user base, may justify the effort in reviewing and merging.
Ultimately if you care enough about Fody to spend over a hundred dollars worth of your time contributing to it, you probably care enough about Fody to drop them three dollars.
Fine. But if my code is useful, and it ends up convincing more users to become Patrons, will I get any financial gratification from the Fody maintainers? Or are any profits from this contribution going solely to the maintainers?
In your average open source project, backing it is separate from using it and contributing code to it. My contribution would therefore benefit all people, including those who cannot pay. But the Fody maintainers consider them to be freeloaders and unwelcome people, so I have reservations about contributing and what the benefit from my contribution would be to others. I'm not working for free for a for-profit entity.
No, I really don't.
https://github.com/keepassxreboot/keepassxc/pull/8500 - I was randomly reading keepassxc's manpage and spotted a curious option, spent some time spelunking through the code and history to discover that it was an outdated option, sent a PR.
https://github.com/python/typeshed/pull/8617 - I converted one of the scripts I use in my DE from shell to Python, saw that VSCode has this new fancy typing support for Python, quickly found a basic bug in the type definitions for the os module, tested a fix locally, sent a PR.
https://gitlab.gnome.org/GNOME/gtk/-/issues/5250 - I found an issue with copy-paste on my phone, investigated it all the way through to the GTK stack, found the commits that introduced the issue, created a distro patch for it while discussing it with GTK upstream.
https://gitlab.alpinelinux.org/alpine/aports/-/merge_request... - I noticed that gnome-passwordsafe crashes some times, debugged it to discover that it was missing a dependency, sent a PR to the distro package to update the dependencies.
etc etc. I've made lots of fixes like these. I have no interest in paying for each and every one of them. The projects are all better off for fixes like mine and gatekeeping them on payment would've been nothing but their loss.
Also, to be clear, there is nothing special or unique about what I do. All large community projects where the users greatly outnumber the developers continue to work because of PRs like these from their users.
Wouldn't you first check the license and contributor agreement before doing such a thing, even on random FLOSS projects?
Unless they are not disclosing their policy in the contributor agreement or the license, I don't really see a problem here.
BTW, the reason I mention sending PRs for bugs I encounter is that, when I do encounter a bug I don't immediately file a GH issue and make it the maintainers' problem. Instead I act upon it just like the maintainer would, by checking the source to figure out why the bug is happening, `git blame` etc to see what commit added that code, whether the issue I'm encountering was already identified or discussed when that code was committed, and so on. So as a result of doing these things I often end up either knowing my issue is by design and that I was doing something wrong, or end up having enough knowledge to be able to construct a bugfix myself.