10 ms·

I realised as I read this post that I have done exactly this on a few occasions. Taken upstream code, forked it, fixed bugs and used it for myself. Usually ther

I realised as I read this post that I have done exactly this on a few occasions. Taken upstream code, forked it, fixed bugs and used it for myself. Usually there's no conspiracy, I just cannot be bothered dealing with "you're doing it wrong" comments when my fix isn't deemed worthy. The problem I have seen is that certain usually vocal members of a community can have this double-edged helpful-jerk attitude. Most of the time I just lurk on communities, so the jerkiness is rarely if ever even directed at me, but it changes my view of the project to the point where I just don't want to be involved. The usual pattern is a post or response to a bug report, patch or question that is generally helpful but at the same time needlessly nasty or snarky, and with a I-know-better-than-you attitude. If the community person dislikes the question asked, or the use that people make of their software, why do they take the time to write answers at all? Usually being pleasant is a question of writing less words as well. These people go out of their way to add snark to the response. This isn't limited to "open source". It is probably just a people problem. I've seen the exact same thing on guitar forums. Members that post helpful replies, but spread a layer of snark over them. You follow their profile and they often have websites with lots of good free information, lessons and whatnot, but here they are, writing twatish answers. It has been a problem on stackoverflow.com too, and they really stirred things up over there recently trying to herd people into being a bit nicer.

fefe23 8y ago
I see this pattern regularly and I always wonder: why would you deny yourself the opportunity to improve? If you have a patch, and others know how to make it better, why would you forgo that chance to learn something? What good can possibly come out of "I'll just hide in my shed" and tell nobody about my patch (that is what the OP recommended, invite-only repositories). You submitting patches has nothing to do with the community. You submitting patches has everything to do with: a) improving the patch to maximize its usefulness b) the project becoming better c) you becoming better d) the project taking over maintenance of your patch so you don't have to. It's a win-win for everybody.
- thecatspaw 8y ago
  Your patch might not fit the projects guidelines, but work fine for what you are trying to do. Maybe it even is a hack, which only works in your case. There's also the possibility of time pressure, or just not wanting to deal with possibily snarky comments.
- kelnos 8y ago
  The benefit of taking that particular avenue to improve oneself might be overshadowed by the potential downsides of having to deal with toxic people to get there. And that's a personal scale-weighing that everyone has to do for themselves. There's no objective right or wrong in that.
  - justtopost 8y ago
    Everyone is toxic to someone. Avoiding every toxic person is just crippiling you socially, professionally. You have to meet challenges head on, or you are just lazy, and blaming the topic du jour. The ideal welcoming working group is a great goal, but we are humans, and always striving. To stop progress because its hard or annoying just shows your character.
    - notacoward 8y ago
      > Everyone is toxic to someone. I'm not known for my positive view of humanity, but I don't believe that's true at all. "Toxic" doesn't apply to anyone short of a true saint. It's meant for people who exhibit specific behaviors that undermine others' confidence, satisfaction, etc. If a person X who seems above average in collaborative and supportive behavior to everyone else has a single bad interaction with another person Y, does that make X toxic? Of course not. It probably means Y is toxic, and is projecting their own toxicity onto others. Who's the lazy one? Who's evading responsibility for their own outcomes? Whose character does that reflect on?
- yourbandsucks 8y ago
  Probably because, if there's a real bug, the patch is by definition an improvement even if the whitespace isn't to everybody's liking? The tech community has pivoted hard to an obsession with the superficial in recent years. I'm not gonna do 10 iterations of catering to someone's personal tastes in order to do them a favor. They can take it or leave it.
Smushman 8y ago
It is just a fact of our protective psychological human makeup that we all have fragile egos and energy conservation always on. That will make us insensitive and upset with others (we respond rudely), and keeps us safe by not wasting energy on unimportant things (we don't submit). Both you as the submitter who doesn't want to deal with the comments, and the person who is complaining back (and to be sensitive myself, I try to remember they may not be conscious of it) are both dealing with that. For example, think about your job, and how often did you just let things go because you had to 'pick your battles' or even 'just too tired to deal with that'. Bosses do it too. This is human nature. It is, as you say, a people problem.
CogitoCogito 8y ago
I think basically the whole point of open source (free software or otherwise) is the ability to edit a program's source code to fit your needs. If your needs are very special, there is no point in trying to merge the changes with upstream or distribute them more widely. If it is too difficult to upstream your code (e.g. because of irritating governance and hoops to jump through), then you don't upstream the code. If you don't agree (philosophically or otherwise) with those running the project, then maybe you also don't want to upstream your work. The majority of code written solves a problem specific to the author. There is no need, responsibility, or moral obligation to make all your code public. Honestly I don't even think that's a good thing. All of this is how it's supposed to work. You are in control.
- firepoet 8y ago
  Correct me if I'm off-base, anyone, but it appears to me that the point of the original post is to express that, if you run an open source project, and you want to take advantage of people's hard-won experience and energy to the benefit of your project, you may want to focus on having an inviting community. At least, that's how I read it. That said, of course there's no moral obligation to contribute. However, as an original author of several open source projects, I take this as a helpful lesson around inviting others who don't have a moral obligation to feel welcome to contribute, and even find some way to reward them, even if I can only afford public praise at the time.
  - CogitoCogito 8y ago
    Well my comment was kind of generally directed at a few different ideas floating around in the comment thread as well as from the original article, but I do believe that yes the main point of the original post is what you say. I definitely believe that any open source project should to the best of its ability make it easy for users to contribute back upstream. That requires a welcoming community, a sane design, good documentation, etc. Many projects fail and lose out on worthy contributions as a result. That certainly is sad. But I just wanted push back against the idea that some have that people should always be contributing their changes upstream. I don't even mean to focus on any moral obligations. As a user of open source software, you should make changes to fit yourself and your needs without regard to others. Sometimes your changes might make sense to upstream, but often they are just changes that you prefer. The real-life parallel would be painting a cool design on your ikea furniture. Just because you like it, doesn't mean ikea needs to know or that you should feel any sort of obligation to tell them or any others about it. It's your furniture and you should make it the way you want it. Maybe I'm just blabbering, since I don't think we really disagree, but I just want people to remember that open source gives users the freedom to mess with software in whatever way they want without any pressure or need to make it look nice or to give it to others. It's their computer and they can make the software run as they wish.
bachmeier 8y ago
> The usual pattern is a post or response to a bug report, patch or question that is generally helpful but at the same time needlessly nasty or snarky, and with a I-know-better-than-you attitude. The most infuriating responses come when I've put a bunch of time into constructing a careful bug report (maybe several hours after narrowing down the problem), and some idiot comes along and closes it, telling me to post support questions elsewhere. It usually takes the form of bug report -> here's a workaround -> no, doesn't help -> idiot jumps in and says "Please file support requests elsewhere. I'm closing this."
- criddell 8y ago
  In my experience, the larger the project, the more likely you are to get that type of response. Small, actively maintained projects are often very welcoming and happy to have any help.
  - biql 8y ago
    This is surprisingly often true with companies too.
- devonkim 8y ago
  I’ve discovered that as any project becomes larger and involves more people, they all lead to patterns resembling awful enterprise corporate bureaucracies with the same political and cultural repercussions. Patterns that result in folks filing issues in the wrong categories and issue trackers entirely come from bad / misaligned UX but also because the maintainers and contributors are having difficulty accommodating the workflows of users and new contributors. Jenkins is a project where they outright disabled Github issues and everything goes to the JIRA, for example, but somehow Kubernetes is able to handle some issues via Github at least (but only by sharding from what I observe).
- anon49124 8y ago
  There's BS and cool on both sides of PRs. - MYOB fail, as mentioned, sigh. - Closing issues before they're resolved. Proper etiquette is to let the filer close it after it's fixed and working. - People demanding features or making vague trouble reports. - Submitting a properly-tested PR that fixes an issue without need for a fix-it issue. - Committers open to some globally-beneficial change only to change their mind after it's already done. - People refactoring your commit with something better. - Rust and a lot of small languages have tiny, good communities of generally humble badasses. - People changing whitespaces or switching to British grammar. SMH. I look at it this way: you gotta take the shit with sugar. Not trying to contribute upstream is consuming without producing... I'm against this because it helps no one and it's uncool.
raxxorrax 8y ago
I have kind of the opposite experience. When submitting patches or solutions, you often don't get feedback at all, people just seem happy. In some cases someone arrives and implements a smarter, shorter and more easy to read solution to the problem you addressed that is superior in every way. Puts you down for a moment, but in normal cases there isn't any snark involved at all. I hope it also happens the other way around from time to time. But in general I wouldn't say people are vindictive. It is the internet and the slapfight is forgotten 1.5 minutes after it happened. Maybe it has something to do with how popular a project is and how often certain question are asked.
- CannisterFlux 8y ago
  Yeah, I've seen both sides of it too. As you say, a lot (the majority?) of projects are really happy to get patches, often rework minor things in the patch instead of telling you to re-do stuff. This is especially true of smaller 1-man shows. If you send a patch for a bug it's either gleefully lapped up and applied, or ignored forever (life happens, I get that, no problem). The other side isn't always true vindictiveness, just wise-ass level garbage. Anyway it's turned me off more than a couple of projects, forums and sub-reddits. You get that 1 dude that you see again and again posting newbie put-downs. They are usually not the lead of the project, but certainly a lieutenant-type. Maybe with "mod" privs. A lot of the time the regulars are sycophantic towards this person, to get on their good side I suppose, maybe to see if they too get some recognition or power. It's rather sad to see, but what else can they do? Walk away I guess. And as a lurker it's what I do when I see it. Also, maybe I read too much into the text. It could just be that text is a really bad media for niceness, and something that would be said out-loud in a different tone comes across as jerky in text.
cik 8y ago
Frequently I do the same - fork, fix, or change, and I'll rarely push it back. Mostly, I don't want to deal with the community, egos, or icons. A couple of decades ago, it was really bad. I'd keep email addresses and pseudonyms separate for the various projects I was involved in, if only to contribute and not impact my life. To this day, when I push something, I release it as MIT for this reason. Anything I put out there is free for you to scratch your itch, the same way I scratched mine. There's no need to share it back, or file an issue - maintain your own. That way, there's no need to worry about goals or personalities clashing.
- tfigment 8y ago
  I relate to this and am same. I still feel guilt sometime because I release something and work on it for a couple weeks but then I'm usually done. Its likely full of issues but did what I wanted. Sometimes a community forms around it and there is a expectation of continued support from me but that is not my goal. Few people will actually take up this code from what i can tell or its forked and not released. Im generally ok with it but feels like there should be a better path for this stuff.
xg15 8y ago
> This isn't limited to "open source". It is probably just a people problem. My understanding is that those kinds of "people problems" are exactly what CoCs are attempting to tackle. (Or at least that's one motivation)
radarsat1 8y ago
As a maintainer I've also had weird situations come up where someone suggests something perfectly good, and even includes code with an implementation, maybe even something they've spent significant time on, but even though it's a good idea and potential contribution, it just doesn't "fit" with the idea we're going for.. it's actually hard to say no to people for reasons like, "Your code is good but we don't want it because that's not the right interface according to the use case our software is designed for." Clearly the code is good for the person proposing it, and I can't even reject with the excuse that it's bad code in any way, all I can say is, that's not what we want to do right now. It's kind of heartbreaking to reject things on that basis. I've even found myself having to reject contributions purely for the reason of, "your code is good but it's too much.. I don't want to maintain that." Believe me it sucks to reject a significant contribution, but the fact is that what often happens from experience, is that someone scratches their own itch, submits a huge patch, and then walks away once it is accepted. And then it does indeed become my job to maintain a bunch of code that I didn't write and aren't familiar with. So I find that these silly practical issues crop up a lot that have nothing to do with code quality per se, but more to do with being pragmatic about maintenance and the goals for a given code base. It's hard to know how to give the right answer, socially speaking, and I think I have definitely come off as snarky in the past doing so, but it's not intentional. Sometimes acceptance or rejection simply doesn't depend on the code but on other factors that are hard to convey properly on an online forum. At least the message for contributors is, small one-off fixes are one thing, but if you're going to spend significant time working on something, please discuss it upstream before proposing a huge patch that might not even be something we want to integrate.
- smaddox 8y ago
  That is somewhat unfortunate, but if I take a bit of time to think about it, it seems like a necessary consequence of a successful open source project/movement. Perhaps, in cases like those, you could find a way to split the base project into two or more modules, making it possible to share code with the new fork, but such splitting has non-negligable cost in terms of ossification of internal APIs and maintenance overhead.
  - 8y ago
stcredzero 8y ago
If the community person dislikes the question asked, or the use that people make of their software, why do they take the time to write answers at all? Usually being pleasant is a question of writing less words as well. These people go out of their way to add snark to the response. This isn't limited to "open source". It is probably just a people problem. It's a people problem. In the 70's and 80's, these would've been the kids that would taunt you or worse in the hallways, gym showers and locker rooms. Not literally, exactly. It wouldn't necessarily have been the same people. However, human nature includes a certain degree of aggression and "us vs. them" groupthink. It's only a question of how it gets expressed. We know that such forces can be negative. We also know that such impulses can be channeled for positive ends.
danShumway 8y ago
Even when maintainers are super nice, it's work to get a patch into an acceptable state for a project, and at least to a certain extent it's not clear why that work should always fall on the person who's making the patch for themselves. If a forked repo solves a problem and keeps it Open Source and available, and their solution genuinely is good and useful for the community, then there's nothing to prevent the original repo from pulling their code and reformatting it or adding tests. Upstream maintainers are totally free to go downstream looking for patches. They don't need to ask anyone's permission or convince somebody else to make a pull request. Just copy the code upstream if you care about it. I've done this in the past with public projects -- fixed a problem, left a quick note on the original repo saying, "hey, I have solution but it's just for me. You're welcome to adapt it if you think it's worthwhile." I've also done the opposite and worked really hard to get something accepted. I've also walked the middle line, where I coordinated with upstream to contribute to an official API, but at the same time made it clear that my downstream fork was going to diverge and stay specific to my use-case. It's nice for patches to get merged back upstream, and it's nice for patch writers to put in the effort to do so, but part of the point of Open Source is you don't need to wait for that to happen. I have no qualms whatsoever about maintaining a personal fork of someone else's software. If I'm patching something to solve one of my problems, I'm going to search for a solution that solves it as specifically and narrowly as possible. I'm not going to worry about what your coding style is or what you'd like the API to look like. Then once my problem is solved, if I have time, I'll think about broadening it or altering it to fit with the overall community. But that's a separate step that doesn't have to be specifically my chore. Anybody can do it.
scotty79 8y ago
> just cannot be bothered dealing with "you're doing it wrong" comments when my fix isn't deemed worthy. Please just post it. Ignore comments. Your fix will most likely prompt them to write their own fix for the same thing in the following weeks or months. They may not even mention you or use your single line of code in their branch but it's you that gave them ideas and belief that problem can be fixed. If you want to get things done on the internet then post your almost right solution and look at all the people that rush to correct you.
scotty79 8y ago
> ... writing twatish answers. It has been a problem on stackoverflow.com too, ... I'm most annoyed by answers "you shouldn't want to do that" from shallow experts. I can bare "you shouldn't want that, that's a horrible idea because ..., but if you must you could do it like that:" from deep experts. I can bare the tone if the response contains actual information, but not if it's just the tone.

fefe23 8y ago

I see this pattern regularly and I always wonder: why would you deny yourself the opportunity to improve? If you have a patch, and others know how to make it better, why would you forgo that chance to learn something? What good can possibly come out of "I'll just hide in my shed" and tell nobody about my patch (that is what the OP recommended, invite-only repositories). You submitting patches has nothing to do with the community. You submitting patches has everything to do with: a) improving the patch to maximize its usefulness b) the project becoming better c) you becoming better d) the project taking over maintenance of your patch so you don't have to. It's a win-win for everybody.

thecatspaw 8y ago
Your patch might not fit the projects guidelines, but work fine for what you are trying to do. Maybe it even is a hack, which only works in your case. There's also the possibility of time pressure, or just not wanting to deal with possibily snarky comments.
kelnos 8y ago
The benefit of taking that particular avenue to improve oneself might be overshadowed by the potential downsides of having to deal with toxic people to get there. And that's a personal scale-weighing that everyone has to do for themselves. There's no objective right or wrong in that.
- justtopost 8y ago
  Everyone is toxic to someone. Avoiding every toxic person is just crippiling you socially, professionally. You have to meet challenges head on, or you are just lazy, and blaming the topic du jour. The ideal welcoming working group is a great goal, but we are humans, and always striving. To stop progress because its hard or annoying just shows your character.
  - notacoward 8y ago
    > Everyone is toxic to someone. I'm not known for my positive view of humanity, but I don't believe that's true at all. "Toxic" doesn't apply to anyone short of a true saint. It's meant for people who exhibit specific behaviors that undermine others' confidence, satisfaction, etc. If a person X who seems above average in collaborative and supportive behavior to everyone else has a single bad interaction with another person Y, does that make X toxic? Of course not. It probably means Y is toxic, and is projecting their own toxicity onto others. Who's the lazy one? Who's evading responsibility for their own outcomes? Whose character does that reflect on?
yourbandsucks 8y ago
Probably because, if there's a real bug, the patch is by definition an improvement even if the whitespace isn't to everybody's liking? The tech community has pivoted hard to an obsession with the superficial in recent years. I'm not gonna do 10 iterations of catering to someone's personal tastes in order to do them a favor. They can take it or leave it.

Smushman 8y ago

It is just a fact of our protective psychological human makeup that we all have fragile egos and energy conservation always on. That will make us insensitive and upset with others (we respond rudely), and keeps us safe by not wasting energy on unimportant things (we don't submit). Both you as the submitter who doesn't want to deal with the comments, and the person who is complaining back (and to be sensitive myself, I try to remember they may not be conscious of it) are both dealing with that. For example, think about your job, and how often did you just let things go because you had to 'pick your battles' or even 'just too tired to deal with that'. Bosses do it too. This is human nature. It is, as you say, a people problem.

CogitoCogito 8y ago

I think basically the whole point of open source (free software or otherwise) is the ability to edit a program's source code to fit your needs. If your needs are very special, there is no point in trying to merge the changes with upstream or distribute them more widely. If it is too difficult to upstream your code (e.g. because of irritating governance and hoops to jump through), then you don't upstream the code. If you don't agree (philosophically or otherwise) with those running the project, then maybe you also don't want to upstream your work. The majority of code written solves a problem specific to the author. There is no need, responsibility, or moral obligation to make all your code public. Honestly I don't even think that's a good thing. All of this is how it's supposed to work. You are in control.

firepoet 8y ago
Correct me if I'm off-base, anyone, but it appears to me that the point of the original post is to express that, if you run an open source project, and you want to take advantage of people's hard-won experience and energy to the benefit of your project, you may want to focus on having an inviting community. At least, that's how I read it. That said, of course there's no moral obligation to contribute. However, as an original author of several open source projects, I take this as a helpful lesson around inviting others who don't have a moral obligation to feel welcome to contribute, and even find some way to reward them, even if I can only afford public praise at the time.
- CogitoCogito 8y ago
  Well my comment was kind of generally directed at a few different ideas floating around in the comment thread as well as from the original article, but I do believe that yes the main point of the original post is what you say. I definitely believe that any open source project should to the best of its ability make it easy for users to contribute back upstream. That requires a welcoming community, a sane design, good documentation, etc. Many projects fail and lose out on worthy contributions as a result. That certainly is sad. But I just wanted push back against the idea that some have that people should always be contributing their changes upstream. I don't even mean to focus on any moral obligations. As a user of open source software, you should make changes to fit yourself and your needs without regard to others. Sometimes your changes might make sense to upstream, but often they are just changes that you prefer. The real-life parallel would be painting a cool design on your ikea furniture. Just because you like it, doesn't mean ikea needs to know or that you should feel any sort of obligation to tell them or any others about it. It's your furniture and you should make it the way you want it. Maybe I'm just blabbering, since I don't think we really disagree, but I just want people to remember that open source gives users the freedom to mess with software in whatever way they want without any pressure or need to make it look nice or to give it to others. It's their computer and they can make the software run as they wish.

bachmeier 8y ago

> The usual pattern is a post or response to a bug report, patch or question that is generally helpful but at the same time needlessly nasty or snarky, and with a I-know-better-than-you attitude. The most infuriating responses come when I've put a bunch of time into constructing a careful bug report (maybe several hours after narrowing down the problem), and some idiot comes along and closes it, telling me to post support questions elsewhere. It usually takes the form of bug report -> here's a workaround -> no, doesn't help -> idiot jumps in and says "Please file support requests elsewhere. I'm closing this."

criddell 8y ago
In my experience, the larger the project, the more likely you are to get that type of response. Small, actively maintained projects are often very welcoming and happy to have any help.
- biql 8y ago
  This is surprisingly often true with companies too.
devonkim 8y ago
I’ve discovered that as any project becomes larger and involves more people, they all lead to patterns resembling awful enterprise corporate bureaucracies with the same political and cultural repercussions. Patterns that result in folks filing issues in the wrong categories and issue trackers entirely come from bad / misaligned UX but also because the maintainers and contributors are having difficulty accommodating the workflows of users and new contributors. Jenkins is a project where they outright disabled Github issues and everything goes to the JIRA, for example, but somehow Kubernetes is able to handle some issues via Github at least (but only by sharding from what I observe).
anon49124 8y ago
There's BS and cool on both sides of PRs. - MYOB fail, as mentioned, sigh. - Closing issues before they're resolved. Proper etiquette is to let the filer close it after it's fixed and working. - People demanding features or making vague trouble reports. - Submitting a properly-tested PR that fixes an issue without need for a fix-it issue. - Committers open to some globally-beneficial change only to change their mind after it's already done. - People refactoring your commit with something better. - Rust and a lot of small languages have tiny, good communities of generally humble badasses. - People changing whitespaces or switching to British grammar. SMH. I look at it this way: you gotta take the shit with sugar. Not trying to contribute upstream is consuming without producing... I'm against this because it helps no one and it's uncool.

raxxorrax 8y ago

I have kind of the opposite experience. When submitting patches or solutions, you often don't get feedback at all, people just seem happy. In some cases someone arrives and implements a smarter, shorter and more easy to read solution to the problem you addressed that is superior in every way. Puts you down for a moment, but in normal cases there isn't any snark involved at all. I hope it also happens the other way around from time to time. But in general I wouldn't say people are vindictive. It is the internet and the slapfight is forgotten 1.5 minutes after it happened. Maybe it has something to do with how popular a project is and how often certain question are asked.

CannisterFlux 8y ago
Yeah, I've seen both sides of it too. As you say, a lot (the majority?) of projects are really happy to get patches, often rework minor things in the patch instead of telling you to re-do stuff. This is especially true of smaller 1-man shows. If you send a patch for a bug it's either gleefully lapped up and applied, or ignored forever (life happens, I get that, no problem). The other side isn't always true vindictiveness, just wise-ass level garbage. Anyway it's turned me off more than a couple of projects, forums and sub-reddits. You get that 1 dude that you see again and again posting newbie put-downs. They are usually not the lead of the project, but certainly a lieutenant-type. Maybe with "mod" privs. A lot of the time the regulars are sycophantic towards this person, to get on their good side I suppose, maybe to see if they too get some recognition or power. It's rather sad to see, but what else can they do? Walk away I guess. And as a lurker it's what I do when I see it. Also, maybe I read too much into the text. It could just be that text is a really bad media for niceness, and something that would be said out-loud in a different tone comes across as jerky in text.

cik 8y ago

Frequently I do the same - fork, fix, or change, and I'll rarely push it back. Mostly, I don't want to deal with the community, egos, or icons. A couple of decades ago, it was really bad. I'd keep email addresses and pseudonyms separate for the various projects I was involved in, if only to contribute and not impact my life. To this day, when I push something, I release it as MIT for this reason. Anything I put out there is free for you to scratch your itch, the same way I scratched mine. There's no need to share it back, or file an issue - maintain your own. That way, there's no need to worry about goals or personalities clashing.

tfigment 8y ago
I relate to this and am same. I still feel guilt sometime because I release something and work on it for a couple weeks but then I'm usually done. Its likely full of issues but did what I wanted. Sometimes a community forms around it and there is a expectation of continued support from me but that is not my goal. Few people will actually take up this code from what i can tell or its forked and not released. Im generally ok with it but feels like there should be a better path for this stuff.

xg15 8y ago

> This isn't limited to "open source". It is probably just a people problem. My understanding is that those kinds of "people problems" are exactly what CoCs are attempting to tackle. (Or at least that's one motivation)

radarsat1 8y ago

As a maintainer I've also had weird situations come up where someone suggests something perfectly good, and even includes code with an implementation, maybe even something they've spent significant time on, but even though it's a good idea and potential contribution, it just doesn't "fit" with the idea we're going for.. it's actually hard to say no to people for reasons like, "Your code is good but we don't want it because that's not the right interface according to the use case our software is designed for." Clearly the code is good for the person proposing it, and I can't even reject with the excuse that it's bad code in any way, all I can say is, that's not what we want to do right now. It's kind of heartbreaking to reject things on that basis. I've even found myself having to reject contributions purely for the reason of, "your code is good but it's too much.. I don't want to maintain that." Believe me it sucks to reject a significant contribution, but the fact is that what often happens from experience, is that someone scratches their own itch, submits a huge patch, and then walks away once it is accepted. And then it does indeed become my job to maintain a bunch of code that I didn't write and aren't familiar with. So I find that these silly practical issues crop up a lot that have nothing to do with code quality per se, but more to do with being pragmatic about maintenance and the goals for a given code base. It's hard to know how to give the right answer, socially speaking, and I think I have definitely come off as snarky in the past doing so, but it's not intentional. Sometimes acceptance or rejection simply doesn't depend on the code but on other factors that are hard to convey properly on an online forum. At least the message for contributors is, small one-off fixes are one thing, but if you're going to spend significant time working on something, please discuss it upstream before proposing a huge patch that might not even be something we want to integrate.

smaddox 8y ago
That is somewhat unfortunate, but if I take a bit of time to think about it, it seems like a necessary consequence of a successful open source project/movement. Perhaps, in cases like those, you could find a way to split the base project into two or more modules, making it possible to share code with the new fork, but such splitting has non-negligable cost in terms of ossification of internal APIs and maintenance overhead.
- 8y ago

stcredzero 8y ago

If the community person dislikes the question asked, or the use that people make of their software, why do they take the time to write answers at all? Usually being pleasant is a question of writing less words as well. These people go out of their way to add snark to the response. This isn't limited to "open source". It is probably just a people problem. It's a people problem. In the 70's and 80's, these would've been the kids that would taunt you or worse in the hallways, gym showers and locker rooms. Not literally, exactly. It wouldn't necessarily have been the same people. However, human nature includes a certain degree of aggression and "us vs. them" groupthink. It's only a question of how it gets expressed. We know that such forces can be negative. We also know that such impulses can be channeled for positive ends.

danShumway 8y ago

Even when maintainers are super nice, it's work to get a patch into an acceptable state for a project, and at least to a certain extent it's not clear why that work should always fall on the person who's making the patch for themselves. If a forked repo solves a problem and keeps it Open Source and available, and their solution genuinely is good and useful for the community, then there's nothing to prevent the original repo from pulling their code and reformatting it or adding tests. Upstream maintainers are totally free to go downstream looking for patches. They don't need to ask anyone's permission or convince somebody else to make a pull request. Just copy the code upstream if you care about it. I've done this in the past with public projects -- fixed a problem, left a quick note on the original repo saying, "hey, I have solution but it's just for me. You're welcome to adapt it if you think it's worthwhile." I've also done the opposite and worked really hard to get something accepted. I've also walked the middle line, where I coordinated with upstream to contribute to an official API, but at the same time made it clear that my downstream fork was going to diverge and stay specific to my use-case. It's nice for patches to get merged back upstream, and it's nice for patch writers to put in the effort to do so, but part of the point of Open Source is you don't need to wait for that to happen. I have no qualms whatsoever about maintaining a personal fork of someone else's software. If I'm patching something to solve one of my problems, I'm going to search for a solution that solves it as specifically and narrowly as possible. I'm not going to worry about what your coding style is or what you'd like the API to look like. Then once my problem is solved, if I have time, I'll think about broadening it or altering it to fit with the overall community. But that's a separate step that doesn't have to be specifically my chore. Anybody can do it.

scotty79 8y ago

> just cannot be bothered dealing with "you're doing it wrong" comments when my fix isn't deemed worthy. Please just post it. Ignore comments. Your fix will most likely prompt them to write their own fix for the same thing in the following weeks or months. They may not even mention you or use your single line of code in their branch but it's you that gave them ideas and belief that problem can be fixed. If you want to get things done on the internet then post your almost right solution and look at all the people that rush to correct you.

scotty79 8y ago

> ... writing twatish answers. It has been a problem on stackoverflow.com too, ... I'm most annoyed by answers "you shouldn't want to do that" from shallow experts. I can bare "you shouldn't want that, that's a horrible idea because ..., but if you must you could do it like that:" from deep experts. I can bare the tone if the response contains actual information, but not if it's just the tone.