Hacker News Reader

> Even if I have to sign over all my rights of the code

Even if people sign over the rights, there can still be admin to prove that they have those rights to sign over in the first place, or the responsibility for any fall-out if it turns out they didn't later, which some will not want to take on.

Also, some projects are personal and while the authors are perfectly happy to share they want to keep their version theirs, as in entirely created by them. People release their code open source for a variety of reasons, sometimes contributions back in that manner are not actually desired and we shouldn't take offence at that (it isn't intended to raise offence).

> ought to be made very clear in README.md or CONTRIBUTING.md or something too

This is a large part of the answer, I'd agree with you there.

The default assumption on github, and more generally, is that contributions are likely to be welcome and in fact actively desired. Politely explaining that this isn't the case in obvious places removes the confusion (and if someone hasn't read the usual places before submitting the PR that is their mistake not something to blame the project owner for). A sentence or two of text, as seen in the example that started this thread, in the README or similar documentation, should be sufficient. Perhaps also add it to the LICENSE file if you think that is more likely to be checked than someone reading the whole of the README (though if the readme is long enough for that to be a significant issue, perhaps look to streamline it and move some detail off to supplementary files).

> I hate it when my only option if I want a bug fixed is to wait for the company to do it themselves or fork.

I think you're missing an important point here: the right to fork is the primary point of Open Source. Sure, it's nice if you don't have to fork, but ultimately the reason Open Source is important is so that you can fork if you have to. The other parts, about projects being able to accept contributions from others and so on, are nice to haves, but not essential. The right to fork is what is essential, so that when a project has a bug, and the project owners aren't fixing it, which is expected to be the most common case (see below for why), you, as an individual, can at least fix the bug for yourself, instead of being stuck with a proprietary system with a bug you can't fix at all.

Why is it expected to be the most common case that the project owners won't fix the bug? Because the tradeoff between benefit and cost from the project's point of view is very different than it is from yours. For you, it's much easier, as you say, for the upstream project to accept your PR than for you to have to maintain your own fork. But from the project's point of view, it's much harder to accept your PR than to just ignore it. Sure, you might be convinced that you've fixed an important bug and your code will be a net gain to the project. But how do they know that? To them, you're just some random person on the Internet. It's not like they have people sitting around just waiting for random people on the Internet to make contributions. Any time spent on evaluating your code is time not spent on something the project has already committed to doing. And if they aren't feeling any pain from the bug themselves (which they won't be if you, a random person on the Internet, have had the time to see it and code a fix for yourself), fixing it won't be on the list of things they are already committed to doing.

This is all true, I just wish that commits to my forks of dead/strict projects showed up on my activity graph. I’m strangely proud of that thing and half my work doesn’t end up on it because things are no longer maintained upstream. :/

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

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

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.

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.

> 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?

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

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

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

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.