3 ms·
> 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
by curtisblaine 9y ago
> 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.
- zimpenfish 9y ago> 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.
- curtisblaine 9y ago> 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 :)