3 ms·

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 projec

by 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.

by macksd 6y ago

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.