4 ms·

You want other people to do work for you, for free. That's completely understandable.

phkahler 6y ago
>> You want other people to do work for you, for free. That's completely understandable. The parent poster was talking about submitting a Pull Request. In other words, contributing the work for free. I suppose expecting someone to look at it might be asking them to do something for free, but if that's a problem then I agree that Github should have the option of not having the button on a project at all. Or maybe you thought PR stood for Problem Report, in which case expecting it to be looked into by someone is an expectation of free labor.
- massysett 6y ago
  Examining the pull request is work, as is integrating it into the software and maintaining it in the future. The parent wants the project to do that so that s/he does not have to fork it him/herself. In other words, the parent wants someone else to do work, for free. Free Software is about the freedom of the user - freedom to distribute, freedom to study, freedom to use, freedom to modify. Somehow people have managed to pervert this so that it not only means "free as in free beer so that I can use it" but even "free beer so that OTHER PEOPLE can do work that I want done, for free." There is absolutely no entitlement to this.
  - macksd 6y ago
    I'm sorry I simply cannot understand how you can read the entirety of my comment and see that as entitled and wanting something for free. I could fork a project and make the fix in my own repo. In fact you have to do that to make a pull request. I even specifically lay out scenarios where I absolutely agree it's not a good return on time invested for the maintainers to bother. But if I forked an open-source project every time I had a bug fix that required time from the maintainer that's worse for everyone. My point is that even though I fully understand and support where the litestream policy is coming from, for anything beyond a personal project I think some flexibility in accepting outside contributions is a win for everyone. I'll do all the work I can without having rights on the project. I'll sign over all my rights. Have tests? I'll run them and post the results. But a rigid "love it or fork it" attitude is a lose-lose.
    - yawaramin 6y ago
      > But if I forked an open-source project every time I had a bug fix that required time from the maintainer that's worse for everyone. Who is 'everyone'? Does that include the maintainer? If so, why is it worse for them? > a rigid "love it or fork it" attitude is a lose-lose. How so? Who exactly is losing, and what exactly are they losing?
      - macksd 6y ago
        "Everyone" includes other users who would benefit from the fix, the PR author who can continue using the same version as everyone else, and yes, the maintainer who is foregoing even the possibility of the fix without starting from scratch. As I said in my comment, it makes total sense to me to look at a major change or a risky fix and say "no this isn't worth my time". But I'm sure we've all had those bugs where they take forever to track down until eventually you find a simple problem in code that is obviously an error. To not even take a look at it, as a rigid matter of policy? Yes, I absolutely think open-source maintainers would be missing out on saving some larger efforts. edit: And to be clear, I freely acknowledge the inverse in my original comment. As TFA explains they were seeing a lot of PRs with unintended side-effects that were complex and counter-intuitive. At no point have I said people MUST accept this as part of the terms of a copyleft license as the original replier seems to think. I used phrases like "I do wish" and "I'd so much rather" and "They don't have to", so obviously it's preference I have. But that's my preference as not only a user of open-source software, but as a committer / PMC member on multiple Apache projects and other open-source projects. It's not remotely coming from a position of entitlement for free-as-in-beer software or ignorance of what it takes to develop and maintain open-source software.
        yawaramin 6y ago
        > "Everyone" includes other users who would benefit from the fix, They can still benefit from it by getting the fixed version from the PR author. > the PR author who can continue using the same version as everyone else, In other words, the PR author is expecting the maintainer to do the work of upstreaming and supporting their (the PR author's) fix for free. > and yes, the maintainer who is foregoing even the possibility of the fix without starting from scratch. And that is their prerogative. If they actually really want that fix they can always get it later. But as said by OP, chances are really good that the way the fix was done would conflict with the direction they want to take the project. And that would actually be a net loss for the maintainer. > As I said in my comment, it makes total sense to me to look at a major change or a risky fix and say "no this isn't worth my time". But I'm sure we've all had those bugs where they take forever to track down until eventually you find a simple problem in code that is obviously an error. To not even take a look at it, as a rigid matter of policy? Yes, I absolutely think open-source maintainers would be missing out on saving some larger efforts. This basically boils down to, expecting an open source maintainer to do the work--for free--of maintaining other people's patches in a patchwork codebase that they no longer have total control over.
  - tshaddox 6y ago
    > The parent wants the project to do that so that s/he does not have to fork it him/herself. That doesn't make a lot of sense. To create a pull request, one must have already done the work to fork the repo themselves. The pull request is an offer to contribute that work back. If the project owners cannot or do not wish to do the work to even triage pull requests, that's fine, but in that case it's pretty clear that a public GitHub repo is the wrong place to be.
    - dodobirdlord 6y ago
      Hosting it in public at least gives others the opportunity to fork it if they have a change they want to see happen. But even reading PRs is work that maintainers shouldn’t be forced into, so GitHub should just allow the PR feature to be turned off.

>> You want other people to do work for you, for free. That's completely understandable. The parent poster was talking about submitting a Pull Request. In other words, contributing the work for free. I suppose expecting someone to look at it might be asking them to do something for free, but if that's a problem then I agree that Github should have the option of not having the button on a project at all. Or maybe you thought PR stood for Problem Report, in which case expecting it to be looked into by someone is an expectation of free labor.

massysett 6y ago
Examining the pull request is work, as is integrating it into the software and maintaining it in the future. The parent wants the project to do that so that s/he does not have to fork it him/herself. In other words, the parent wants someone else to do work, for free. Free Software is about the freedom of the user - freedom to distribute, freedom to study, freedom to use, freedom to modify. Somehow people have managed to pervert this so that it not only means "free as in free beer so that I can use it" but even "free beer so that OTHER PEOPLE can do work that I want done, for free." There is absolutely no entitlement to this.
- macksd 6y ago
  I'm sorry I simply cannot understand how you can read the entirety of my comment and see that as entitled and wanting something for free. I could fork a project and make the fix in my own repo. In fact you have to do that to make a pull request. I even specifically lay out scenarios where I absolutely agree it's not a good return on time invested for the maintainers to bother. But if I forked an open-source project every time I had a bug fix that required time from the maintainer that's worse for everyone. My point is that even though I fully understand and support where the litestream policy is coming from, for anything beyond a personal project I think some flexibility in accepting outside contributions is a win for everyone. I'll do all the work I can without having rights on the project. I'll sign over all my rights. Have tests? I'll run them and post the results. But a rigid "love it or fork it" attitude is a lose-lose.
  - yawaramin 6y ago
    > But if I forked an open-source project every time I had a bug fix that required time from the maintainer that's worse for everyone. Who is 'everyone'? Does that include the maintainer? If so, why is it worse for them? > a rigid "love it or fork it" attitude is a lose-lose. How so? Who exactly is losing, and what exactly are they losing?
    - macksd 6y ago
      "Everyone" includes other users who would benefit from the fix, the PR author who can continue using the same version as everyone else, and yes, the maintainer who is foregoing even the possibility of the fix without starting from scratch. As I said in my comment, it makes total sense to me to look at a major change or a risky fix and say "no this isn't worth my time". But I'm sure we've all had those bugs where they take forever to track down until eventually you find a simple problem in code that is obviously an error. To not even take a look at it, as a rigid matter of policy? Yes, I absolutely think open-source maintainers would be missing out on saving some larger efforts. edit: And to be clear, I freely acknowledge the inverse in my original comment. As TFA explains they were seeing a lot of PRs with unintended side-effects that were complex and counter-intuitive. At no point have I said people MUST accept this as part of the terms of a copyleft license as the original replier seems to think. I used phrases like "I do wish" and "I'd so much rather" and "They don't have to", so obviously it's preference I have. But that's my preference as not only a user of open-source software, but as a committer / PMC member on multiple Apache projects and other open-source projects. It's not remotely coming from a position of entitlement for free-as-in-beer software or ignorance of what it takes to develop and maintain open-source software.
      - yawaramin 6y ago
        > "Everyone" includes other users who would benefit from the fix, They can still benefit from it by getting the fixed version from the PR author. > the PR author who can continue using the same version as everyone else, In other words, the PR author is expecting the maintainer to do the work of upstreaming and supporting their (the PR author's) fix for free. > and yes, the maintainer who is foregoing even the possibility of the fix without starting from scratch. And that is their prerogative. If they actually really want that fix they can always get it later. But as said by OP, chances are really good that the way the fix was done would conflict with the direction they want to take the project. And that would actually be a net loss for the maintainer. > As I said in my comment, it makes total sense to me to look at a major change or a risky fix and say "no this isn't worth my time". But I'm sure we've all had those bugs where they take forever to track down until eventually you find a simple problem in code that is obviously an error. To not even take a look at it, as a rigid matter of policy? Yes, I absolutely think open-source maintainers would be missing out on saving some larger efforts. This basically boils down to, expecting an open source maintainer to do the work--for free--of maintaining other people's patches in a patchwork codebase that they no longer have total control over.
- tshaddox 6y ago
  > The parent wants the project to do that so that s/he does not have to fork it him/herself. That doesn't make a lot of sense. To create a pull request, one must have already done the work to fork the repo themselves. The pull request is an offer to contribute that work back. If the project owners cannot or do not wish to do the work to even triage pull requests, that's fine, but in that case it's pretty clear that a public GitHub repo is the wrong place to be.
  - dodobirdlord 6y ago
    Hosting it in public at least gives others the opportunity to fork it if they have a change they want to see happen. But even reading PRs is work that maintainers shouldn’t be forced into, so GitHub should just allow the PR feature to be turned off.