Choosing to stay out of the community | Hacker News Reader

Choosing to stay out of the community

rachelbythebay.com

242 pointspulisse198 comments

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.

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.

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.

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.

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.

> 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?

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.

There was an upvoted article on HN the other day [1] where the gist of it was:

"If you don't have a separate documentation website for your open-source project, it's not worth my time."

This is as superficial as it gets.

[1] https://news.ycombinator.com/item?id=18150876

I take your point but good documentation is not superficial.

I'm referring to the stipulation that documentation has to be dressed up with a full-blown website.

Wow that whole thread is awful. So much entitlement, so much inaccuracy, so little insight.

It’s also that if the guidelines about the whitespace are so important, just automate the thing.

I like quite a lot the approach taken at my $dayjob: the files that you change must not change if one uses ‘indent’ twice on them (twice because some of indent’s opinions are bistable). And there is a script that brings the non compliant files to compliant state.

So I don’t have to think of whitespacing at all while coding and can make “good” before submitting. And, even if I don’t like that particular style of whitespacing, I do admit the code which is uniformly whitespaced is easier to read and maintain.

I really like how a number of languages now have a code formatter built in (Elixir, Go(?)). I might not always like how it formats my code, but most of the time I do. Furthermore, it:

1) spares everyone a whole bunch of bike-shedding and bickering

2) often teaches me how to better format my code

3) speeds up my work slightly because quite often I can just messily write my code and rely on the formatter to fix it.

In most cases, the process has some hidden steps and hoops which are unrelated to patch.

The patch methodology will be probably criticized. Sometimes this criticism will go beyond the boundaries and leak to personal space of the developer, and the dialog will turn abrasive or abusive.

And a patch written in two days will be revised an revised for weeks. Not all revisions will be made for logical or legitimate reasons.

Then the developer will submit its patch, it'll be accepted at last, and the developer will never patch anything again, for ever. It'll be burnt out in a single patch.

Some communities do this, and often they don't know what they're doing.

I personally wouldn't do kernel patches. Heck, can't dare to ask anything to the list. Because I don't want the harassment. Also there's the silent ignorance in the mailing lists because your question is too basic or uninteresting or just posted to wrong-ish list. That's a different matter, but results in the same avoidance reflex.

Some anecdata:

I tried to submit a patch once (https://patchwork.ozlabs.org/patch/660921/) - which to me felt exactly as you described. I didn’t get the reply to my questions questioning the review comment (maybe I didn’t understand it completely so was not worthy of a response?).

In any case, luckily that was not in a critical path for me and then I have moved to a different project so I abandoned it - just seemed like a not so productive/happy use of my time.

And now I feel actively disinterested to ever attempt contributing again.

I can see the other side of the coin as well - the need to maintain the code quality, and probably the burnout of multiple “stupid” questions/patches. I can imagine how it gets tiring especially if one does it in their spare time.

Do I have the right to say “they need to be more patient/welcoming”? Probably I don’t - but equally I don’t fancy being someone’s emotional grounding.

So I will rather stay on the sidelines.

> I can see the other side of the coin as well - the need to maintain the code quality, and probably the burnout of multiple “stupid” questions/patches. I can imagine how it gets tiring especially if one does it in their spare time.

It gets tiring only if you despise answering these "basic" and/or seemingly "stupid" questions. In my day job I'm a system administrator of an HPC cluster, and we also do technical support ourselves. Users ask questions "wrong" all the time. Not enough information, seemingly simple details, etc. I personally never get mad at them, because they don't know how to do it better. We generally try to guide them, point to the correct places, test the problem ourselves, and see what happens, but never intentionally harass them.

You can maintain the code quality with a polite "Why this patch didn't pass the inspection" letter. There's a similar effort called "I downvoted because" [0], but even giving links from that page requires some niceness. Just pasting the relevant URL also looks and feels rude.

If a user is intentionally volatile, we defuse them. If they're intentionally malicious, we block/prevent them. If they're intentionally smarmy or snarky, they get polite but firm answers. At the end they cool down, because they cannot fuel their anger with our reactions.

> Do I have the right to say “they need to be more patient/welcoming”? Probably I don’t - but equally I don’t fancy being someone’s emotional grounding.

They don't need to be patient, if one is intentionally testing their patience. They don't need to be (overly) welcoming, but they need to be polite enough to tell that, or point the person to right way. Saying "no" is not a problem, but not pointing the next step is problematic, especially if the asking person doesn't know the better.

At the end, these behaviors are not because of the person asking the question, or sending in that "stupid" patch. It's about the person who's reacting to the patch/question/whatever. They don't like something, or see something and get triggered, then unload all the rage upon the asking person regardless of relevance of the rage.

For one, knowing oneself better is as essential knowing the stuff that you're working on. Having a baseline niceness is a win for everyone, because it makes life much simpler without softening boundaries. In fact, it strengthens them without making them intimidating.

[0] http://idownvotedbecau.se

I am responsible for my emotions, and my reaction to something is my problem. I get this.

Programming is creative. Just like artists, writers, any other creative process. We get emotionally involved with our work and we become emotionally vulnerable when we show our work to others.

So submitting code to the scrutiny of others is a vulnerable space for me. If the reaction of others is "this sucks" then I have a negative emotional reaction to that. I understand that this reaction is my problem, I'm not blaming the other person for their response, but I still have a negative emotional reaction.

I do not want to emotionally disassociate myself from my creative work so that I no longer have this reaction. I enjoy being this emotionally connected to my work.

I'd rather not show my work to others, or to only selected people who I can trust not to respond with something that will hurt me. I know this about myself.

Disclaimer: I'll intentionally use "you" to address you, since you expressed some emotions, and I'll directly address them, but I won't hurt you.

> I do not want to emotionally disassociate myself from my creative work so that I no longer have this reaction. I enjoy being this emotionally connected to my work.

I also see programming as a form of art, and I'm also attached to my code emotionally, however you need to understand that, when someone says that your code "sucks" it's their point of view. Neither you nor your code sucks. It may not be doing something in a certain way the critical person likes or prefers. Even if your patch is plain wrong, this doesn't change the real value of you or your code. You've put the effort and tried something. You're the man in the arena [0].

If the person is agreeable, you can talk and improve the code and the persons involved in this. If not, do not take the critics' criticisms and move on. Even if your patch or code is wrong, it doesn't give the person the right to hurt you. So don't allow him/her to do so.

The critic might be right in its words, but wrong in its attitude. You can learn to separate the two, and thank for the advice while giving back the thorny part. Yes it's a very hard thing to learn, but when you learn it, you can keep the ability without much maintenance. When you learn this skill, you do not emotionally disconnect from your work. On the contrary, your connection is stronger and the elements cannot affect this connection between you and your work. Also, you have a much pure and powerful kind of empathy as a result of this learning process. Because you can look from the eyes of the critic, with the disconnection of the critic from your life and work, and process this criticism with the emotional connection to your code. This transforms the whole situation into something hard to describe, but it's very powerful indeed. Last but not the least, it's free from the emotional damage that critic deals (knowingly or unknowingly).

Code on, keep creating and at least put it somewhere visible. You don't need to shout about it.

[0] http://www.theodore-roosevelt.com/trsorbonnespeech.html

Yeah, there are strategies for dealing with criticism. I use this a lot when dealing with customers (I love the analogy of the feedback bucket - put the shitty feedback in the bucket and use it to grow roses of insight). It's easier to deal with this kind of criticism, because the customer is always right.

But add the emotional vulnerability to the well-known entitlement stuff ("I used your code in my project and it doesn't work, so you need to fix it"), and the hassle of dealing with other people (ugh), and, well... why bother?

The upside that you describe - or struggle to describe... I've never experienced that. I find myself explaining my code to someone because they criticised it without understanding it, and there's no feelgood there. I wish there was.

> Yeah, there are strategies for dealing with criticism. I use this a lot when dealing with customers (I love the analogy of the feedback bucket - put the shitty feedback in the bucket and use it to grow roses of insight). It's easier to deal with this kind of criticism, because the customer is always right.

That's a good strategy too, however I do not explicitly use the things I said as a "strategy". I always live like that, so it can be said that it's my default mode. However, I need to say I was much like you. With some hard work and determination I've changed myself.

> But add the emotional vulnerability to the well-known entitlement stuff ("I used your code in my project and it doesn't work, so you need to fix it"), and the hassle of dealing with other people (ugh), and, well... why bother?

I wouldn't bother too, but send them a bug report template to fill. If they say it doesn't work, they need to put the money where their mouth is, and tell me exactly why and how it doesn't work.

> The upside that you describe - or struggle to describe... I've never experienced that. I find myself explaining my code to someone because they criticised it without understanding it, and there's no feelgood there. I wish there was.

You're telling yourself. My code didn't suck, but they didn't read/understand it. Don't forget that the problem is on the other side of the fence. You don't need to feel bad, because the other side didn't understand it. It's not because your code sucked. Don't let them throw their frustration to your turf.

The more I think about it, the less I believe the whole "I am responsible for my emotions". It is true in some situations and not in others. As a strategy, it makes it impossible to adress abusive or manipulative people while it makes it easier for abusive people to get their way. You are responsible for reaction, but certain emotions are perfectly natural and normal.

0.) There are many people who purposely insult others and then brag about it. When I go out of my way to make you pissed off for own pleasure, then blaming you for being angry is unfair. Then there are people who push and see how you react. If you are doormat, you get more abuse. Here insult have purpose.

1.) This ideology is more focused on pretending emotions don't exist or framing you as bad/weak if you have then. But, it allows you to "retaliate" against third parties.

2.) It is asymetric. Insulted person is expected to have perfect emotional control while the lack of such control on the side of the one who insulted you is ignored or seen as strength.

3.) It leaves you with two options - leaving or bending over to abusive people. There is little space for standing for yourself without becoming abusive yourself.

Imagine a group of respectful people competing with each other. Then the abuser comes in and intentionally causes stress and discomfort to competitors. If you don't allow the respectful people to address his behavior or openly talk about its consequences without sounding "weak", then the abuser is in advantage. They spend effort to manage those negative emotions while he does not have to. He is less in advantage where "stop insulting me" or "stop constantly undermine me" are legitimate things to say.

I am not a perfect human being. I can react in ways that are not ideal when situations trigger my flaws. That's OK, as long as I accept responsibility for that.

I am responsible for my emotions, but that doesn't mean I have to apologise for them. If I think someone is acting like a dick, and my reaction to that is stress and anger, I'm OK with accepting responsibility for my anger and showing it anyway. I am human, I have inappropriate emotions at times.

However, blaming the other person because "they made me feel angry" is not helpful. They acted like a dick, and they have to accept responsibility for that. I got angry, and that's my responsibility. I could have chosen not to get angry, and I refuse to give the power to make that choice to someone who acts like a dick.

Responsibility and authority go together. Accepting authority over my emotions means I have to accept responsibility for them. Refusing to accept responsibility for my emotions also means I'm refusing my authority over my emotions. Giving others control over my emotions is not going to lead to good things.

I also don't believe that "I am responsible for my emotions". It frames emotional / emphatic people as weak as you say, however I don't also think that retaliating with anger is a solution to this problem, but I also don't imply pacifism as the solution.

Every kind of bullying is deteriorating and highly damaging. I've experienced this for 10 years straight, and I decided that I will never do anything to anyone that I don't want to experience (Don't sow anything you don't want to reap).

However in real life, we need to protect ourselves against these manipulators and bullies. We can overpower them, we can play their game or we just become too hard to attack. I've chosen the third way. When someone attacks me in any way, I don't provide them any fuel with my anger or sorrow. I give them nothing. If they're criticizing me, I note words (but not the emotions), and give them a hard think. If I can get anything useful from it, I use the advice. If nothing comes out, I throw everything away.

Of course I'm not perfect at this, I also have soft sides. I sometimes short circuit after the event, but I sorted out most problematic parts of my life that way. I even saved my career that way. It's not an easy thing, but it's highly rewarding if you ask me.

I agree with you. It is ok to be angry, but anger does not excuse everything person does and anger does not mean that I am in the right.

I would also add that there are many people who are not bullies and still may do something bully-like without realizing it. I know few people like that - somehow they are not good at seeing your reaction the way others do and are bad at predicting it. With them, if you just let it be, then it get worst. If you openly tell them to stop and explain how it hurts those around, then it gets better.

Even neurotypical people including me can do hurtful things without realizing. Feedback and communication helps.

I am sorry to hear you were bullied. I also have experienced this.

I know this will be hard to listen to, but it is my truth.

I was bullied because I gave them my power. When I took responsibility for my emotions, and refused to fear them, it all changed. Power comes with responsibility. When I took responsibility for my fear away from them, I could take my power back and it all stopped.

It sounds like victim blaming, I know. "Just ignore them and they'll go away". All that crap. For me, it was more like "no one is ever doing that to me again". I refused to be afraid any more. I would face them, fight them, do whatever it took, take whatever they did to me, but I would not be afraid any more.

I am responsible for my emotions. I refuse to give anyone else that power over me.

> In my day job I'm a system administrator of an HPC cluster, and we also do technical support ourselves.

The difference is that you are paid to do that. You are not helping those people out of personal altruism, so wasted time is not lost. You did a successful job nonetheless.

If I on the other hand like to help people with coding problems in my free time, and they don't even bother to properly format the code they want me to look at, I'm wasting time if I still try to read it. My free time, and other peoples time that would need some help too.

> The difference is that you are paid to do that. You are not helping those people out of personal altruism.

I'm not working as a system administrator for its pay, I work here because I like my job. Payment is a side effect of it. So it's like a paying hobby for me. It also other side benefits like being able to carry my academic knowledge to my work and vice versa.

> , so wasted time is not lost.

I do not consider helping a person to learn something, to show something they don't know, or to point them the right direction as wasted time. It's kind of planting seeds. It may come alive or not. I just put in the effort that I can.

> You did a successful job nonetheless.

Honestly, thanks. :)

> If I on the other hand like to help people with coding problems in my free time, and they don't even bother to properly format the code they want me to look at, I'm wasting time if I still try to read it.

I'd auto-format in Eclipse and try to read for five minutes. If I fail, then I send back my formatting work and politely ask for making it more readable. This is my way of saying no: "Hey I can't help you, but that's what I've done while my time allowed. If you do your part, I'll try again to do my part when I have more free time."

My time, and nobody's time is for free, and using it effectively is very wise, you're right!

I've had a similar experience when submitting a patch for an open source Google product.

Jumped through their hoops, was met with denial and skepticism of a problem hundreds of people were reporting, that is until one of the skeptical project members independently cited a standard that I had cited in my pull request. We go back and forth for two weeks to refine the pull request, where I am doing all of the revisions. Eventually they're given approval and I assume all is well.

About three months went by, their product is still broken so I check on the pull request and it appears that the relevant people tested and approved of my patch... but they wanted a test suite written for it. They expected me to write and submit tests for their broken product after spending a month of my free on their project.

I was left with feeling as though Google employees should just do their jobs if they want their products to work, as I'm not wasting any more of my time by doing work for them for free.

This is a sharp contrast with other projects I've contributed to, where the response has been "Thanks for pointing out a problem with our project, let's do everything we can to fix it" instead of an uphill battle that was my experience with Google.

If they want the tests to be written beforehand by the patch developer, they need to write that in the guidelines. If that isn't present in the guidelines, or they're not accepting patches to testing/building process, they should write these tests themselves.

Otherwise it's just the same thing as child labor. Unethical, ugly, and sad.

Honestly, aside from issues with the process it's also just embarrassing. IMO, that's what is causing a lot of the issues that are being surfaced these days in oss. No one likes to be told they're ignorant. Add in a smarmy attitude and poor social skills and only the most confident or skilled people will contribute; which isn't a bad thing to be honest.

We've come a long way from the RTFM days but learning something as complicated as programming tends to make people sensitive about what they do and don't know.

It's a delicate balance. On one hand the project and the community benefits from a lot of ideas. On the other hand, a strong ego with poor understanding can not only destroy a project, they can cost a lot of people a lot of time, money, and heartache so some sort of barrier to entry that turns some people away isn't a bad thing.

At the end of the day, it'll all work itself out as long as we keep the projects open and free. Popular projects attract talent which in turn improve those projects.

> Add in a smarmy attitude and poor social skills and only the most confident or skilled people will contribute; which isn't a bad thing to be honest.

Personally I'm playing with computers since Commodore64 days. I'm occasionally publishing papers about algorithms that solve real problems that I develop (just submitted one yesterday). I'm confident about my skills, and generally know about my stuff, however I don't like uncivilized brawl.

So to be able to be a developer whose patches to be accepted, I need to be a person who can put up with snarky comments, and be able to return them with the same level of abusiveness?

Sorry. Life is too short for that.

> Add in a smarmy attitude and poor social skills and only the most confident or skilled people will contribute; which isn't a bad thing to be honest.

It is a bad thing, because the "most confident" and the "most skilled" are almost never the same.

Theoretically, rude gatekeeping can destroy confidence, but it can't really destroy skill. Of course, the rude gatekeepers typically don't recognize skill either...

"...and only the most confident or skilled people will contribute; which isn't a bad thing to be honest...some sort of barrier to entry that turns some people away isn't a bad thing"

Confidence (or as I look at it, social pain threshold) is unrelated to skill.

  If you have a patch, and others know how
  to make it better, why would you forgo
  that chance to learn something?

If I have patched the code to scratch an itch of mine, by the time I submit the patch my itch is scratched - no subsequent changes will contribute to scratching my itch, no matter how good they are.

At the same time, many open source projects are subject to constraints or requirements that are entirely reasonable from their perspective but that take time and don't much help or educate me as a one-off contributor.

For example:

* Paperwork like contributor license agreements

* Supporting obsolete (or nearly obsolete) platforms, and avoiding modern language features to maintain that support.

* Compatibility with project features I don't use, but other people do.

* Getting all the integration and test features of a finicky build pipeline to work, not just those needed to make a build.

* Correctly dividing up changes in multiple areas into multiple patches reflecting the fact different changes will need to be reviewed by different people.

* Requirements like code style and automated test coverage that contribute statistically to lower bug counts at the project level, but that don't reveal any bugs in my specific contribution.

* Code structure issues specific to the project, which as a one-shot contributor it isn't productive for the project to educate me about.

* Conflicts with planned future changes that aren't really documented very well anywhere - or that are documented only in places I didn't find, like the archives of a high-traffic mailing list.

d is the only one that the people paying me care about.

The benefit of not dealing with upstream is that I can get more done that they do care about.

I also got burned in a case where I was added to a project as a maintainer and then the original maintainer disappeared, 10 years later I am still getting support requests on a project I just submitted bug fixes for.

The time spent "improving" in the terms of the project is time not spent improving in areas that matter to you (or your employer) more. If the fix works and the itch is scratched, extra time spent developing specialized knowledge about that project's build/test systems or standards or personalities for is likely not time well spent, especially if the likelihood of submitting a second patch to the same upstream is low. If you plan to keep contributing over the long term then sure, but that's not the only case.

>If you have a patch, and others know how to make it better, why would you forgo that chance to learn something?

Maybe because there is not much to learn from people who cannot give you feedback about your patch without calling you an idiot, or making sure that they show that they are above your level.

Because in toxic projects, they are not about teaching you something. And because the only thing you learn is to never contribute to a toxic project again.

Also, why don't you try to create a github account, where you disguising yourself anything but a white guy, and start to contribute. Or just ask any female developer about their experiences.

>You submitting patches has nothing to do with the community.

If you seriously believe this is true, you have no idea about software development.

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.

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.

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.

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.

And as usual, it's a question of degree. If the bulk of development is done on the official repo and people just do occasional private forks for special use cases, I don't think there is a problem.

What's problematic is when the balance shifts and the bulk of interesting developments is done in private forks.

> 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."

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.

This is surprisingly often true with companies too.

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).

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.

Can you expand the acronyms please? Except BS, I figured that one out

MYOB, Mind Your Own Business

PR pull request

SMH = shake/shaking my head

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.

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.

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.

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.

> 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)

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.

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.

Interesting you say so, in one particular project this has become such a problem that I have indeed been thinking along those lines.. of breaking it up into more than one repository so that people can just build their own extensions and I would just maintain a kind of "kernel interface". I do think it's a useful way to go, but it does take some time to redesign with that in mind. It's hard to know when it's "time" to do it, because it's usually only after a project gets to a certain size and has some popularity that it becomes simultaneously difficult to (a) integrate external work and (b) to rewrite the project to make (a) easier. The only answer in some cases seems to be to start a parallel project, but then you're back to the problem of whether this gets any traction in the community, or is seen as "hostile" somehow.

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.

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.

> 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.

> ... 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.

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.

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.

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).

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.

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.

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.

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.

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?

>You don't operate in a vacuum when you work on projects.

OP Is exactly describing working in a vacuum. They've got no ego invested in the project and whoever does can decide if they want to use their modifications.

>What if someone comes in the way of you building things? What then?

I don't think you're describing someone getting in the way of you building something. It seems more like, "What if you don't feel validated, by some community, after you built something?" Which is something leadership of any project might choose to evaluate. Does the project benefit more by trying to provide validation to everyone who makes an attempt to contribute or not?

In my experience, providing validation for anyone other than children is an enormous waste of time. Especially when building something.

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.)

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?

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.

Yes.

Given how difficult this is, it's no surprise to me that potential contributors might not want to stick their neck out, as expressed in TFA.

Yes, I find it helps to say "here is what is needed, anyone should feel free to take it from here." In my first response, so it's clear I don't expect anything more.

Quite a few PRs were improved and merged this way, and I think the feeling of community is enhanced when a PR goes through multiple revisions by multiple contributors.

"(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.)"

Go ahead and close them with notes that they can be re-opened if they come up to standards, but that you don't have the time or interest or capability to do it yourself, and that you are not judging them beyond this comment.

Closing a PR doesn't mean as much as people kinda think it does; they can be re-opened. Closing them without comment is harsh, but it correctly represents the current state of the world, which is that without changes, they aren't going in. Closing them with comment is the best compromise between all the issues.

As a maintainer, you need the "open PR" list to be a list of meaningful, actionable items. You don't have all that many tools to use, and the ones you do have need to be kept sharp. It's OK.

This. If you have 20 open PRs and all of them are old, they should be closed. Same for issues if they don't appear to have any resolution or are too stale.

If people keep asking for a feature that isn't ready, you can make an issue that depends on the PR that describes the acceptance criteria for the feature, and send them the link. Or you can edit the top of the PR description with the acceptance criteria/status so new people see it immediately.

A third option is to refuse issues and PRs entirely and just use mailing lists. Less people will ask for a feature because it takes a lot more work to dig through mailing lists, and by that time you've already found the thread and know why it isn't accepted yet.

On a technical level, I think this encourages the contributor to delete the branch, in which case it's gone for good and benefits no one.

If GitHub automatically saved a copy of each PR branch, I would be more receptive to this advice. This would potentially cause a lot of other problems...

> dozens of open PRs on his repo, none so bad they must be closed, but also not good enough to merge

But you've decided to reject them. Isn't that just what 'closed' is for?

They're not rejected. They're just not ready.

If it were something really stupid or wrong, I'd close it, sure.

For people criticizing this approach as a selfish one:

Fixing toxic communities is work. While it would be a public service for the author to do so, she is under no obligation and probably has a day job and a life that take priority.

I praise community-builders and community-shapers and code-sharers and code-reviewers to the heavens, but I'm not going to knock someone who just can't be bothered to do all of that.

You don't need to fix a toxic community to just submit your patch. Just submit it, and if they don't want it, they don't want it. But at least you've done the bare minimum of giving back. If they want to tell you to fix your code formatting or something, or make your comments less phallocentric or whatever and you don't like it, don't make the changes - but you still ought to submit the patch.

On the other hand, reviewing code is also work. One could argue that if you don't intend you follow the contribution guidelines and work with the maintainers to get the code to a state where it's good enough to merge, you are wasting their time.

I agree, but I also think it's easy to avoid that. If you say in your cover letter "I appreciate that this might not be in a good state to merge, but I don't personally have any more time to spend on it and won't be able to respond to any code review; I'm posting it to make it public in case it helps somebody else", then the project knows where it stands with the patch, and can invest time, or not accordingly.

(I did something like that with a half-done binutils patch once. It wasn't committed, and I didn't expect it to be. But I was happier having put it out there, so somebody looking for weirdo-TI-COFF-format support maybe had a place to start.)

You're right--communicating about the intent of a patch is a good idea, especially if that intent is outside of normal expectations.

In a similar vein, I recently learned about prefixing a pull request on Github/Gitlab with "[WIP]", or a "work in progress", to suggest that the proposed changes are for informational purposes or not yet complete.

Thanks for mentioning GitLab, Community Advocate here.

WIP is really used, and we even have documentation about it https://docs.gitlab.com/ee/user/project/merge_requests/work_...

this is how private warez torrent sites work

It's true and they're now mostly dead. Either gone completely or in a zombiefied state.

This is the fate of virtually all closed communities. Yes, you avoid many problems, it's tempting, but you die in the end. Usually, quickly.

Open communities suffer from many problems, and employ a variety of not-terribly-pleasant solutions like dictatorships to deal with those problems. Yes, many can be described as "toxic."

But they're also alive.

And I've seen some of these private trees. The quality tends to be rather underwhelming. As you would expect from someone tinkering at the margins without cooperation from the main drivers of the project.

Lots of private torrent sites are alive and kicking, and lots of open communities die. I'd need more evidence that openness vs closedness is what kills them.

Their forums are ghost towns. What.cd still doesn't have a successor, and one of three strong pretenders didn't even manage to stay online.

It may be caused more by competition from Spotifies and Netflixes than their closedness (although I don't agree) but they're certainly not alive and kicking.

$10 a month for more content than I know what to do with is such a cheap price to not have to deal with the pain of torrenting.

If it was $20 per DVD like in the past, the pain of torrenting was far less than the pain of the cost of buying your favorite movies.

I really think it's that simple. This value equation alone means that a majority of people won't care enough to go the extra length to participate in torrent communities. They'll just pay a small $10 a month to watch whatever they want, whenever they want, on any device, anywhere. That'll kill the incentive right from the start.

> They'll just pay a small $10 a month to watch whatever they want, whenever they want, on any device, anywhere.

Unfortunately this doesnt exist. I would gladly pay it. Netflix isnt it either, no matter how much they pretend they have all the content, the movies which I am interested in, I have to torrent, because they simply arent on netflix. Their library is so bad that my first instinct is "oh lets look for a torrent" instead of "lets check netflix if it has it" when I want to watch a movie.

If only the $10 a month would actually give you a good value for your money then I would gladly pay them $50 a month starting today.

- They mostly host newer movies and series. If you want something older, tough luck.

- Ads for other shows. Annoying. I can go to the recommended section if I want to. They should be opt-in, not opt-out. Not to mention the clunky UX to turn them off (and I am pretty sure that's by design so less people opt out).

- Flaky connection sometimes -- and I have a gigabit link at home. Yes the internet is a complex graph and it might not be their fault, I know. That's fair but it's not my fault as well. And when I pay money I feel entitled to good service. The tech details are their problem, not mine.

Torr3nting is very often not done just because somebody is a scumbag and wants to see Brad Pitt go broke. T0rrenting many times is done because (a) you get the entire content and can later watch it anytime you wish, including repeteadly, without lags, buffering or quality drops, (b) because it gives you the option to watch offline when you are off the grid -- like I download gaming tournaments from Twitch and put them on my tablet, and (c) the paid services are not good enough.

Curious why you don't think redacted.ch is the successor to what.cd? I certainly wouldn't describe it as a "ghost town" or "not alive and kicking".

Also wondering what you think of the idea that what.cd may have been too big for a private tracker to exist sustainably?

Redacted is definitely the successor to What.cd.

Better discussion can typically be had on community engines than specialized forums these days, unless they are large and have a decently long history, e.g. bodybuilding.com, honda-tech.com, etc.

I'd guess most discussion in such places is probably meta. tech support, or non-tech support.

Private torrent sites are hardly "private" in the same sense as being discussed here. They're private enough to legally defang the RIAA, but it's slightly more than trivial to gain access to any of them with even the slightest amount of savvy.

The "private" being discussed are much more exclusive.

> It's true and they're now mostly dead. Either gone completely or in a zombiefied state.

This is the fate of virtually all closed communities.

You will have to do better than that.

Torr3nt sites are pursued relentlessly by authorities and are aggressively closed in what people would call censorship just a short 10 years ago.

I know a few t0rr3nt sites in my country with semi-closed and small backbone communities and they are VERY functional and very lively.

I have been running Open Source projects for about 15 years, which implies moderating the communities around those projects (in my case, very small communities). I'm familiar with toxic environments. I once sent a very stupid question to the qmail mailing list - it did not go well for me. But I learned a lesson from that beat-down.

I make serious efforts to create an inclusive environment for my projects because that is what Open Source software is all about IMO. Any contribution deserves respect, it's a gift to the project. Maybe the PR needs some work, maybe it's total crap - but it's a gift either way and that should be respected.

It makes me sad to think people feel the need to maintain private repos just to avoid potential conflict with project maintainers because of toxic environments - but I understand that is a reality. I would like to counter that with the fact that not all projects are run that way, and some are very willing to accept contributions.

> It makes me sad to think people feel the need to maintain private repos just to avoid potential conflict with project maintainers because of toxic environments - but I understand that is a reality.

So you get sad for me because I am tired, burned out and want to get stuff done without the inevitable drama so many people feel they have to inject in everything?

Thank you for being sympathetic. ;)

This was half-sarcastic / half-serious.

---

On a totally serious note, you cannot at all blame anyone for wanting less -- or zero -- emotional baggage added to what should be a professional exchange of code and conversation points. I seriously cannot and will not care if somebody has a shitty life and spouts poison at me because I try to be helpful and they have nobody else to vent at the moment. I refuse to participate in a free therapy / rage unloading session with them.

As we get wiser, we start to get economical with our energy expenditures. Even more conservatively so with emotional expenditures. That one can feel like total crap after even one hour of drama is a harsh reality -- and the fact that many of us choose to avoid ruining our day is absolutely our right.

Nothing for you to feel sad about.

While I don't think her solution is the best, I can't say I disagree with the spirit of this post. With politics being dragged ever more into the software world, people attacking everyone for any perceived transgression, attempts to get people kicked out of communities, or even fired, over social media comments, you really need to consider what you're exposing yourself to by getting involved in the open source community. You would think that a community based on giving away typically very expensive effort would be more welcoming, but somehow we've ended up with this.

It does seem like this is just part of some wider trend though. It's not just the software world, public communities in general seem to be destabilizing and radicalizing.

It's not perception. It's a byproduct of a few different things. Close interaction between people of different social classes, lack of faith in governmental institutions, massive changes in labor markets, and in the U.S. in particular massive disenfranchisement through gerrymandering and archaic voting and representation laws.

The private/secret repos I'm talking about? They're probably operating under Fight Club rules. If you aren't plugged in, they don't even exist as far as you are concerned. You don't even know you're missing out.

I don't think this is staying out of the community. It's staying out of a community by forming another community, complete with its own set of good/bad people, rules, and expectations. Indeed, this is how many popular communities began - small, insular, quiet, before growing larger as human constructions frequently do.

Absolutely, and additionally to this, it's not forming a well-behaved community, it's forming a community that behaves in the way this particular person likes. It's just as likely to be full of snark and bitching.

This is likely, you say... according to whom?

The author clearly expressed their lack of desire to deal with drama or toxicity. What makes you think they will tolerate it in another community?

This is ridiculous. I have projects where I don't want feedback, and I have no intention of fixing bugs.

I put them on GitHub and turn off the issue tracker and PR notifications. If others want to fork, fine. If others want to discuss on PRs, fine. I don't care. I'm not fixing it. I avoid the toxicity by not partaking, not hurting my own career.

Rachel (the OP) probably cannot help but have emotional reactions to people's behavior even when the people are strangers and the behavior is entirely online. A large fraction of people are probably like that.

I would suggest therapy or religion to those people.

I hope no one reading my comment (GP) got the impression that I think there is something pathological about Rachel's choice not to publish her code.

Why though? If it's a smaller project there won't be tons of toxic people (or people at all) that participate. And what if somebody really finds some bug? How is it better to not even know about it, even if you don't plan to fix it?

I don't care if people post them to my github issue tracker, or fork my repository. People are welcome to collaborate. I'd even add someone else as an admin on it if they want to manage it. Some projects I have no desire to manage myself, and until someone opens an issue asking for privileges, I'm not going to make an effort to respond.

You can turn of GitHub notifications without turning off the collaboration features. Thus, while the collaboration features work, I simply don't collaborate. Easy peasy. If others want to, fine; I could care less. Just don't break my license.

Everything you've already heard about on HN and/or your favorite this-leaning or that-leaning web site.
This is a legitimate question, and I have an answer, but I don't think many people are going to like it.

My response to this is to say "wow, look at how screwed up these communities are", and then tag on "just like I always suspected", and then finally I add "and that reinforces my decision to stay out of them".

Makes me wonder why her writing does so well here.

Intelligent self-critical and/or masochistic penchants of the community, I'd guess :)

"Makes me wonder why her writing does so well here."

Yeah, that was funny to think about. I've only seen so many articles. Her write-ups were mostly technical dodging politics a lot. The back and forth, downvote mobs, or whatever kick in with politics on certain topics or views due to community's biases. If she stays away from that, then she can still be really popular.

Whereas, she just now admitted something that could be in the red zone for some portion of HN community in terms of benefiting, but not sharing, in FOSS. It's simultaneously a response that's understandable or folks might sympathize with for the portion that is concerned about toxic behavior in general FOSS and/or toward minority members in particular. Still a grey area in potential reaction here.

I find it fascinating to watch how these things play out. Regardless, her posts about spotting problems, solving them, and keeping them from recurring were pretty awesome. Most of us will probably still respect her regardless of how much she's embracing or dodging online communities.

I don't care one iota if she does or does not participate on HN or in any other community.

The only other post of hers I recall reading boiled down to her refusing to fix a thing at work that it was her responsibility to fix and wouldn't have taken very long, like a few minutes, and leaving it that way for six months, calling it "an experiment" to see if anyone else would fix it and then talking trash about everyone else at work when her boss finally told her to fix it already. It struck me as very unprofessional, childish and toxic.

She is the only woman that I'm aware of who blogs about programming. I'm not a programmer, so that might just be my ignorance showing. But my guess is that's the primary reason her writing shows up here so often, because it doesn't strike me as great writing overall and her attitude seems to be pretty toxic generally while she blames that on everyone else.

She could make a lot of the same points she makes without pissing all over everyone in the process. She could very reasonably say "I'm a woman in tech, so I deal with brogrammers 40+ hours a week and I have no patience left to do more of that in my off hours." She could say "Eh, different strokes for different folks. I share my stuff with people I enjoy talking with and I'm okay with that meaning it isn't out there in the ether for the whole world to access. We can't all be Linux."

She could make all the same choices she is currently making and describe them in her blog without gratuitously pissing all over a community that very likely accounts for a large share, perhaps even the vast majority, of her blog traffic.

> She is the only woman that I'm aware of who blogs about programming

While I cannot speak to your awareness, I can say for a fact that there are many women who blog about programming.

https://www.google.com/search?client=safari&rls=en&q=women+w...

Maybe programming blogs aren't that interesting to you so you don't have much exposure to them? I'm struggling to understand how you would not be aware that there are more such blogs beyond Rachel's.

I'm not a programmer. I already said that.

If there are many more women who actually blog about programming per se, rather than blogging about the problem of being a woman in tech, then I am even more mystified as to why her writing seems to be so popular here.

Because this is not site about programming, this is site about culture around programming.

This isn't a site about programming, nor about programming culture. It is a site for discussing things that are intellectually engaging and it is open to anyone who wishes to join.

My point is that programming per se articles are minority and often end up burried. And when they are here, they tend to be limited to few topics popular also among those who don't use them. That is not sort of content one goes for here, whether by men or women (which is not complaint) so it should not be used against anyone.

I will add that it is and should be ok to write your thoughts about communities and processes and culture and pop tech etc even if you don't write technically technical articles. Such blogs are pretty normal in programming communities. These things actually matter for those who deal with those communities daily. Moreover, Linux community prides itself on being tough and not caring and pissed off all the time on each other, so really, demanding that whover is commenting on it is nice to them and not pissed them off is odd. As far as linux community standards go, this article is remarkably nice - the only way to make it less nice is to keep opinions for yourself.

She can write anything she wants. My bafflement at why it is popular here isn't some kind of censorship.

There is a thing that happens a lot where people nominally argue for free speech in a manner that suggests that asking X question or saying X thing should not be allowed. If one genuinely believes in free speech, then that doesn't work.

As best I can tell, it seems to frequently be rooted in an assumption that asking such questions is really some passive-aggressive agenda to prevent someone else from expressing themselves.

I happen to have a deep and longstanding interest in social phenomenon. I find it fascinating to puzzle out the details of why X flies when it seems like it shouldn't, but Y doesn't when it seems like it should. This is frequently interpreted as nefarious behavior with some preconceived agenda. It really isn't, anymore than wondering at some edge case programming bug is inherently nefarious.

On a technical level her skills/knowledge are world-class and her most successful posts[1] have been tech-focused.

[1]:https://hn.algolia.com/?sort=byPopularity&prefix&page=0&date...

Thank you.

"It struck me as very unprofessional, childish and toxic."

Just reword it as an article with the headline "Don't Be a Hero". Suddenly it's valuable career advice.

Hi! I've written open-source and Free Software for a decade. I don't see anything wrong with Rachel's behavior, her opinions, or her desire to not get involved when there's stupid toxic shit to deal with, and I don't understand why you've written four posts over three hours complaining about her. It sounds like this is a case of women policing women.

By my count, it's more like six comments, so you missed a few, possibly including this one where I make it clear I'm not policing anyone:

https://news.ycombinator.com/item?id=18182668

You, on the other hand, appear to be trying to police my behavior, though you aren't a moderator on the forum.

> something that could be in the red zone for some portion of HN community in terms of benefiting, but not sharing, in FOSS.

I admit, I'm in this camp where my gut reaction is fairly negative. Truthfully, I'm trying to sit on this info a bit and come to terms with how I feel with it (with respect to a personal strategy), because my reaction was pretty visceral. I mean, it's okay, it's not disallowed by most licenses, but if I wanted could I do this and feel okay about it?

There's a wide spectrum between doing work and fighting to get it included and doing work and actively keeping it limited to a few individuals. At a minimum, just throwing what you have out to the public and saying "here, do what you may with this, it worked for me but I wash my hands of it if you want help" seems a sane middle ground to explore.

I read this as being similar to “The king is dead long live the king.” Toxicity is just swapped with different toxicity. The road to toxic is often paved with good intentions.

IMHO Some of the responses here are missing the point. That seems to be a common theme as of late: "I don't like the argument or I'm already on side 'X' in this fight, so I'm going to setup a straw-man to attack so I can avoid engaging the core premise of the article."

Her post isn't about keeping a private repo or being selfish. It's about "I am not your therapist or punching bag, nor is it my job to educate you, so why would I waste my time submitting my patch and dealing with a toxic community? What am I supposed to gain from that interaction, other than being insulted, belittled, and having my patches ignored?"

She is hardly the only person who stays far away from contributing to the Linux kernel (and other projects) thanks to certain nasty and emotional segments of "community". Those people don't show up in stats. No one knows they exist. The project just has a reputation for being full of assholes, so many really talented people choose to stay away (or strictly limit their involvement). This can become a self-reinforcing cycle where only assholes can be heard, resulting in design-by-asshole rather than design based on technical merit. Assholes (by virtue of being assholes) usually immediately dismiss this by claiming anyone making such complaints is technically inferior (or is intrinsically unsuited to contributing because of their age, gender, or other attribute).

I'll also point out that acting out like this is purely emotional knee-jerk behavior - the exact opposite of merit or technical arguments. Linus is perfectly capable of criticizing patches on technical merits without calling people morons in the process. In the past he has chosen to lash out emotionally for one reason or another. Perhaps he had a bad day. Perhaps he just enjoyed insulting other people. Perhaps he thought he was better than them and wanted to show off how superior he was. None of us can really know the underlying reason, but at the end of the day it hardly matters.

I really want to stress my last point: lots of people (including here on HN) are trying to make a self-evidently Orwellian case that adopting a CoC and setting community standards is somehow trading technical merit for soothing people's feelings... in defense of another contributor's ability to lash out emotionally. One has to engage in some especially motivated reasoning to make such prima-facia false claims.

A code-of-conduct basically boils down to "don't attack people personally and don't belittle, harass or intimidate other contributors". Or perhaps in simpler terms: "act like a professional".

Being professional means giving direct and honest feedback. Lying to avoid hurt feelings is the opposite of professional!

That's all well and good. But none of it explains why the author says the current changes taking place in the Linux project reinforce her decision not to participate in Linux.

How does a code of conduct and a hiatus for the guy who was cursing at people reinforce the decision to stay away? The only way that makes sense is if she weren't previously aware of any of the documented cases of Linus' abusive behavior, and that seems quite unlikely given she was already using her own "shadow ecosystem" years ago.

It also makes sense if you view codes of conduct as inherently toxic and a sign of a hostile community, and don't view Linus's cursing as particularly out of line. After all, Linus tended to chew people out for what they did or what they made, not what they were.

Not everyone views having a CoC as a good thing. If they did, this whole set of drama wouldn't be a thing in the first place...

I believe you are misinterpreting her post. I believe she's trying to communicate that the eruption of toxic behavior in response to the addition of a code of conduct reinforces her decision to stay away, not the code itself.

But none of it explains why the author says the current changes taking place in the Linux project reinforce her decision not to participate in Linux.

I can't speak for the author, so I can't explain that to you.

What I can tell you is that virtue signaling is vastly more common than people actually doing the right thing and nasty behavior frequently gets a great deal worse during periods when people are very visibly and openly trying to publicly address the problem in some manner.

My observation is that a common outcome is the metaphorical guillotines come out, people on their high horses behead all the bad guys, pronounce themselves to now be the good guys in charge and then business as usual follows.

So, for example, if the issue is sexism, terrible evil asshole sexist pigs take the fall to be promptly replaced by more men, not a mixed gender group of leaders, and you hear a lot of smack talk about more women being in the pipeline and someday this will result in gender parity while nothing really changes. But you should be nice to the new men in charge since they beheaded the bad guys and, clearly, in twenty years this will pay off for women.

If the issue is racism, well, clearly, racist white supremacist assholes get removed and are promptly replaced by new white people who will obviously treat people of color better -- someday, but probably not today, but you should believe they are the good guys. After all, they were so kind as to behead your enemies.

Etc.

If you are part of an "oppressed" group, you eventually get burned out on watching all the white guys fight over which white guys are less evil while no one actually does much of anything to genuinely include women, people of color, etc. And you don't really care to get in the middle of this mess knowing that none of these people actually has your best interest at heart and every last one of them will be happy to trample you underfoot in service of convincing virtue signaling.

Some of the most vicious fights are the ones about how to be respectful and well-mannered. Those frequently get ugly real, real fast and only go down hill from there.

> What I can tell you is that virtue signaling is vastly more common than people actually doing the right thing

You absolutely nailed it right here IMO.

Codes of conduct nowadays I feel are hijacked and reshaped into the vendetta persecutions you described.

Could Linus be nicer? Everybody keeps talking about that. I almost never see anyone assume that he tried being nicer but the only way he could get through to people was to draw their attention with being rude.

From what I gather, Linus is sincere and making a good faith effort. I think that's a better signal than writing a Code of Conduct. CoCs strike me as virtue signaling more often than not.

Hopefully, Linus will figure out a better path forward and start setting a better example. If he does that, I think that will make more of a difference than a CoC.

>How does a code of conduct and a hiatus for the guy who was cursing at people reinforce the decision to stay away? The only way that makes sense is if she weren't previously aware of any of the documented cases of Linus' abusive behavior, and that seems quite unlikely given she was already using her own "shadow ecosystem" years ago.

I did not read it that way. I read it more of calling out both sides as being toxic. And I do not think she was speaking specifically about Linux, but the whole dialogue these days about codes of conduct. She's indicting both the pro and anti crowds.

But in reality, all of us (including me) are projecting. She simply doesn't spell out what she's talking about.

> What am I supposed to gain from that interaction,

You do gain from the recognition though. Your code can steer the project's future and set new standards for example. It gives you active influence, which is power, and recognition as a bonus course. That might explain why a lot of people do put up with shit.

If your goal is just to get your job done and call it a day, you probably don't care about that kind of recognition.

A lot of people seem to think that having a large "open source resume" is a large component of success in getting software jobs, but that really isn't the case.

> get your job done and call it a day, you probably don't care about that kind of recognition

Then i don't get what the article is about. "I don't care for what i don't want" is a passive aggressive drivel.

> why would I waste my time submitting my patch and dealing with a toxic community?

when I could be wasting that time writing blog posts for venting resentment towards communities I don't want to be a part of in the first place?

There are plenty of projects whose communities don't gel with me. The solution is not to participate, not poo-poo them online, explaining how everything would be better if they just did it your way.

>This can become a self-reinforcing cycle where only assholes can be heard, resulting in design-by-asshole rather than design based on technical merit. Assholes

Why are you labeling everyone who doesn't want to deal with you on your specific terms?

> "don't attack people personally and don't belittle, harass or intimidate other contributors". Or perhaps in simpler terms: "act like a professional".

Those are not "simpler terms". One is a basic guideline, the other sounds like "Everybody should act like the corporate environment I'm used to working in".

>when I could be wasting that time writing blog posts for venting resentment towards communities I don't want to be a part of in the first place?

>There are plenty of projects whose communities don't gel with me. The solution is not to participate, not poo-poo them online, explaining how everything would be better if they just did it your way.

I honestly don't see how your posting this comment on HN is any different from her posting it on her blog.

> Those people don't show up in stats. No one knows they exist.

I am surprised by the thought that I might be one of those people. On paper, I seem like exactly the sort of person who ought to feel confident getting involved in Linux kernel development. I have decades of programming experience, I've been using Linux since the '90s, and I've spent most of my career building system software and developer tools. I've written drivers, filesystems, memory managers, embedded RTOS kernels, compilers, linkers, debuggers, VMs, runtime libraries, you name it. I've grepped through the Linux kernel source plenty of times. I am a thoroughgoing free software advocate and I've been GPLing all my personal projects for many years; in fact I am currently fortunate enough to be making my living developing free software.

And yet - it has never once occurred to me that I should get involved in the Linux kernel project. A friend actually suggested it last week, and my reaction was an instant, wordless sense of deflation - uffff, wow, "no way." Why? I didn't really investigate the feeling at the time, but it occurs to me now that I simply don't want to deal with a lot of hostile, critical "are you good enough" attitude, and that's what I expect I would get if I went and bothered those people.

Who knows what might have happened in an alternate universe where the kernel community were more welcoming; perhaps there would have been other reasons not to participate - but it's easy for me to believe that you're right, and there are lots of people who might have something to offer who are just quietly getting on with their lives and not even considering it.

I help keep at least one fork due to the upstream community being toxic. It's expensive, but what can you do?

A small and healthy community doesn't even need a code of conduct, but in the long run any large community needs by-laws and governance, and that includes rules for punishing toxic participants.

It seems amazing to me that people use toxic to mean "A tiny minority of anonymous people on a world accessable network of people may say mean things"

The world is full of at least 10% of people that are just stupid and awful. We should work to keep taking out the trash but we shouldn't turn away from the entire community.

If you choose not to share your own work because someone might say mean things I'm disappointed but if you keep private forks of public open source software I feel like your cheating the system that benefits you.

Why do you accept that people being mean to you is a price you must be willing to pay to participate? (Aside, toxic can be much much worse that just "being mean", but I'll engage with your definition here for the sake of discussion.)

I mean that some portion of the population is between disagreeable and despicable. Good communities ban the despicable but no matter where you draw the line some people will inevitably be negative enough to be a drag without stepping over the line to the point of being banned.

> It seems amazing to me that people use toxic to mean "A tiny minority of anonymous people on a world accessable network of people may say mean things"

If that tiny minority are in charge of or prominent in projects you're thinking about contributing to, then that's all that really matters, no?

How many successful projects are run by people that fit that description?

at least some of the toxicity in a community around an open source project is due to the pressure the participants feel in maintaining both their own professional reputation and the viability of the project, and there are positive ways to engage with the core committers that will create goodwill all around.

I hope people consider the potential of playing the long game when engaging with a community. Yes there are assholes in the world but they frequently move on to other pursuits, or just die, and after they are gone it's just amazing how excited people are to get things done.

And what if I value my time enough so as not to want to waste a minute of my life and wait "to play the long game"?

^ I believe that's the premise of the article.

This is why I always try to accept people's first contributions, even if it means reworking them to fit (I usually just do it if it's trivial, or give guidance and offer to do it if not).

I have generally had really great responses when I've sent drive-by tweaks to other FOSS projects, so I feel obliged to pay that forward to others.

Well that sucks.

I mean she is WELCOME to keep her contributions to private repos shared only among trusted friends if that's how she wants to work. But it's not for me. I want the work that I do to be shared as widely as possible. (I would share more widely if my employer permitted it.) That is why I choose permissive licenses, and make an effort to contribute patches back to the original source.

Yes, sometimes the communities are toxic. When I see that I speak up. Yes, sometimes my code contributions are used by people I don't much like or used for purposes I don't support. But far MORE often they are used by people I don't know, who I would certainly find to be perfectly nice folks if I ever DID meet them, but individual connections don't scale.

So Rachel is welcome to her insular community -- but I'm going to stick to the open one. I'd rather fix the flaws it has than hope to get a better one by foregoing the openness.

How long did it take Linus to realize his behavior was toxic? How many times was he told?

That's a lot of work to fix a project for almost no benefit to yourself.

Life is too short to deal with [people who aren't nice].

> I'm here to remind everyone of that post, and to point out that I'm not the only one doing this. There could be an entire "shadow ecosystem" of invite-only source repos being shared among friends who are responsible for those they invite, including possibly having whole "trees" pruned if they turn out to be troublesome.

This has crossed my mind before, I think it might be the only way to actually meaningfully stop rapid expansion/dilution of culture, which I think is roughly equivalent to what people mean when they say things get "toxic" or the community worsens (it's a bit of a stretch but you can rephrase toxic behavior as behavior that is not regarded as productive/acceptable by the original or some other culture).

Does anyone have any examples like this? An invite-only network that penalizes bad actors by revoking their membership along with everyone else they've invited?

Usage of the word "toxic" is quickly becoming a pet peeve of mine. I see it used all over the place recently to describe groups of people who, while they may exhibit some unfortunate traits, will not actually cause you to get sick or die. More often than not calling people toxic feels more like a way to write off people with whom you disagree or who you simply dislike.

This isn't to say that people in e.g. the open source software community don't behave badly. They absolutely do behave badly. But rather than just labeling someone toxic and assuming that everyone agrees and shares your definition of "toxic" - I feel that everyone's interests would be better served by actually describing 1) what exactly the problematic behavior is, 2) why it is bad, and 3) how to behave better.

TL;DR I find usage of the word "toxic" to be toxic. :)

I have the same feeling. "Toxic" is the new "problematic".

Or maybe you simply disagree with the author of the article and are seeking a way to undermine her opinion and overwrite it with... your opinion? :)

That's how your comment came across to me.

I did not offer any opinion other than I don't like using the word toxic to describe people. But since you bring it up, my opinion on the article is that the author is in no way obligated to contribute code to open source communities that she doesn't like dealing with. In other words, I agree with her. I'll even go a step further and say that I support codes of conduct for online communities if they encourage civil discourse and encourage more people to participate.

As for my motivations - my comment was actually more inspired by the comments here than the original article (61 occurrences of the word toxic at the time I write this). Are you now going to suggest that my intent is to undermine everyone who used the word toxic here and replace their opinions with my own? Or are you willing to accept my plea to stop referring to people as toxic at face value?

Neither.

I am more curious why do you dislike the word "toxic" being used to describe people?

Because it is imprecise and dismissive.

Says you. Let's recognize the undeniable fact that it's just your opinion. Same as the people using the word toxic saying it's deserved (your opponents) -- that's an opinion as well. If you are open to discuss your definition then a talk might happen. If not, everybody is stuck in their own confirmation bias.

¯\_(ツ)_/¯

I see little value in this post. She simply proclaims how "screwed" up HN, Linux, and other communities are, then uses an irrelevant story / anecdote to explain her lack of public participation in open source software. This could have been wrapped up in a tweet along the lines of: "These communities are toxic and screwed up, as I suspected! This reinforces my decision to stay out."

And what value does your comment have? You basically rephrase her article.

When shit started hitting the fan with the Linux CoC, my boss indicated that it was a shame that the CoC was being used as a tool for political revenge.

My response was to wonder why there were so many grudges? The CoC is for certain acting like gasoline on a fire, but I don’t believe it was the spark.

Glad I never really bothered to try interacting with that community in the first place.

> There could be an entire "shadow ecosystem" of invite-only source repos being shared among friends who are responsible for those they invite, including possibly having whole "trees" pruned if they turn out to be troublesome.

That could certainly be evidence that FLOSS projects need to do a better job of mentoring newcomers, and of combating abusive and anti-social behavior on their lists and issue trackers. That people are squirreled away on "shadow ecosystems" in sizable numbers would be a sign that FLOSS projects are failing at those tasks.

But it is not evidence that the artifacts these shadow ecosystems are producing have much value. If there are indeed a sizable number of participants there would be an example of a fork that releases binaries/tarballs of significantly higher quality than the original project.

Does anyone have such an example?

* tarball/binary available for fork

* fork is significantly improved over the original project

* FLOSS dev community for fork is invite only

No, there's no reason to do it in private. If you look around there are plenty of people who publicly fork code bases and work together independently of the original project with no drama. It could be they just want to go in a different direction, or to play, or didn't like the original group etc. They own their repo(s), get to decide who's invited in and if they even have a forum/mailing list/whatever. Been that way for decades.

That's not to say there aren't very public forks of important projects: they happen all the time. (just a few: Emacs/XEmacs, GCC/EGCS, FFmpeg/Libav, Cyanogenmod/LineageOS) If those who did the fork are right, the new project tends to supersede the original. And when there's a fork because one or more of the controlling personalities is an asshole, it tends to be public, noisy and messy. Note: the Linus/lkml thing barely moves the needle on this scale. (i.e. it's public, but there really hasn't been a lot of noise or mess to date.) Also, Linus is a complete gentleman compared to some of the situations I've read about.

There is a reason to do it in private: So you don't have to deal with the general public and the questions they might ask.

There's no requirement that projects listen to feedback or provide support, though the most successful ones generally do. There are many projects that simply ignore user and developer feedback. That's often a reason people fork.

I could name some arguable candidates: XFree86/x.org, mplayer/mplayer2/mpv, and xchat/HexChat. In many cases the catalyst was some kind of licensing disagreement, but the reason people were drawn to the fork was the dev culture of the original project. What they have in common is the original project tends to (but does not always) wither and die, at which point the quiet fork becomes the main focus.

But to be clear, this is the normal, daily-basis operation in the name of distro packaging, too. Some distros (Slackware, e.g.) try to hew as close to upstream as possible, but others (Red Hat and Debian, e.g.) significantly modify the upstream code, and development of this private not-a-fork-just-a-set-of-massive-patches is absolutely invite-only. There are weird rituals around not calling a given distro's effective forking "a fork," but in essence that's exactly what it is. "We can't get this patch accepted upstream," they'll say, and then the fork is live. It leads to heated and sometimes inimical clashes between the upstream dev and the packaging entity (c.f. xscreensaver, firefox/iceweasel, etc).

The only difference between some of these "packaging efforts" and the article's "shadow ecosystem" is how many users they have, really.

> I could name some arguable candidates: XFree86/x.org, mplayer/mplayer2/mpv, and xchat/HexChat.

Sorry, I left out the bullet about development being done in a private, invite-only group. That's what I'm curious about, and I don't think there are any examples of that.

The linked article from 2013 is worth a read, too: http://rachelbythebay.com/w/2013/06/03/bugs/

If your ego is so fragile, than good, keep the code to yourself. Some people might be a bit too sharp, but when you get the 100th "bug fix" that includes unsafe code, extra dependencies and the effort put into auditing is 10x the effort to write it on your own, then yes, you'll get a rude response. You might have been meaning well, but others haven't. Your contribution won't be missed.

You are making an unvalidated assumption about her code quality based off of her desire to not participate. This sort unsubstantiated opinion, stated with an implied assumption of fact, is exactly the sort off thing that contributes to toxicity in a community.

> than good

*then

> What's funny is that my friends in the know tell me this is how private warez torrent sites work: you invite someone, and now you're responsible for their behavior. If they mess up, you deal with them, or you might be out, too.

lobste.rs works like this too. Tree structures of invites are a great way to prune further up the tree when undesired behavior happens.

I believe only once has someone who invited a problem user been banned. That inviter contributed a feature to disable invitations and was unbanned. But I think the possibility also has a deterring effect that prompts people to exercise care.

(Context: I'm the lobsters admin.)

I just don't understand how you validate and inspect your own ideas without participating in some broader Internet-based community. Be these technical ideas or social ideas, "not participating" is akin to "not examining".

The toxicity is just a byproduct, and you try to rise above it, but not participating sounds to me to be a dulling activity, not a sharpening one.

> ...the Central Intelligence Agency has used it for hacking, Google for crawling webpages, Pixar for producing movies and Spotify for recommending songs.

This statement gives articles and journalism like this a bad name. It's as misleading as you can get as it gives the impression Python would be the main language for these jobs and nothing could be further from the truth. I'm sure it participates in some way, directly or indirectly, but doesn't perform the main function.

And then we get this:

> Fortran, Lisp and Ada were all highly popular in the 1980s and 1990s

Which may be true for Fortran and maybe even Ada in defense or government but Lisp? I don't think so.

[flagged]

..and evidently, the open source community and its products could be even more impressive if it was better at responding to criticism. You are bad at this - and that’s a problem.

I'm just stating my opinion; that's essentially what this site is for. I wasn't criticized and therefore was not responding to criticism. It is true that I have little time for codes of conduct etc.

"It is true that I have little time for codes of conduct etc"

That's the worst excuse for plastering the internet with low quality 'opinions' like the one above.

No, the problem is that you don’t like my opinion, not that it is low quality. And that’s absolutely fine. I made two serious points in 3 sentences; the remainder was a criticism of the post. My points were about what a fascinating and positive phenomenon open source is. If you’d like I can explain them to you again.

She seems to be implying that she has one hell of a fix for the Linux kernel, but she’s not sharing it because Linus is mean to contributors. I can’t fathom how awesome this fix must be for her to write about it twice, and she doesn’t go into any detail.

This is the answer to the Fermi Paradox.

It comes across as elitist to keep code fixes in your own private repository to 'punish' those you don't agree with. The whole point is freedom and sharing code that transcends arbitrary human defined barriers.

What if linux was kept in a private repository to punish those he didn't agree with?

I doubt the motive is to punish, but is instead to avoid the unwanted drama of dealing with a "toxic" community.

I think the point is, whenever I fork a piece of code, fix something, and push the fix back upstream, there’s a whole set of things I apparently didn’t do to the maintainers liking.

I don’t want to deal with that...

My favorite is when they demand you write tests for a three-line change to code that has no tests.

In their defence, deciding you're going to require new tests for all new additions in a pretty effective way to get out of the 'there are no tests' situation. I recently heard something along the lines of "don't bother adding new tests, this project barely has any tests anyway" about a project where I have been trying to increase test coverage whenever I have to make a change in recent months. With that attitude it's no surprise the project barely had any tests...

Naturally it is not a reasonable request when there is no existing testing infrastructure yet.

> The whole point is freedom and sharing code that transcends arbitrary human defined barriers.

Whose point is this?

It is not the point of the free software movement as seen by the FSF, which calls the APSL 1.x non-free because it requires you to publish changes https://www.gnu.org/philosophy/historical-apsl.html , nor of the (largely similar) free software movement as seen by Debian, which has a "dissident test" that explicitly requires you have the option of keeping changes among your trusted friends (assuming you trust them not to republish, of course) https://people.debian.org/~bap/dfsg-faq.html . It is certainly not the point of the open-source movement nor the Linux Foundation, both of which are firmly supportive of companies making internal improvements and not publishing any of them.

If it is your point, I urge you to reconsider a position that focuses on individuals not publishing code instead of corporations not publishing code.

Except that sometimes "those you don't agree with" don't really care about the repo, they just want to push their political agenda.

Other times your conscience might feel cleaner just knowing that you aren't part of a group that does things you don't like, for example: discrimination based on race. Some big projects have partnered with programs like Outreachy, that decide who to help based on the ethnicity, gender, and sexuality of the applicant.

Would you feel comfortable working for a project that openly partners with the KKK to foster adoption of open source in the white supremacist community?. This is an extreme example, but I'm using it for the sake of the argument: Most of us wouldn't want to work for such a project, even though some people might be more malleable than others.

The motive isn't to "punish." It's much more basic than that: I just don't want to deal with the toxicity of the community, and the best way to accomplish that is to not engage. Once I engage, I will probably need to spend mental cycles dealing with it.

> The whole point is freedom and sharing code that transcends arbitrary human defined barriers.

I think this is both an admirable view but also a naive one. Code is built, maintained, modified, sold, bought, and used by humans, so at the end of the day code is a human endeavor, and that means you will never escape having to deal with other humans in the process of writing code. You might have more or less pleasant interactions, but (at least before the singularity) code doesn't exist outside the context of human interactions.

I've personally constantly sought ways to spend more time coding and less time dealing with people, but my efforts have only reinforced the bittersweet message that the code I write is both more effective and more useful when I engage with people more. So at some point I just embraced the human element of the craft. But that comes with managing my emotional and social energy, which also means avoiding communities I don't need to be a part of.

>> What if linux was kept in a private repository to punish those he didn't agree with?

What a wonderful world that would be.

It's not elitist, it's just not wanting to deal with assholes. I think that is pretty understandable. That doesn't punish them it just results in not dealing with them.

This is my take. I think this goes on at all levels. I know I definitely take some roundabout paths at work from time to time to avoid people with big egos because it's just a roadblock and a time suck. Ideally, we could work together and be more efficient, but some people just don't want to play nice or fair and there are only so many hours in the day.

>It comes across as elitist to keep code fixes in your own private repository to 'punish' those you don't agree with.

Throughout my life I seem to have endless arguments about this. Many people seem to have a binary view of the world (positive/negative), and many others (like me) tend to have more of a ternary view (positive/neutral/negative).

No one is punishing anyone. Not helping is neutral. It is not a punishment.

If I dislike what you do and decide to withdraw support I had been providing, I am not punishing you. I am merely disengaging with you. My position is the same as that of someone who never helped you and continues not to help you.

And of course, as another person has pointed out. When someone gives you something with the explicit permission that you do not have to give back, it is petty to complain when they don't give back.

If freedom to share code doesn't include freedom to not share code, it's not very free, is it?

The meta-point is that everybody's wringing their hands over "oh no, I can't say things I want to say and also contribute to Linux", and her point is that this is not new, lots of people have experienced this for a long time.

Reply on news.ycombinator.com