4 ms·

>And if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy. Issues I can understand. But if I s

>And if you open an issue or pull request and you're not on the OpenCollective, it's usually immediately closed, by policy. 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.

deleted 4y ago
[deleted]
krasin 4y ago
>Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and it gets rejected because I also need to pay, I'm dropping your library 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.
- Arnavion 4y ago
  Yes, I'm sure it makes sense for them to have this perspective. And it also makes sense to me that if I'm not going to get the bugs I encounter fixed, even if I make the effort to fix them myself, then my effort is better spent on a project where that will happen. Their loss.
  - knicknic 4y ago
    I don’t pr unless it will be obviously taken without first opening an issue. This prevents me wasting time testing and writing code. 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
- pharmakom 4y ago
  Must get awkward when the PR from a member of the collective comes in with a tonne of issues though? They are paying so may feel entitled for it to be merged.
  - krasin 4y ago
    They are entitled for attention, yes. And if they respond to code review and ready to address comments, they will likely get it merged (depends on the project and the PR, obviously). 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.
- ilyt 4y ago
  > 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. 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
chrisandchris 4y ago
I can understand too, but I won't even dig into your code when I need to pay you first. Shouldn't you pay me too for opening the pull-request, because "I did your work"?
lelanthran 4y ago
> But if I spend time grokking your code, fixing a bug and submitting a PR, 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.
- Arnavion 4y ago
  I do check the LICENSE and CONTRIBUTING files before I contribute. It is likely that I would have not contributed to such a project in the first place. It doesn't change my point, namely that a project where I cannot contribute fixes for bugs I encounter is one that I have no desire to use. 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.
evv 4y ago
> I'm dropping your software without a second thought. 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!
- Arnavion 4y ago
  >Ha, it sounds like more work to replace a free piece of software with something else than to use your own patched version. 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.
pie_flavor 4y ago
The page I linked was the FAQ, which addresses this exact point: > 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.
- Kwpolska 4y ago
  > 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.
- Arnavion 4y ago
  >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. No, I really don't. https://github.com/keepassxreboot/keepassxc/pull/8500 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 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 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_requests/34979 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.

deleted 4y ago

[deleted]

krasin 4y ago

>Issues I can understand. But if I spend time grokking your code, fixing a bug and submitting a PR, and it gets rejected because I also need to pay, I'm dropping your library 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.

Arnavion 4y ago
Yes, I'm sure it makes sense for them to have this perspective. And it also makes sense to me that if I'm not going to get the bugs I encounter fixed, even if I make the effort to fix them myself, then my effort is better spent on a project where that will happen. Their loss.
- knicknic 4y ago
  I don’t pr unless it will be obviously taken without first opening an issue. This prevents me wasting time testing and writing code. 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
pharmakom 4y ago
Must get awkward when the PR from a member of the collective comes in with a tonne of issues though? They are paying so may feel entitled for it to be merged.
- krasin 4y ago
  They are entitled for attention, yes. And if they respond to code review and ready to address comments, they will likely get it merged (depends on the project and the PR, obviously). 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.
ilyt 4y ago
> 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. 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

chrisandchris 4y ago

I can understand too, but I won't even dig into your code when I need to pay you first. Shouldn't you pay me too for opening the pull-request, because "I did your work"?

lelanthran 4y ago

> But if I spend time grokking your code, fixing a bug and submitting a PR, 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.

Arnavion 4y ago
I do check the LICENSE and CONTRIBUTING files before I contribute. It is likely that I would have not contributed to such a project in the first place. It doesn't change my point, namely that a project where I cannot contribute fixes for bugs I encounter is one that I have no desire to use. 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.

evv 4y ago

> I'm dropping your software without a second thought. 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!

Arnavion 4y ago
>Ha, it sounds like more work to replace a free piece of software with something else than to use your own patched version. 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.

pie_flavor 4y ago

The page I linked was the FAQ, which addresses this exact point: > 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.

Kwpolska 4y ago
> 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.
Arnavion 4y ago
>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. No, I really don't. https://github.com/keepassxreboot/keepassxc/pull/8500 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 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 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_requests/34979 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.