My boundaries as an open source developer

It's usually harder to find an authors direct contact information than the official channels. If the user has a legitimate bug report or issue, being told they accidentally found the wrong contact information wouldn't bother many. However if the user is going through backdoor channels specifically to get special treatment then that isn't fair to others.

- Always respond to the initial question/comment/PR. Not necessarily immediately. But it lets people know you have seen it and they are not being ignored. If they DM but you rather have them use another way of communicating, just point that out.

- Give people the benefit of the doubt. Some people just don't know how to ask a good question or how to report an issue in a constructive way, so just respond with a remark that nudges them in the right direction, possibly have some document ready describing how people should ask questions (for example, like https://stackoverflow.com/help/how-to-ask).

- Don't continue fruitless discussions. I don't repeat things I said earlier, unless there is something to clarify. If someone disagrees with me and I don't see the merit in their points, then so be it. At some point you just have to ignore messages, and don't feel bad about doing that. If someone DMs and you said to create a ticket instead, and they DM again saying things like "but it's just this small thing" or "but I just told you", I'll just ignore that, and if they really care about the issue they'll eventually figure it out.

- When it comes to low quality pull requests, tell the author how to improve them. Ideally, I should be able to merge PRs without any changes necessary on my part. This will both lower the amount of work I have to do, as well as educate the author so they will be more productive in the future.

- I try not to be too fussy about how people want to contribute. I'll just as happy to accept a patch sent via email as a PR. And sometimes it's just less work to copy&paste a DM into a ticket instead of educating the user.

Bingo. The hard-earned wisdom of this insight right here almost completely explains all the internal issues the OP was feeling when he wrote his rather over-the-top post.

Yeah, it sucks to realize that your just as human as the next guy and that your motives aren't always as pure as you wish they were, but there is nothing at all wrong with being proud and wanting to be noticed for abilities.

Figuring out what path works for you AFTER realizing your motives aren't pure is how one solves the open-source user issue.

The way Github e.a. use forks dilutes the larger meaning of the word, that's what this thread is about. When people used to talk about forks, they always mean a community fracture over differences of opinion: gcc vs egcs, xfree86 vs xorg, ffmpeg vs libav, openwrt vs lede, glibc vs eglibc, kde4 vs trinity, gnome3 vs cinnamon vs mate.

The common-use term of "fork" on github has nothing to do with divergence of development, it's just a band-aid for lack of contributor access control. I can understand why people don't like github's use of forks, and that has nothing to do with what the license "allows" or not: if it's not a divergent development line, it's not a fork, it's a clone at best. In most cases, I'd say it's just a feature branch hosted in a different repository.

Calling something a fork implies long-term viability (or at least the intention) as an alternative to the original repo. That doesn't sound like a realistic description of most cloned repo's on Github to me.