4 ms·

I've been involved with open source communities off and on for over a decade, as well as other, non-computer communities. News flash: It's not the community tha

I've been involved with open source communities off and on for over a decade, as well as other, non-computer communities. News flash: It's not the community that becomes toxic, it's humanity. Every community that I've ever witnessed gets toxic at some point. As in-groups grow more insular and people become more involved, they get more toxic. But the solution to this phenomenon doesn't have to be black & white. I have always stayed on the margins of communities, and still dip my toes in the water occasionally to get something done. But do I need to keep private forks of patches to avoid messy interactions? Nope. It's pretty easy to fire off a pull request or patch set and then forget about it. I'm not investing great deals of effort or emotion. I'm just sharing my crap. If they merge it, fine, if they don't, fine. But I'm certainly not keeping super secret private repos for just the cool kids to use. That would be even more involved than what little I am already.

nickpsecurity 8y ago
I like your route. Another thing to point out about just fire-and-don't-care-if-it-hits contributions is you still can take credit for them. You put your effort in, you improved the software as you see it, you benefit from that even if they don't want it, others can benefit from your fork, and (if branding) you can even highlight your improvement in CV or resume. So, you and/or others might benefit from them taking your contributions. You and/or others might still benefit when they don't. You can't control what they do anyway. So, might as well set it up so you and others can benefit either way.
- tzs 8y ago
  Fire and forget open source can be fun if you truly forget about it, because then you can be surprised by coming across it in the wild. I wrote something in the early '90s, entirely for my own use. I thought others might find it useful, so tossed it up on my public FTP space at school, added a notice saying it was public domain, posted a single message to the appropriate Usenet group saying it was available in case anyone might find it useful, but that since it fully satisfied my needs I was not going to do any further work on it nor was I interested in any enhancements, and stopped reading that Usenet group. I few years later I noticed Red Hat included a package with the same name ("suck"). Curious, I looked to see what it did--and found it was a descendant of mine! Someone looking for something like it found mine, which did a good chunk of what they were looking for, added the parts missing for their needs, and had been maintaining and distributing it. (And I just checked...it's still in some Linux distros! It's in Debian 9, package name "suck". Too bad I've long since lost my original code. It would be interesting to see if anything of mine has survived in it).
  - jddj 8y ago
    Yeah, this is a great feeling. Not anywhere near the same scale as proliferating throughout the linux package managers, but in my early teens I played an online text RPG and ended up writing a fairly large amount of code on top for playing / navigating / fighting etc. When my hobbies shifted away I shared it around and promptly forgot it. I checked in briefly about 10 years later and was happy to find a lot of my stuff still floating around and being maintained/extended in various forms.
drenvuk 8y ago
This guy has the right idea. Do you think it's worth it to send a PR because it's a cool project? Submit a PR. Maybe because you submit a PR more people submit PRs. Keep your fork and pull the changes that you like while giving back things you think are useful. I've never really understood why people actually want to deal with the people on the other side of the code. I just want your code, not you. I really don't care about you. I can hardly expect you to care about me. Your code and what I can do with it are more interesting than you in nearly all circumstances. So, I contribute to the codebase and I take what I want. Your opinions and thoughts are usually useless. OpenBSD has the proper motto for this: "Shut up and hack". If more oss devs followed the motto then they would be happier as a whole.
- tejaswidp 8y ago
  With the CoC in most projects, that's changing. See also: the Python Mailing list, where threads are locked and people are being banned for CoC violations.
  - drenvuk 8y ago
    It's like you only read the end of my post and skipped the rest of it. I'm going to be a dick here when I say this but this is the reason I have my way of dealing with things people... What you just posted is useless. I don't give a damn. If need be I will fork it, work on it, submit a PR if I make something useful and take what's useful that other people have made for my own code, even among the other forks/branches people have made if it's easy enough to find. My interaction with them is limited to the functionality of the code that I have written and the bare minimum effort needed to let them know of its existence. Anything more is a waste of my time - I have things to build.
    - tejaswidp 8y ago
      I know what you mean, but it's not as clear cut as you think it is. You don't operate in a vacuum when you work on projects. What if you think someone is wrong? Being direct might be a risk, because then the community might not be seen as "welcoming to newcomers" anymore. I mean, ideas don't come out of nowhere for projects, and people who care about things, will be passionate about them. What if someone comes in the way of you building things? What then?
fourthark 8y ago
Not a serious problem with "fire and forget", but an annoyance: say the patch is not up to standards: not well designed, needs tests, or whatever. It worked for the contributor but it can't be merged in its current form. Now the maintainer has to explain what's wrong to a contributor who isn't going to do anything about it. And then explain again and again to everyone else who wants that feature that no, it needs work and can't be merged yet. (Yes, I am that maintainer with dozens of open PRs on his repo, none so bad they must be closed, but also not good enough to merge.)
- tremon 8y ago
  Then again, why should you wait for the original submitter for those modifications? The original contributor published his code, and has not given any indication he's interested in the rest of the process. Why can't anyone else who wants that feature pick up the slack? Maybe you can make that explicit, marking such feature requests as NEEDS_WORK or something?
  - koliber 8y ago
    This is where the behavior of the maintainer is key. On one hand, if the maintainer asks the contributor to fix up their code, the maintainer can be seen us ungrateful, demanding, dictatorial, and/or pedantic. On the other hand, if the maintainer makes the changes herself, they can seem impatient, uncooperative, overpowering, and/or power-hungry. Regardless where on the above spectrum the maintainers behavior falls, they can come across as friendly, neutral, pessimistic, or toxic. That depends on how they communicate. It also depends on the social norms that the maintainer and contributor are used to. A maintainer must be extremely vigilant and aware of the tone they use and the image they want to portray. The contributor should also be aware of these things. If either side wavers, opportunities for an unhealthy brew arise. This is compounded by the fact that most people, maintainers and contributors, are doing the work on a volunteer basis. Often there is an unspoken expectations that others should be grateful for the work that they are doing. When these expectations are not met, sour feelings arise.
    - 8y ago

nickpsecurity 8y ago

I like your route. Another thing to point out about just fire-and-don't-care-if-it-hits contributions is you still can take credit for them. You put your effort in, you improved the software as you see it, you benefit from that even if they don't want it, others can benefit from your fork, and (if branding) you can even highlight your improvement in CV or resume. So, you and/or others might benefit from them taking your contributions. You and/or others might still benefit when they don't. You can't control what they do anyway. So, might as well set it up so you and others can benefit either way.

tzs 8y ago
Fire and forget open source can be fun if you truly forget about it, because then you can be surprised by coming across it in the wild. I wrote something in the early '90s, entirely for my own use. I thought others might find it useful, so tossed it up on my public FTP space at school, added a notice saying it was public domain, posted a single message to the appropriate Usenet group saying it was available in case anyone might find it useful, but that since it fully satisfied my needs I was not going to do any further work on it nor was I interested in any enhancements, and stopped reading that Usenet group. I few years later I noticed Red Hat included a package with the same name ("suck"). Curious, I looked to see what it did--and found it was a descendant of mine! Someone looking for something like it found mine, which did a good chunk of what they were looking for, added the parts missing for their needs, and had been maintaining and distributing it. (And I just checked...it's still in some Linux distros! It's in Debian 9, package name "suck". Too bad I've long since lost my original code. It would be interesting to see if anything of mine has survived in it).
- jddj 8y ago
  Yeah, this is a great feeling. Not anywhere near the same scale as proliferating throughout the linux package managers, but in my early teens I played an online text RPG and ended up writing a fairly large amount of code on top for playing / navigating / fighting etc. When my hobbies shifted away I shared it around and promptly forgot it. I checked in briefly about 10 years later and was happy to find a lot of my stuff still floating around and being maintained/extended in various forms.

drenvuk 8y ago

This guy has the right idea. Do you think it's worth it to send a PR because it's a cool project? Submit a PR. Maybe because you submit a PR more people submit PRs. Keep your fork and pull the changes that you like while giving back things you think are useful. I've never really understood why people actually want to deal with the people on the other side of the code. I just want your code, not you. I really don't care about you. I can hardly expect you to care about me. Your code and what I can do with it are more interesting than you in nearly all circumstances. So, I contribute to the codebase and I take what I want. Your opinions and thoughts are usually useless. OpenBSD has the proper motto for this: "Shut up and hack". If more oss devs followed the motto then they would be happier as a whole.

tejaswidp 8y ago
With the CoC in most projects, that's changing. See also: the Python Mailing list, where threads are locked and people are being banned for CoC violations.
- drenvuk 8y ago
  It's like you only read the end of my post and skipped the rest of it. I'm going to be a dick here when I say this but this is the reason I have my way of dealing with things people... What you just posted is useless. I don't give a damn. If need be I will fork it, work on it, submit a PR if I make something useful and take what's useful that other people have made for my own code, even among the other forks/branches people have made if it's easy enough to find. My interaction with them is limited to the functionality of the code that I have written and the bare minimum effort needed to let them know of its existence. Anything more is a waste of my time - I have things to build.
  - tejaswidp 8y ago
    I know what you mean, but it's not as clear cut as you think it is. You don't operate in a vacuum when you work on projects. What if you think someone is wrong? Being direct might be a risk, because then the community might not be seen as "welcoming to newcomers" anymore. I mean, ideas don't come out of nowhere for projects, and people who care about things, will be passionate about them. What if someone comes in the way of you building things? What then?

fourthark 8y ago

Not a serious problem with "fire and forget", but an annoyance: say the patch is not up to standards: not well designed, needs tests, or whatever. It worked for the contributor but it can't be merged in its current form. Now the maintainer has to explain what's wrong to a contributor who isn't going to do anything about it. And then explain again and again to everyone else who wants that feature that no, it needs work and can't be merged yet. (Yes, I am that maintainer with dozens of open PRs on his repo, none so bad they must be closed, but also not good enough to merge.)

tremon 8y ago
Then again, why should you wait for the original submitter for those modifications? The original contributor published his code, and has not given any indication he's interested in the rest of the process. Why can't anyone else who wants that feature pick up the slack? Maybe you can make that explicit, marking such feature requests as NEEDS_WORK or something?
- koliber 8y ago
  This is where the behavior of the maintainer is key. On one hand, if the maintainer asks the contributor to fix up their code, the maintainer can be seen us ungrateful, demanding, dictatorial, and/or pedantic. On the other hand, if the maintainer makes the changes herself, they can seem impatient, uncooperative, overpowering, and/or power-hungry. Regardless where on the above spectrum the maintainers behavior falls, they can come across as friendly, neutral, pessimistic, or toxic. That depends on how they communicate. It also depends on the social norms that the maintainer and contributor are used to. A maintainer must be extremely vigilant and aware of the tone they use and the image they want to portray. The contributor should also be aware of these things. If either side wavers, opportunities for an unhealthy brew arise. This is compounded by the fact that most people, maintainers and contributors, are doing the work on a volunteer basis. Often there is an unspoken expectations that others should be grateful for the work that they are doing. When these expectations are not met, sour feelings arise.
  - 8y ago