What is hacker culture?

[mjg59]

Eric Raymond, author of The Cathedral and the Bazaar (an important work describing the effectiveness of open collaboration and development), recently wrote a piece calling for "Social Justice Warriors" to be ejected from the hacker community. The primary thrust of his argument is that by calling for a removal of the "cult of meritocracy", these SJWs are attacking the central aspect of hacker culture - that the quality of code is all that matters.

This argument is simply wrong.

Eric's been involved in software development for a long time. In that time he's seen a number of significant changes. We've gone from computers being the playthings of the privileged few to being nearly ubiquitous. We've moved from the internet being something you found in universities to something you carry around in your pocket. You can now own a computer whose CPU executes only free software from the moment you press the power button. And, as Eric wrote almost 20 years ago, we've identified that the "Bazaar" model of open collaborative development works better than the "Cathedral" model of closed centralised development.

These are huge shifts in how computers are used, how available they are, how important they are in people's lives, and, as a consequence, how we develop software. It's not a surprise that the rise of Linux and the victory of the bazaar model coincided with internet access becoming more widely available. As the potential pool of developers grew larger, development methods had to be altered. It was no longer possible to insist that somebody spend a significant period of time winning the trust of the core developers before being permitted to give feedback on code. Communities had to change in order to accept these offers of work, and the communities were better for that change.

The increasing ubiquity of computing has had another outcome. People are much more aware of the role of computing in their lives. They are more likely to understand how proprietary software can restrict them, how not having the freedom to share software can impair people's lives, how not being able to involve themselves in software development means software doesn't meet their needs. The largest triumph of free software has not been amongst people from a traditional software development background - it's been the fact that we've grown our communities to include people from a huge number of different walks of life. Free software has helped bring computing to under-served populations all over the world. It's aided circumvention of censorship. It's inspired people who would never have considered software development as something they could be involved in to develop entire careers in the field. We will not win because we are better developers. We will win because our software meets the needs of many more people, needs the proprietary software industry either can not or will not satisfy. We will win because our software is shaped not only by people who have a university degree and a six figure salary in San Francisco, but because our contributors include people whose native language is spoken by so few people that proprietary operating system vendors won't support it, people who live in a heavily censored regime and rely on free software for free communication, people who rely on free software because they can't otherwise afford the tools they would need to participate in development.

In other words, we will win because free software is accessible to more of society than proprietary software. And for that to be true, it must be possible for our communities to be accessible to anybody who can contribute, regardless of their background.

Up until this point, I don't think I've made any controversial claims. In fact, I suspect that Eric would agree. He would argue that because hacker culture defines itself through the quality of contributions, the background of the contributor is irrelevant. On the internet, nobody knows that you're contributing from a basement in an active warzone, or from a refuge shelter after escaping an abusive relationship, or with the aid of assistive technology. If you can write the code, you can participate.

Of course, this kind of viewpoint is overly naive. Humans are wonderful at noticing indications of "otherness". Eric even wrote about his struggle to stop having a viscerally negative reaction to people of a particular race. This happened within the past few years, so before then we can assume that he was less aware of the issue. If Eric received a patch from someone whose name indicated membership of this group, would there have been part of his subconscious that reacted negatively? Would he have rationalised this into a more critical analysis of the patch, increasing the probability of rejection? We don't know, and it's unlikely that Eric does either.

Hacker culture has long been concerned with good design, and a core concept of good design is that code should fail safe - ie, if something unexpected happens or an assumption turns out to be untrue, the desirable outcome is the one that does least harm. A command that fails to receive a filename as an argument shouldn't assume that it should modify all files. A network transfer that fails a checksum shouldn't be permitted to overwrite the existing data. An authentication server that receives an unexpected error shouldn't default to granting access. And a development process that may be subject to unconscious bias should have processes in place that make it less likely that said bias will result in the rejection of useful contributions.

When people criticise meritocracy, they're not criticising the concept of treating contributions based on their merit. They're criticising the idea that humans are sufficiently self-aware that they will be able to identify and reject every subconscious prejudice that will affect their treatment of others. It's not a criticism of a desirable goal, it's a criticism of a flawed implementation. There's evidence that organisations that claim to embody meritocratic principles are more likely to reward men than women even when everything else is equal. The "cult of meritocracy" isn't the belief that meritocracy is a good thing, it's the belief that a project founded on meritocracy will automatically be free of bias.

Projects like the Contributor Covenant that Eric finds so objectionable exist to help create processes that (at least partially) compensate for our flaws. Review of our processes to determine whether we're making poor social decisions is just as important as review of our code to determine whether we're making poor technical decisions. Just as the bazaar overtook the cathedral by making it easier for developers to be involved, inclusive communities will overtake "pure meritocracies" because, in the long run, these communities will produce better output - not just in terms of the quality of the code, but also in terms of the ability of the project to meet the needs of a wider range of people.

The fight between the cathedral and the bazaar came from people who were outside the cathedral. Those fighting against the assumption that meritocracies work may be outside what Eric considers to be hacker culture, but they're already part of our communities, already making contributions to our projects, already bringing free software to more people than ever before. This time it's Eric building a cathedral and decrying the decadent hordes in their bazaar, Eric who's failed to notice the shift in the culture that surrounds him. And, like those who continued building their cathedrals in the 90s, it's Eric who's now irrelevant to hacker culture.

(Edited to add: for two quite different perspectives on why Eric's wrong, see Tim's and Coraline's posts)

Comments

I still think Eric is right

[(Anonymous)]

I think arguments in linked articles and publicly available abstract shows, that main problem is, that too many non-technical people are now involved in "open source" (or thinks so).
Especially it shows in large organizations (e.g. corporations which started "doing open source") and their corporate politics of power and control, but it has nothing to do with postulates of open source.
In short, there is huge difference between "open source" in corporations (or any other large hierarchically structured groups), which come more dominant, and just collaborative open source projects which go more minor (not in absolute, but in relative numbers).

Re: I still think Eric is right

[mjg59]

The idea that open source is fundamentally about technical people is the biggest misconception here. It's not. It's about social change. It's about avoiding concentration of power among an elite. It's about empowering those whose voices would be ignored by proprietary vendors. It's about making it possible to meet the needs of those with different experiences to us. We can't do that without non-technical people.

Thanks for adding Tim and Coraline's posts

[aleph_one]

I am glad to see a breadth of responses to Eric. I think the basic idea that "the current system has bugs and meritocracy ignores them" is what will eventually win out (I hope), and multiple takes on that idea are important for working it out as a community.

Re: Thanks for adding Tim and Coraline's posts

[(Anonymous)]

This sounds like 'teach the controversy' bullshit from creationists. Meritocracy ensures that irrelevant human bullshit stays irrelevant, preventing it from consuming much resources or time.

[(Anonymous)]

Utter bullshit. Yeah, let's rant about "sexist language" instead fixing bugs, while Debian testing gets more and more unusable. Let's help bullies that already started bullying hackers, to bully into oblivion those who DO write code and fix bugs, at the same time creating "safe spaces" with play-do and shit for those who DON'T. Great.

[mjg59]

The more people involved, the more bugs we fix. Ignoring the impact sexist language has on diminishing our contributor pool is ignoring reality.

Nice post

[(Anonymous)]

Nice post, level headed, civil. I may or might not agree with it but there are some points clearly made and a positive discussion can go on from those.

I must state though that the "different perspectives" posts you linked aren't on par with yours: they fail to link to the original article (fear or letting the reader check the other side) and especially Tim's is full of vitriol without bringing much to the table (Coraline's one read like a consummate politician).

Re: Nice post

[(Anonymous)]

I can certainly understand people not wanting to link to ESR, ever. I'm impressed that Matthew managed to focus on this particular reason why ESR is wrong, as opposed to pointing out all the other ways he's a terrible person that don't directly relate to this.

I do find it amusing that even one of the ESR posts Matthew linked to shows in a nice, self-contained way just what kind of person he is.

[tcpip]

I seem to recall that one of the core items for hackers from Levy's Hackers: Heroes of the Computer Revolution (1984) was the following:

"Access to computers should be unlimited and total."

That seems to me to be a social justice argument.

But as you say there is explicit discrimination and implicit biases that prevent the objective of meritocracy, an issue which you may find a few pointers in my post from the discussion on Linux Australia.

Meritocracy is an evolving code of practice, and there are bug fixes and commit requests etc.

That's not quite how it works

[(Anonymous)]

The primary thrust of his argument is that by calling for a removal of the "cult of meritocracy", these SJWs are attacking the central aspect of hacker culture - that the quality of code is all that matters.

This is a misrepresentation of the anti-SJW argument. That is more properly stated as an argument that replacing strict meritocracy (i.e. with something that isn't) is a step downward in terms of technical quality, which is an unacceptable compromise. Furthermore, meritocracy isn't a "central aspect of hacker culture" -- good shit is, and meritocracy is its herald. This must be so because any non-meritocratic organization would substitute maximally capable maintainership with people who've got less proven capability, resulting in worse output.

The argument presented in the blog-post argues only against this misrepresentation, and not the proper argument. As such the blog's argument does not address meritocracy as perceived within the hacker culture, but a social-justice activist's misrepresentation thereof.

(but hey, maybe someone can find us a guy who unironically believes that Elon Musk is a proper rocket scientist because he's got some economic merit. not all people can get pork-rich in a couple of years, right? and this line of thought isn't at all Calvinist either, is it.)

Re: That's not quite how it works

[mjg59]

This must be so because any non-meritocratic organization would substitute maximally capable maintainership with people who've got less proven capability, resulting in worse output.

This is true only if an allegedly meritocratic organisation treats people purely according to their quality. They don't, so it isn't. Those asserting that functional strict meritocracies exist must argue that everybody involved in decision-making roles is free of any traits that would cause them to consider anything other than the quality of a contribution. This is an extraordinary claim, and requires extraordinary evidence that nobody has ever provided.

In the absence of this evidence there's no reason at all to believe that the existing leadership of any organisation is maximally capable, and no reason to believe that replacing existing leadership with those willing to take social factors into account would result in worse output.

[(Anonymous)]

If his article was so obviously wrong, why all you rushed to write so many notes about how he is wrong?

He's right. You don't like some project policy? Fork it, if you really have the balls some courage. Gather around those who cares about your way of thinking AND who able to do things, clone the project and set sails! All that time-wasters want to achieve their goals for the cost of time of others. Suck it.

[mjg59]

If his article was so obviously wrong, why all you rushed to write so many notes about how he is wrong?

If the SJWs are so obviously wrong, why did Eric rush to write about them in the first place?

You don't like some project policy? Fork it

You fork once it becomes clear that you can't achieve your aims within the existing project. If that's not clear, you continue trying to work with the existing project. Easy enough.

comment on post

[(Anonymous)]

Is this what the majority of the Fedora community believes? If so, I will certainly move from the community and to another not caught up in political correctness. The goal should be the best operating system/software possible. As long as the best OS/software is being provided, I don't care if all contributions are coming from just one race. It's irrelevant. As soon as 'inclusiveness' and fairness becomes more important than quality and ability, the project as far as I'm concerned is trash, and no longer worth participating in.

Re: comment on post

[pgordon.id.fedoraproject.org]

[...] As long as the best OS/software is being provided, I don't care if all contributions are coming from just one race. It's irrelevant.

I think you're taking this from the wrong perspective. It is absolutely relevant, and a fundamental necessity to the continued quality of the entire community that no one be excluded from contributing to it if they have the desire and capability to do so. Ability to contribute and quality of those contributions, however, require that no one be excluded from the opportunity to contribute. And that is the necessity of social justice within the community: to ensure that what we believe and want to be a meritocracy truly is. The pedantry of wording and codes of conduct (whether explicitly stated or not) serve to enable that true meritocracy by ensuring that we do not look down upon anyone just because they might be different in some way.

But the Contributor Covenant isn't fail-safe

[m50d.wordpress.com]

I can well imagine that there would be marginal PRs that ESR or anyone might accept or reject based on the identity of the contributor. But only the marginal ones. And in that case at least other reviewers can see the rejected PRs and judge their technical merits themselves; if someone is rejecting good PRs and approving bad ones, sooner or later the project will take action, even a project that sees itself as purely meritocratic.

How fail-safe is the Contributor Covenant? Remember we're talking about practice, not theory. When I've seen it implemented, if that means anything concrete it tends to mean giving an unaccountable, secret committee the authority to exclude project contributors on their say-so. That's not very fail-safe.

And while as far as I can see your concern is purely theoretical, as a ScalaZ contributor I have seen mine in practice. Someone introduced a project code of conduct, then claimed a contributor had violated it and banned him, first quoting some lines and claiming they obviously violated the CoC, then that he'd violated the CoC on a different occasion but refusing to provide any details, then equivocating over whether he'd violated the CoC at all but still refusing to discuss it.

Re: But the Contributor Covenant isn't fail-safe

[(Anonymous)]

Choosing not to do anything is a decision too. How fail-safe is the *lack* of a code of conduct?

...

[(Anonymous)]

Eric is right

Re: ...

[https://makabra.org/id/miroslaw]

Oh yes – just like when he predicted that Obama will lose, twice?

[(Anonymous)]

>exist to help create processes that (at least partially) compensate for our flaws.

So we are trying to fix subconscious prejudice with a system, where people in charge make decisions, certainly affected by their subconscious prejudice, to place people into positions specifically for their supposed subconscious prejudices (diversity), to counterbalance other peoples subconscious prejudices.

What a great idea!

[jewelfox]

No, actually, diversity initiatives are all about promoting inclusion based on easily observable qualities about people. And informed by the knowledge that some people are excluded, from free software and other environments, because of things that they ARE and not things that they DO.

An example of a successful initiative to increase diversity would be Outreachy, formerly the GNOME Outreach Program for Women.

Ignoring the fact that people are facing exclusion for reasons UNRELATED to the quality of their work is what gets us bullshit opinions like Eric's, which act as blockers to a major bug fix.

[jewelfox]

mjg59: Social justice is an important part of real meritocracy, because it's an attempt to patch the bug where we are so biased against other people that we don't value their contributions.

Teh ESR Squad: BUT IF WE LET WIMMINS IN THEIR CODE WILL SUCK

ALSO EVERYTHING OTHER THAN CODE, IS SUCK, AND THE PEOPLE WHO WORK ON IT SUCK

mjg59: ???

Consider the beam in thine own eye.

[(Anonymous)]

Everyone is biased, but not you. Anyone that disagrees is "Teh ESR Squad". Wonderful.

[(Anonymous)]

"Would he have rationalised this into a more critical analysis of the patch, increasing the probability of rejection?"

Isn't that a good thing? More vs. less critical analysis?

Shouldn't the argument therefore be we want ESR's analysis of the patch for everyone to be as critical as he would be for those he's most biased toward?

You will likely never get rid of bias. It's an evolutionary trait. A shortcut to not being omniscient. Having a collaborative, open system will result in minimization of problems resulting from any biases and as I point out above... it's not impossible that in these cases such a bias could actually lead to better end results.

There are also much simpler solutions to these kinds of "problems". If you believe people are biased due to metadata leaks which reveal personal attributes / identity... create anonymous identities. That's far easier and less insulting to contributors than calling them out as biased, claiming they aren't living up to their goals, or that the goals are fundamentally flawed, or trying to impose "diversity" when any benefits from diversity are natural and emergent.

[mjg59]

Shouldn't the argument therefore be we want ESR's analysis of the patch for everyone to be as critical as he would be for those he's most biased toward?

Sure. Another way of viewing my statement would be the possibility that he is less critical of patches that appear to be from white men. I think we'd agree that that would be a problem.

You will likely never get rid of bias. It's an evolutionary trait.

Citation needed.

If you believe people are biased due to metadata leaks which reveal personal attributes / identity... create anonymous identities

The opportunity to contribute to your project is not a privilege that people will fight for. As a project owner, having people willing to contribute to your project is a privilege. If you are sufficiently unaware of your own biases that you need to ask all your contributors to hide their identities in order to ensure that you treat them reasonably equally, you're making it more difficult for people to contribute and you should expect to receive fewer contributions. How is that optimising for quality?

empirical tests

[fche]

inclusive communities will overtake "pure meritocracies" because, in the long run, these communities will produce better output - not just in terms of the quality of the code ...

Matthew, would you mind proposing an actual test case with which to empirically evaluate this prediction? Are you aware of any projects that have (for example) forked into competing "inclusive" and "non-inclusive" teams?

Re: empirical tests

[mjg59]

No individual case will serve as a meaningful test, simply because it's impractical to control the other factors. We're going to end up looking at the success of populations rather than individual projects.

I don't understand

[(Anonymous)]

I'd like to understand what's controversial about that Contributor Covenant -- from both sides. From reading it, I don't really see why people would be strongly opposed to it. On the other hand, I also fail to see how it really helps. To me, it reads more like a new law saying that "it is now illegal to do illegal stuff". Did I miss something?

Re: I don't understand

[mjg59]

People may behave in ways that hurt others out of lack of consideration rather than out of malice. Others may feel[1] that if they're a victim of this kind of behaviour, any attempt to rectify it will either be ignored or end up hurting them more than the perpetrator. Documents like this exist to assure others that the community is aware of these problems and will attempt to

a) discourage them, and
b) deal with them appropriately if they do occur

[1] Often based on previous experience

SJWs? *rolleyes*

[(Anonymous)]

It is impossible to take ESR's goofy fantasies seriously, or anyone who believes his nutty ravings. There is no cabal of SJWs out to compromise his virtue. Treating people with courtesy and respect, and removing barriers to contributors from all walks of life is exactly how FOSS is supposed to work. Erecting barriers against women, people of color, or anyone else is the exact opposite of meritocracy.

"it must be possible for our communities to be accessible to anybody who can contribute, regardless of their background." Exactly. Diversity is an important feature in building a contributor community, because a lack of diversity leads to a lack of imagination. If you believe in the "scratch your own itch" concept, then limiting your contributors to a small homogenous pool means everyone will have the same itch.

Re: SJWs? *rolleyes*

[fche]

You're constantly switching between different meanings of "diversity" and "homogeneous" to make your point. Sorry, "diversity" as a term does not have the righteous moral authority of "motherhood & apple pie", so you don't get to do that. Specify the types of diversity you mean, and be ready to argue correlation to other desiderata.

It's not the goals, it's the culture.

[grendelkhan.livejournal.com]

Having seen some social-justice mobs in action, I think people are less scared by the idea of replacing their precious meritocracy (though there's plenty of that!), and more scared of the culture that comes along with it.

The prospect of being bullied off the internet for (it's kind of vague) using the wrong Twitter hashtag (http://slatestarcodex.com/2014/06/14/living-by-the-sword/) is frightening. Or the prospect of being bullied into an ER visit for heart troubles for using the wrong hashtag (https://mail.python.org/pipermail/python-cuba/2015-June/000085.html), which is frightening. Or the prospect of someone obviously making up accusations from thin air and commanding an audience of fawning apologies (https://storify.com/nkallen/a-spiral-of-confusion/) instead of being told to go pound sand. Maybe people don't want that kind of thing in their community. Maybe people don't want self-righteous bullying unto suicide attempts (http://www.dailydot.com/geek/steven-universe-fanartist-bullied-controversy/) (over fan art!) that everyone involved seems super-duper keen on.

Or maybe, from the comments section right here, one's politics being described as "violence" (https://mjg59.dreamwidth.org/38746.html?thread=1513306#cmt1513306) (to be responded to appropriately, I'm sure!)--perhaps that makes people uncomfortable.

I'd think a lot more highly of your view that hacker culture should embrace SJ culture if you actually addressed any of this stuff. Of course hacker culture would be better off it we dealt with implicit bias better, if we broadened our base of contributors and made it a more welcoming place in general. I don't see how taking on the norms of the social justice movement is going to do that--it looks like it would substitute a bunch of self-righteous commissars for curmudgeonly geeks, and at least the geeks don't tell you how much they're helping you when they're beating you up.

Re: It's not the goals, it's the culture.

[tim]

and at least the geeks don't tell you how much they're helping you when they're beating you up.

It says a lot about how some people feel about having their views challenged that they characterize it as being "beaten up".

Also, hold on, in the same comment:
"...one's politics being described as 'violence' (https://mjg59.dreamwidth.org/38746.html?thread=1513306#cmt1513306) (to be responded to appropriately, I'm sure!)--perhaps that makes people uncomfortable."

"...and at least the geeks don't tell you how much they're helping you when they're beating you up."

Is it wrong to describe political actions as "violence"? Or is it only wrong when those political actions are ones you agree with? Clarification would help.

Repent Sinners!

[(Anonymous)]

Why does this post so much reminds me of dark ages catholic church?

Projects like "Contributor Covenant" are irrelevant. There is nobody on other side objecting that we must consider race/gender/etc. when accepting patches. Nobody cares and in most cases I doubt you can figure that out based on email or user name.

Re: Repent Sinners!

[https://makabra.org/id/miroslaw]

Why does this post so much reminds me of dark ages catholic church?

Perhaps because you don't know much about both the middle ages and the catholic church.

There is nobody on other side objecting that we must consider race/gender/etc. when accepting patches.

Grand – what's the problem with stating it explicitly then?

Principle of Least Harm

[(Anonymous)]

Hacker culture has long been concerned with good design, and a core concept of good design is that code should fail safe - ie, if something unexpected happens or an assumption turns out to be untrue, the desirable outcome is the one that does least harm. A command that fails to receive a filename as an argument shouldn't assume that it should modify all files. A network transfer that fails a checksum shouldn't be permitted to overwrite the existing data. An authentication server that receives an unexpected error shouldn't default to granting access. And a development process that may be subject to unconscious bias should have processes in place that make it less likely that said bias will result in the rejection of useful contributions.

I think there is a strong claim you are making here, and you are not even saying explicitly that you are making this claim. I also think this may explain some of the controversy people are seeing here.

If I follow you correctly (and please tell me if I don't), what you are saying here is that in doubt, "accepting a patch" is doing less harm than "rejecting the patch". I do not think this is actually true. Every piece of code that you accept into a project is a burden, as the code has to be fixed (if it is flawed) and maintained. It is true that there is some damage done by rejecting a patch, in terms of the author of the patch interpreting this as discouraging their contributions. That's why it is important to give sound technical reasons for rejecting a patch.
However, I would argue that lots of damage can also be done to a project by prematurely accepting a patch. The burden of proof that a patch is useful lies on the side of the author, and the project should be careful about erring on the side of accepting to much. That way lies a horrible mess of a codebase that cannot possibly be maintained. So, if the goal is to fail safely and doing least harm, then I would actually argue that in doubt, a patch should not be rejected, since it may well turn out to be a burden.

Re: Principle of Least Harm

[mjg59]

If I follow you correctly (and please tell me if I don't), what you are saying here is that in doubt, "accepting a patch" is doing less harm than "rejecting the patch"

You don't. What I'm saying is that if you don't have processes in place to compensate for our human failings, you're more likely to reject patches that should have been accepted, more likely to fail to act on offers of help from people who would have been valuable community members, more likely to lose contributors as they fall victim to inappropriate behaviour.

Sorry, but it's been many a year since ESR said anything worth serious thought.

[(Anonymous)]

Yeah, he wrote a couple of good essays back in the 1990s about a new way to create & maintain software, but since then anything he's written has been expressions of his own right-wing projections on the world & software development.

And if we're going to judge ESR simply on the quality of his code, what has he written since fetchmail? His efforts to rewrite the Linux kernel configuration system wasn't exactly a resounding success: IIRC, he was more interested in using it as a DOOM module than functional code. His further coding efforts since have been even more underwhelming.

Maybe he does have something to say. But so might any non-technical person on coding style of the Linux kernel, Open SSL, or the best way to migrate from IPv4 to IPv6. And ESR is no longer consider an informed person on software -- or the best way to make it better. -- llywrch

why bother?

[(Anonymous)]

I don't understand the stakes here. Why should every society on Earth should be socially inclusive? I can understand the argument for social inclusivity with respect to the government and other organizations (like corporations and companies) that hold (or decide about) actual resources that humans need. But open source development group? OSS is freely available for anyone, by definition.

So I don't really understand a mind of somebody who thinks he should lead an open source project and it's unfair that he doesn't. What is this trying to accomplish, that couldn't be done by forking? And how we differentiate this from just being power hungry?

Maybe the stakes are things like user base, e.g. Debian has bigger user base than its fork (which is actually empirically not true, see Ubuntu). Well, then the question is, should everybody have the right to be popular (by associating with a popular group in society)? This is where it leads to, IMHO. It's just another human power contest in disguise, despite sweet words about equality.

Second, even access to those real resources isn't completely equal and democratic. Shouldn't people be more concerned about that? I am leftist, and movements like SJW seem to focus on their own members rather than be concerned by the real power inequality among people (because these concerns actually cut across minorities). It's just another form of group bias.

Side effect

[(Anonymous)]

The fact that FLOSS benefits your favorite minority/vulnerable group is only one of its side effects, a use case, not its sole purpose.
So I don't think there is need to turn Open source development communities into SJW armies. It is OK to have open communities and have inclusive values, but to subvert FLOSS development to serve such an (even "nice") agenda seems a bit misguided to me.

All ESR tries to express is the warning that we have come to a point where we are subverting the nice excellence values usually exerted in the FLOSS development communities for this albeit noble (but fashionable) notion that Social Justice precludes any other technical criteria.

About security/hacker/whatever "culture" and "ethics"

[(Anonymous)]

Somehow I've got rather interesting example of security "culture" and "ethics". Today. By your own hand :(.

When I visit blog of security researcher, what would I expect? Probably some security, and probably some privacy, etc. Security researcher supposed to be able to secure at least own systemd, and probably should take at least some care about visitors security, privacy, etc, right? I can see you promoted CoreOS in your twitter and if I got it right, you're also employed by them on some security position.

Now, I follow your link to CoreOS site and ... what?!

1) CloudFlare banner appears! It asks to enter captcha. Screw that. But wait, I've used HTTPS, right?!
- I can see my SSL session is hijacked - by cloudflare.
- I can see information about my visit is shared with 3rd party without warnings.
- I can see cloudflare dares to hijack content of web page to "protect" someone. And even HTTPS is null void, because it terminated on cloudflare's global spyware. So it's not a big deal if there was https at all. They can read all my traffic to this site while pretending they "protect" someone. Protection by hijacking HTTPS session. Sounds great.

2) I read privacy policy of CoreOS and it isn't exactly best thing on the planet either. Site claims it even collects name of hardware I use and overall privacy policy looks hostile. It's so nice to learn CoreOS privacy policy suxx when I already visited their web site, dammit. Following your link.

Though...
- I wonder what the hell CoreOS web site has detected as my "hardware name". I'm somewhat care about security, so CoreOS web site faced rather unusual setup and I fail to imagine what it would detect. Can you give a rough idea as security guy of these not-so-funny people?

- Uhm, well, if we are up for culture and ethics, there're quite many things to ask and tell, if your superb TPM things and distributed trust stuff ends up with just HTTPS session hijacked by cloudflare. So much security .. only to fuck it up in such a stupid way?! Honestly, it looks like plain marketing BS. What about culture and ethics? I've got really negative first impression about CoreOS, sorry about that. And of course I would not dare to try any code from company with such an awful privacy policy. So much loud buzzwords ... just to hunt down customers like a rabbits?

Toward Cyber-Civilization

[(Anonymous)]

In a Wild West atmosphere you get both nasty Blackhats AND (just a bit later) abusive enforcement officers/warriors - self-appointed or not - for example: Wyatt Earp and his siblings. The point of civilized codes of behavior isn't to empower the latter but to banish them as well, along with those badly-behaving Blackhats; creating instead a civilized atmosphere that abhors both.

A small nomadic tribe doesn't really need any of this of course, but as Matthew points out, we're well past that point. We're in an increasingly crowded Wild West, and need to evolve into something closer to a cyber-civilization. That won't be done in a day because it isn't entirely obvious what the best cultural practices are/will be.

Russell Irvin Johnston

[(Anonymous)]

One line that keeps coming up is "It should be about code, not feels."

That's a statement I agree with, but, to my mind bizarrely, people seem to be using it as an argument _against_ these kinds of covenants and codes of conduct. Surely the best way to enforce feels-neutrality is to have a document saying "don't try to stir up drama based on your personal feelings towards people's person lives, and keep your personal opinion to yourself" ?