Hacker News Reader

I think the best way to go (if you're the "Good Samaritan Who Wants to Do His Civic Duty but Also Doesn't Want to End Up Spending the Week in Nerd Court") is to fork it, fix it, and leave a brief comment in the issue thread that says "hey, I fixed this in my fork".

That way, people with the same issue who come in to the issue thread through a search aren't reduced to combing through all the forks to see if one happens to fix the issue. Then instead of spamming up the thread with "me too, this is soo frustrating, fix asap pls", they can spam it up with "merge this fork into the main project asap pls" :-)

If you don't distribute to others you don't need to distribute your own changes even for copyleft licenses. That's why the AGPL license was written, because if you're doing something as a service you won't need to distribute any sources even with GPL license.

> you do kinda legally have to share that modified source code

I'm using the license exactly as intended. Upstream developers literally don't matter. Free software is not about developers, it's about users.

Free software licenses say the user gets the source code. They're about empowering the user, in this case me, with the ability use and modify the software as I see fit. If I customize something for my personal use, then I'm the only user of the fork and license terms are fulfilled. People would only get to demand source code from me if I started distributing compiled executables to other users.

> You've got no need to campaign for the solutions if they get rejected.

I used to feel that need. Caused me significant anxiety. I thought upstreaming patches was the Right Thing to do. Mercifully I've been cured of this misconception.

> There's really no downside beyond taking 5 minutes to be nice and at least put your solution out there.

I have no problem with that. My point is getting involved with upstream is often more trouble than it's worth. Let them do their thing. Just pull from them and rebase your changes. Enjoy life.

People should think twice before trying to cram their unsolicited code down other people's throats. Even when they ask for the code, chances are deep down they don't actually want to deal with it.

That is exactly why I said that that only comes in once you publish something. The legal argument isn't as strong as the moral one is for me anyway, I never publish anything. I think making a PR isn't forcing code on someone, they're not obligated by anything to read and consider it, but if they do want to they can. I'll make one, and then I'll stop responding, because that's where my personal moral obligation ends. Whoever wants the code can now easily discover it, whoever doesn't can throw it away as they like. Including the upstream maintainer.

Usually better start with small scale fixing typos and improving docs. That’s great canary for me. If it’s accepted within day or so, that’s project which I willing to learn. I would say you can select projects for your value and you would be fine contributing there. Eventually people will learn you and will trust you more

I understand your point and it's good advice. Typos and documentation though? That's boring... I want to do interesting things. Ever wondered why some program can't do something? Surely someone much smarter would have thought of it, right? And then you code it up and it actually works? That's the kind of thing I like to do.

I once tried to retrofit a library system into GNU bash of all things. Let's just say it didn't go well.

Your patch sounds horrible, no wonder people reject them.

Works for me. I can easily organize and reuse functions now. Made scripting much more pleasant. Even made a package out of it so I could install it alongside the upstream version.