| > Back in pre-LLM days, receiving an unexpected pull request (PR) from a fellow coder was a source of excitement and pride. As a maintainer of a few FLOSS projects, this tracks. The Pavlovian PR notification response has gone from, "Oh! What do we have here?" to "Groan. Do we have _anything_ here?" I won't get specific but I just had to remove a contributor from a project after multiple submissions of either cutesy, fluffy bullshit (add ASCI animations!) or "rewrite entire project in other language". Not only did the PRs result in wasted time and energy but they also resulted in conversations about how to deal with this sort of spam. (Probably good to get out of the way and set policy but still...) So, this person probably spent fifteen minutes prompting together these stupid PRs and multiple maintainers had to spend hours agonizing over what to do about them. |
| |
| ▲ | lelanthran 7 hours ago | parent | next [-] | | > TBH I never contributed to Open Source because of the effort needed to bring my PR from "works on my machine" to "compliant with the rest of codebase". Especially that I only want to implement one small thing. That's a good thing; OSS projects don't want drive-by contributors, they want a community. A small bit of friction is a good thing. After all, we can see what happens with frictionless contributions. | | |
| ▲ | tough 7 hours ago | parent [-] | | I some times will open a PR even if i know it will get closed, simply by because if its a bugfix or feature i want, someone else might do so too, and i have many times adopted code from PR's that were never adopted by mainstream or closed. By pushing that PR, i might be annoying a grouchy maintainer, but at the same time helping tens or hundreds of other users of the software. Imho the beauty of open source is as long as you're adhering to the licenses, you can do whatever the heck you want =) | | |
| ▲ | ahartmetz 6 hours ago | parent [-] | | If you already know it's not good enough, you can just say so by calling it a proof of concept or hack to demonstrate what needs to be done. Such code is often very useful when writing the real fix. | | |
| ▲ | greiskul 6 hours ago | parent [-] | | Yup, some of my first contributions when I was a teenager, was to an open source project where I was able to find a couple of bugs, and implement a hacky solution that I shared with the team on the forum. My code was absolutely awful, but by having done both the effort of tracking down the cause of the bug, and one possible way of fixing it (which was badly coded, but worked), made the developers able to quickly turn around and edit my patches into actual patches that got merged into the project. And it was actually a pretty good feeling. Made me feel that even as a newbie programmer, I was adding value to the community, which I was! | | |
| ▲ | ahartmetz 3 hours ago | parent [-] | | I've done the same for a fix in the Gold linker, which is now obsolete due to even faster linkers being available. Shout out to Ian Lance Taylor, his behavior as the maintainer was exemplary: very gracious and very responsive. |
|
|
|
| |
| ▲ | yoyohello13 8 hours ago | parent | prev [-] | | I not trying to be mean about it, but... that's good. If your one small thing wasn't worth the effort for contribution then it probably doesn't need to be in upstream. Contrary to what many seem to believe, code existing is not inherently better than code not existing. | | |
| ▲ | darkwater 7 hours ago | parent [-] | | Actually it's good for another reason, and that's the very essence of opensource: the user can customize the software to their needs, but there is no obligation to participate in a community effort (although it's definitely cool as a side effect) |
|
|
