The Truth About Rod Vagg(medium.com)
medium.com
The Truth About Rod Vagg
https://medium.com/@rvagg/the-truth-about-rod-vagg-f063f6a53557
11 comments
Does Node need to be inclusive anyways? We're taking for granted that inclusivity is good for a technical project just because it feels "right", and because they told us that it is right. But does it help or does it harm? Does it really help to take people onboard who are less technically and more politically oriented? Does it really help to hold down criticism to not offend anyone, risking a situations where points are never made and emphasis is never placed?
We have an example of a successful and long lived open source project - Linux - which is famous for being exclusive and "snarky". Yet, it has taken over the server and embedded world. Would it have been the same if it had a committee kicking out and reprimanding people for not adhering to a Code of Conduct where everyone has to be kind and mindful and avoid criticizing the way things are done? Because people, when they're working, will eventually be not nice to each other. They will write snarky comments and they will be rough and they will always prefer qualities related to the work they're doing (technical / architectural proficiency) to qualities related to the social and politics sphere. Technical projects are technical, deal with it.
> Yet, [Linux] has taken over the server and embedded world
I would posit that this is nothing to do with Linus being a dickbag to people and everything to do with a) they focused on "getting shit working" over "purity", b) were (as best I can tell) much more open to contributions and partnerships than the BSDs, and c) expanded rapidly to cover just about every little niche there was.
Any of the BSDs (or other OSs, I guess) could have had the same viral trajectory if they'd focused on the same things instead of their ideological purity, code stability, et al.
> But does it help or does it harm?
I believe there are several studies that show increasing diversity can improve technical projects because this reduces "situations where points are never made".
> Does it really help to take people onboard who are less technically and more politically oriented?
That depends - does your project exist in a world that contains politics? Is it meant to solve problems for human beings? Both of those benefit from diversity because, and this will shock you, a very small percentage of the world is comprised of privileged white dudes.
I would posit that this is nothing to do with Linus being a dickbag to people and everything to do with a) they focused on "getting shit working" over "purity", b) were (as best I can tell) much more open to contributions and partnerships than the BSDs, and c) expanded rapidly to cover just about every little niche there was.
Any of the BSDs (or other OSs, I guess) could have had the same viral trajectory if they'd focused on the same things instead of their ideological purity, code stability, et al.
> But does it help or does it harm?
I believe there are several studies that show increasing diversity can improve technical projects because this reduces "situations where points are never made".
> Does it really help to take people onboard who are less technically and more politically oriented?
That depends - does your project exist in a world that contains politics? Is it meant to solve problems for human beings? Both of those benefit from diversity because, and this will shock you, a very small percentage of the world is comprised of privileged white dudes.
> a) they focused on "getting shit working" over "purity"
Also, they focused on "getting shit working" over "making sure to not offend anyone".
> b) were (as best I can tell) much more open to contributions and partnerships than the BSDs
And they managed to be more "open to contributions" despite having a "dickbag" as benevolent dictator and an "hostile environment" (as you probably would put it) to beginner devs. And not having a CoC for 20 years. So maybe it's not terribly essential to be forcibly inclusive in order to be open to contributions?
> c) expanded rapidly to cover just about every little niche there was.
Again, they managed that being a non-diverse environment, by most meters of (modern) judgement. So maybe it's not so essential to be inclusive when you manage to cover all niches in no time? It was so exclusive that managed to cover everyone's needs? How's that even possible?
> I believe there are several studies that show increasing diversity can improve technical projects because this reduces "situations where points are never made".
Indeed, but you have to consider that being overly-inclusive opens the doors to bike-shedding and, for example, wanting to exclude perfectly capable programmers just because they communicate aggressively. I believe that more points are made (and I don't find difficult to believe studies prove that), but are highly capable people valued correctly in such an environment? Is it an overall gain, in all aspects?
> That depends - does your project exist in a world that contains politics?
A lot of stuff exist in a world that contains politics, but doesn't have to be political. Is medicine political? Obviously yes. Are you "including" surgeons based on their right to be there? No.
But I concede that there should be an overall body with actual powers controlling that a series of Code of Conducts, known and approved by anyone (by representation) are respected. And that this body should be periodically elected democratically. Oh, wait... we have one - it's called "Government" and the CoC are called "laws".
Having that, do we really need to tell people on Github to avoid telling others to "stop saying bullshit" because it's offensive? Do we need to make kindness mandatory? Do we need to favour inclusion over technical prowess? Sounds like the recipe for a disaster.
Also, they focused on "getting shit working" over "making sure to not offend anyone".
> b) were (as best I can tell) much more open to contributions and partnerships than the BSDs
And they managed to be more "open to contributions" despite having a "dickbag" as benevolent dictator and an "hostile environment" (as you probably would put it) to beginner devs. And not having a CoC for 20 years. So maybe it's not terribly essential to be forcibly inclusive in order to be open to contributions?
> c) expanded rapidly to cover just about every little niche there was.
Again, they managed that being a non-diverse environment, by most meters of (modern) judgement. So maybe it's not so essential to be inclusive when you manage to cover all niches in no time? It was so exclusive that managed to cover everyone's needs? How's that even possible?
> I believe there are several studies that show increasing diversity can improve technical projects because this reduces "situations where points are never made".
Indeed, but you have to consider that being overly-inclusive opens the doors to bike-shedding and, for example, wanting to exclude perfectly capable programmers just because they communicate aggressively. I believe that more points are made (and I don't find difficult to believe studies prove that), but are highly capable people valued correctly in such an environment? Is it an overall gain, in all aspects?
> That depends - does your project exist in a world that contains politics?
A lot of stuff exist in a world that contains politics, but doesn't have to be political. Is medicine political? Obviously yes. Are you "including" surgeons based on their right to be there? No.
But I concede that there should be an overall body with actual powers controlling that a series of Code of Conducts, known and approved by anyone (by representation) are respected. And that this body should be periodically elected democratically. Oh, wait... we have one - it's called "Government" and the CoC are called "laws".
Having that, do we really need to tell people on Github to avoid telling others to "stop saying bullshit" because it's offensive? Do we need to make kindness mandatory? Do we need to favour inclusion over technical prowess? Sounds like the recipe for a disaster.
> more "open to contributions"
Yes - and Linus wasn't involved in most of them (since he delegated subtrees) which makes your "despite having a dickbag in charge" completely irrelevant.
> Maybe it's not terribly essential to be forcibly inclusive in order to be open to contributions
But you'll note I specifically said "more open [...] than the BSDs" - it wasn't an absolute. The Linux kernel is very much not open to contributions per se -but- compared with the *BSDs etc. it is a paragon of welcome.
> exclude perfectly capable programmers just because they communicate aggressively
Being able to communicate effectively - and that generally excludes "aggressively" - is an important part of being a capable (and better) programmer.
> Are you "including" surgeons based on their right to be there? No.
What?
> you have to consider that being overly-inclusive opens the doors to bike-shedding
Ironic that you call it "bike-shedding" when that was coined from a project that wasn't "overly-inclusive". Almost as if your link between the two is fanciful nonsense.
It's clear your only argument is "I don't like inclusivity" and that's fine - you're on the wrong side of history and doomed to fail.
Yes - and Linus wasn't involved in most of them (since he delegated subtrees) which makes your "despite having a dickbag in charge" completely irrelevant.
> Maybe it's not terribly essential to be forcibly inclusive in order to be open to contributions
But you'll note I specifically said "more open [...] than the BSDs" - it wasn't an absolute. The Linux kernel is very much not open to contributions per se -but- compared with the *BSDs etc. it is a paragon of welcome.
> exclude perfectly capable programmers just because they communicate aggressively
Being able to communicate effectively - and that generally excludes "aggressively" - is an important part of being a capable (and better) programmer.
> Are you "including" surgeons based on their right to be there? No.
What?
> you have to consider that being overly-inclusive opens the doors to bike-shedding
Ironic that you call it "bike-shedding" when that was coined from a project that wasn't "overly-inclusive". Almost as if your link between the two is fanciful nonsense.
It's clear your only argument is "I don't like inclusivity" and that's fine - you're on the wrong side of history and doomed to fail.
> which makes your "despite having a dickbag in charge" completely irrelevant
So not having a CoC and having a dickbag in charge is OK? Cool! QED!
> Being able to communicate effectively - and that generally excludes "aggressively"
It doesn't. Aggressivity doesn't exclude efficiency. Aggressivity is a human interaction with a purpose. If used correctly it can express emphasis with amazing efficiency.
> Ironic that you call it "bike-shedding" when that was coined from a project that wasn't "overly-inclusive".
Bike-shedding is a reality in non-inclusive project like FreeBSD. Now imagine in "inclusive" projects where every word has to be carefully weighted in order to not offend anyone. People fighting not only over the color of the bike shed, but also on the political undertones of supporting bikes, on the percentage of male and/or white bike riders, all while constantly accusing each other of being threatening. Exponential bullshitting and no work done :)
> It's clear your only argument is "I don't like inclusivity"
Actually, I like it. But, in a technical project, it should always come after the actual "getting shit done" part.
> you're on the wrong side of history and doomed to fail.
Am I? I was there in the 90s, when riot grrrls were all the shit and PC peaked. I wasn't terribly impressed back then and I'm not impressed now :)
So not having a CoC and having a dickbag in charge is OK? Cool! QED!
> Being able to communicate effectively - and that generally excludes "aggressively"
It doesn't. Aggressivity doesn't exclude efficiency. Aggressivity is a human interaction with a purpose. If used correctly it can express emphasis with amazing efficiency.
> Ironic that you call it "bike-shedding" when that was coined from a project that wasn't "overly-inclusive".
Bike-shedding is a reality in non-inclusive project like FreeBSD. Now imagine in "inclusive" projects where every word has to be carefully weighted in order to not offend anyone. People fighting not only over the color of the bike shed, but also on the political undertones of supporting bikes, on the percentage of male and/or white bike riders, all while constantly accusing each other of being threatening. Exponential bullshitting and no work done :)
> It's clear your only argument is "I don't like inclusivity"
Actually, I like it. But, in a technical project, it should always come after the actual "getting shit done" part.
> you're on the wrong side of history and doomed to fail.
Am I? I was there in the 90s, when riot grrrls were all the shit and PC peaked. I wasn't terribly impressed back then and I'm not impressed now :)
CoCs are good in that they allow someone to say 'hey, we told you no booth babes / sexual slides / persistent unwanted sexual attention' - it takes some courage for a woman to walk into a room full of dudes and (assuming she's straight) it's not nice to have something which assumes you're interested in women (both babes / sexual slides), or that makes you feel like she might get sexually assaulted (or just takes away from the fact that she's there for tech, not men).
CoCs are bad in that they're often used as ideological purges - for joking about 'dongles' or, in this case, retweeting an article http://quillette.com/2017/07/18/neurodiversity-case-free-spe... that was on the front page of HN a few days ago. Women aren't children and won't be harmed by seeing something they may potentially disagree with, nor do they all hold the same opinions.
CoCs are bad in that they're often used as ideological purges - for joking about 'dongles' or, in this case, retweeting an article http://quillette.com/2017/07/18/neurodiversity-case-free-spe... that was on the front page of HN a few days ago. Women aren't children and won't be harmed by seeing something they may potentially disagree with, nor do they all hold the same opinions.
Half the case here has been assisted by the removal of details for the thread. Unless you read the archived version with working links (available online but also reproduced in this article) you'd have no idea what Rod actually tweeted.
Linking to a Quilette article and screen capping abuse you receive doesn't mean you're a 'known hostile' and all the various hyperbole that's been around in the last couple of days.
Linking to a Quilette article and screen capping abuse you receive doesn't mean you're a 'known hostile' and all the various hyperbole that's been around in the last couple of days.
(after reading through https://github.com/nodejs/board/issues/58 and other issues related to this situation)
The Github comment revision needs to stop. It makes it impossible for people who were not involved in the original conversation to understand what actually happened. Without a full archive of all revisions, you cannot even judge if the edits were made in good faith or if the current text represents the author's original intent. It casts doubt on everything.
The whole mess is even worse on long threads like the ones linked to. Editing a comment that other users responded to can make the responding comments look silly or stupid, or completely change the meaning of their response.
This is mostly a process thing but Github also needs to improve how edits are handled.
The Github comment revision needs to stop. It makes it impossible for people who were not involved in the original conversation to understand what actually happened. Without a full archive of all revisions, you cannot even judge if the edits were made in good faith or if the current text represents the author's original intent. It casts doubt on everything.
The whole mess is even worse on long threads like the ones linked to. Editing a comment that other users responded to can make the responding comments look silly or stupid, or completely change the meaning of their response.
This is mostly a process thing but Github also needs to improve how edits are handled.
This story is everywhere, i don't feel you are drumming up support by this. The options of the responses seem negative to the ppl behind the fork
Is 'you' Rod, Max or the people behind the fork? Having trouble parsing your comment.
When a project focuses on other things unrelated to the core reason why they exist things like this happen.
To the outside world these issues seem unrelated to why they use the language.
Inclusivity seems more like creating documentation in different languages rather than kick someone out over a retweet with an acceptable message to the average node user.