What's the deal with all this anti-meritocracy stuff? Can't we all just work on a level playing field and move past this junk? Seems like not doing so causes a lot more problems than it solves.
The latest thinking from our fine universities is that only white males can get ahead in a meritocracy. Everyone else lives life at a disadvantage so they can't truly compete in such a system. Or something like that.
> The amount of discrimination is uniform across occupations and industries. Federal contractors and employers who list Equal Opportunity Employer' in their ad discriminate as much as other employers. We find little evidence that our results are driven by employers inferring something other than race, such as social class, from the names. These results suggest that racial discrimination is still a prominent feature of the labor market.
Sorry, I'm not saying everywhere in society _is_ a meritocracy, simply that it should try to function like one. Meritocracy should be a respectable goal, not one to be shunned. The labor market would be a better place if it were a meritocracy - can we agree on that?
And isn't the only way to live in that goal of meritocracy to actually try to?
Setting aside the pressing question of measurement and bias, it's not at all clear to me that it is just to apportion power according to ability and talent.
Consider Rawl's original position argument: https://en.wikipedia.org/wiki/Original_position -- sure, if you perceive yourself to be (or actually are) of high merit, a meritocracy sounds great. But defining a just society requires one to consider the possibility that one could be in the position of being incapable of meeting the demands that a meritocracy requires of its participants in order to flourish.
I don't see why promoting inclusiveness and frictionless contribution shouldn't be seen as meritorious activity - I'm not saying that's what you're suggesting, but "meritocracy" in the context of a software project like this is often taken to mean "can be socially dysfunctional so long as it is technically functional", as if the two requirements are in opposition to each other. I don't believe they are, and I think there are more examples of friendly and socially functional projects (that happen to be meritorious) than not.
I think that's all true, but too often "inclusiveness" is used as a stick to beat political opponents with. I'm all for attracting more developers for FreeBSD. However I'm against e.g. giving an appointed and unaccountable committee the authority to kick out anyone at their sole discretion, which was what some of the "code of conduct" proposals boiled down to.
Codes of conduct boil down to requiring members of the community to treat each other with basic decency, and defining a process for showing them the door when they fail to do so.
This is not a controversial concept in the real world. You'll be fired from your job if you treat your co-workers badly, you'll be ejected from the pub if you harass the other clients.
> You'll be fired from your job if you treat your co-workers badly
Sure, but there'll be a process. You'll have a right to a hearing, the right to your own union representative, and a right to appeal to a tribunal or similar. And the HR people themselves will have oversight. HR don't get handed a license to just fire anyone they want to.
> You'll be ejected from the pub if you harass the other clients
Pubs are not an institution to emulate. A project like FreeBSD should hold itself to a higher standard.
> And the HR people themselves will have oversight. HR don't get handed a license to just fire anyone they want to.
indeed.
and if the HR folks fire so many people that the damage the organization's ability to compete, they'll be out of work sooner or later. no such feedback mechanism is in place for conduct enforcement committees in open projects.
I'm not saying they can't, I'm saying they all too often don't, based on my own experience of seeing them introduced (primarily ScalaZ). IIRC the FreeBSD proposal that the article seems to be supporting has the kind of issues I described.
> Codes of conduct boil down to requiring members of the community to treat each other with basic decency
If only it were that easy.
I've seen codes of conduct for technical projects where they said things like "MUST be inclusive of trans, gay, etc.", along with political / ideological statements. And the kicker was a phrase saying "these ideologies are not open for discussion".
Why a software project needs an ideological statement, I have no idea. But it hits all of my red flags that the purpose of the code of conduct is not to treat each other with basic decency, but instead to push a particular ideology.
> you'll be ejected from the pub if you harass the other clients.
What about simple questions?
Q: Hi, I noticed you're a Democrat / Republican / whatever. I think I may disagree with your opinion.
A: THE SIGN SAYS NO QUESTIONING IDEOLOGICAL PURITY. GET OUT.
> Why a software project needs an ideological statement, I have no idea.
Any selection of relative values is ideological; and every project is, inherently, based on an agreement to pursue some set of values. And the choice for those values to not include social inclusiveness is as much an ideological choice as the decision that the values should include inclusiveness (or that they should include exclusiveness, which is a third possible ideological choice.)
Your comments are either a tautology (projects are based on ideas), or very likely to be wrong (engineering projects should also include social values).
e.g.
> ... an ideological choice as the decision that the values should include inclusiveness
I explained why this is not just unnecessary, but also why it's wrong on a much more fundamental level.
When I get patches from people, I don't care what's under their clothes. I don't care what their political opinions are. I don't care what religion (or not) they belong to. I evaluate the patch based on it's engineering merits. I give them a review of the engineering work that they did, without reference to any of the above mentioned issues.
It's absolutely inclusive, in a way that perhaps you don't understand. It doesn't pervert the project by demanding that members adhere to a particular ideology.
I find naive attempts at "inclusiveness" to be repugnant. They are a back-door way of leveraging such "niceties" into taking over the group, and establishing an ideology-driven totalitarian dictatorship with Orwellian overtones.
And no, I'm not exaggerating here. Look at any number of groups which started out as goal oriented, and devolved into fights over ideological correctness. Very soon, the arguments over ideology overwhelm the group, and everyone who gets things done... leaves. What's left is the ideology-driven politicians, who then find out that they're in their an echo chamber. They turn on each other, and the group dies a flaming death.
See Atheism+ for a good example of this in recent years.
I never said codes of conduct were all perfect. Some (probably most) are certainly flawed and could do with improvement, but the underlying goal is generally what I described. I feel the basic idea is both sound and laudable, so I encourage people to take part in iterative improvements, rather than rejecting the idea outright.
And yes, treating other people with basic decency is actually a tricky thing that needs to be spelled out for some people. A lot of people actually - you gave some great examples, whether you meant to or not.
There are quite a few people who are technically very capable and at the same time socially dysfunctional. They are great if they can have their own corner of the project. But can be a disaster in areas where interaction is required.
There is also the opposite, people who are busy communicating, who generate lots of noise and never do anything.
So yes, merit should be defined as getting useful things done with rough consensus and not as brilliant code that then split the community.
I may be wrong, but I actually think the current move towards codes of conduct and clarity about expected social behaviour should help with these cases.
Being socially dysfunctional (as opposed to being malicious, which is a different problem) is often linked to an inability to pick up the social cues and clues that most people take for granted. A document which clearly explains and gives examples of unwelcome behaviour should help in these cases - assuming people actually read it!
..and assuming those examples of unwelcome behavior are objectively defined. Any room for judgement calls or definition stretching, and you've taken what it supposed to be a useful metric and turned it into a cudgel to be misused.
Example: Wikipedia. The talk pages on that site, especially on politically charged topics, are detailed examples in how one can behave in a destructive fashion and drive off talent without ever dipping into base namecalling.
> I don't see why promoting inclusiveness and frictionless contribution shouldn't be seen as meritorious activity
The question is "who judges" ?
A meritocracy is generally an engineering meritocracy. People who get things done, get more merit. And it's easy to judge who gets things done. No one cares if the contributor is black, blind, gay, trans, politically left or right. They're doing engineering. All other topics are off topic for the engineering project.
In contrast, "inclusiveness" is a vague concept. It's hard to judge "inclusiveness". So when the judging happens, it tends to be subjective, and driven by politics, ideology, or emotion.
This subject came up on the FreeRADIUS list last year. I made similar points here:
The only permitted topic on the list is technical discussion related to FreeRADIUS.
Off topic messages will result in a warning. Continued misbehavior will result in the person being unsubscribed from the list, and permanently banned.
This code of conduct was defined after many years of experience running the list. It is simple to explain, and simple to enforce. Unlike other codes of conduct, it does not require people to be "inclusive" or "accepting" of certain topics. It requires people to be blind to non-technical topics, as those subjects are explicitly off-topic.
---
Such a "code of conduct" is easy to explain, easy to enforce, and easy to judge. No politics, ideology, or emotion get in the way of people doing engineering.
There's a big difference between the concept of meritocracy on paper and the actual behavior of organizations calling themselves meritocratic. In many cases, the operational definition of "merit" ends up incorporating irrelevant biases of the most senior and influential members, sometimes cloaked by formalities such as HR performance metrics.
So, much like with debates over communism, I think we end up with a major disconnect between people who focus on love for the ideal and people who focus on hate for the implementations they've seen.
Do you have such an example of an organization that claimed to be meritocratic but defied that in practice? There are plenty of such examples for communism of course, but I'm blanking on ones of meritocracy.
Seems like it should at least be an amicable goal.
I don't know that they've ever (publicly) published a post-mortem, but I know GitHub used to emphasize being a "meritocracy" but have since moved away from that after some long-festering issues (that were distinctly anti-idealistic-meritocratic) surfaced.
There's also the fact that the participation of women and minorities in OSS is smaller than their participation in the technology industry as a whole. Granted, not every OSS project touts itself as a meritocracy, but it's probably the area where the concept is championed most vociferously.
>participation of women and minorities in OSS is smaller
I think that can mostly be diversity hiring. A company can hire women/minorities to increase diversity. A FOSS project can't accept code on the premise of diversity. I think the narrow scope of most FOSS projects (or the individual components that contributors wind up specializing in) also makes most of the benefits of diversity less relevant. Diverse teams do better on diverse tasks.
(I don't think diversity hiring is a bad practice as long as the people hired are qualified for the job)
There's a ton of possible interpretations here - could simply be that more women just generally have other things to do with free time than men. Or maybe it's that women are genuinely scared off of open source development due to problems. Or an issue with the studies that get those results as a lot are based off username, which might be a bad metric. Lots of possibilities.
Once upon a time, social justice types supported meritocracy. That was in the era when having classical musicians audition behind a screen increased the % of women.
Unfortunately, the technology world has not had the same experience. When technology becomes more meritocratic (e.g., audition via github/coding tests/open source contributions rather than interviews), we get more Asians, fewer non-Asian minorities and fewer women.
Because meritocracy in technology fails to achieve the goal of "gotta catch them all", it must be opposed.
> When technology becomes more meritocratic (e.g., audition via github/coding tests/open source contributions rather than interviews), we get more Asians, fewer non-Asian minorities and fewer women. Because meritocracy in technology fails to achieve the goal of "gotta catch them all", it must be opposed.
This seems to suggest that you don't want meritocracy. Was that sarcasm?
I don't think meritocracy (at least in tech) helps promote "diversity" (where diversity is a code word for "women and non-Asian minorities"). (The latter claim is broadly supported, albeit in convoluted language, by the social justice types who oppose meritocracy.)
I'm perfectly fine with this; "gotta catch em all" is not one of my goals. It is, however, the goal of many social justice types, so they necessarily oppose meritocracy.
Google and Facebook have both claimed that women and minorities tend to outperform hiring scores, which is why they hire them more aggressively.
I think there are two factors at play:
* Generation and exchange of ideas and approaches is the most important part of software engineering on a team. Diversity of gender and background probably gives this factor a bump.
* People are biased, both consciously and unconsciously, against certain minorities. This means lower evaluation scores and weaker resumes (since the world shares the bias).
But whatever the reasons, Google and Facebook are pretty good at this whole data analysis thing, so I wouldn't discount their experiences.
I'd be curious to see this analysis. Can you link to it?
Here's a hypothetical. Imagine google made an error and it turns out that their analysis has a sign error. Blacks/women actually underperform. Would you favor flipping the sign on whatever action you propose? If not, why not?
I ask this because in a number of other contexts, the sign is actually flipped. Blacks drastically underperform what would be predicted from college entrance scores, they are less likely to pay back loans (holding other things constant), and more likely to commit crime.
Generation and exchange of ideas and approaches is the most important part of software engineering on a team. Diversity of gender and background probably gives this factor a bump.
I'm the only person of my race/nationality at my current company, but I've never really observed this effect. Can you tell me how to tap into these powers?
I admit, I do sometimes provide ideas that no one else has, mainly in the area of bayesian stats, low level performance hacking and probabilistic data structures. Is that what you mean? Are these the secret powers unavailable if you don't have someone of my race?
> Imagine google made an error and it turns out that their analysis has a sign error. Blacks/women actually underperform. Would you favor flipping the sign on whatever action you propose? If not, why not?
No, because of the above point about diversity. It has an effect on more than just the individual. I don't know if Google has made any claims about the following, but it's been noted that, for example, diverse management teams tend to outperform nondiverse ones.
> I admit, I do sometimes provide ideas that no one else has, mainly in the area of bayesian stats, low level performance hacking and probabilistic data structures. Is that what you mean? Are these the secret powers unavailable if you don't have someone of my race?
You are being intentionally facetious. I know you're a smart person, that you're very probably aware of what diversity arguments are about, and this reply is thoughtless in a disrespectful way. I'm only spelling it out to avoid downvoters: the idea is that different approaches and attitudes are informed by race, culture, background and gender in ways that are difficult to measure in the interview process.
For the record, I would consider a white hillbilly or southerner as 'diverse' in most computer workplaces.
That point does not apply to lending or crime prediction. There is no collective decisionmaking on the part of parolees or borrowers.
Do you have any objection to using your same solutions, but with the opposite direction, in this areas? E.g., if google should try and hire more blacks (due to them overperforming), should BofA try to lend less money to them (because they underperform)?
Similarly, since we know diversity harms group cohesion, should companies which value group cohesion avoid it?
You are being intentionally facetious. I know you're a smart person, that you're very probably aware of what diversity arguments are about, and this reply is thoughtless in a disrespectful way. I'm only spelling it out to avoid downvoters: the idea is that different approaches and attitudes are informed by race, culture, background and gender in ways that are difficult to measure in the interview process.
I don't know why you find this disrespectful. Could you clarify?
I'm simply asking, concretely, how "race, culture, background and gender" inform different approaches and attitudes to detecting systematic failures in a sensor network? Or similarly, how does this inform different approaches to querying a dataset consisting of a normalized SQL schema together with a collection of very large structured files?
I'm being facetious because I consider this idea to be patently ridiculous. In most of my jobs I've been the only person of my race present, and it's literally never affected any professional task.
That's also why I'm asking for specifics, rather than vague allusions to some study you kind of remember reading.
I do of course know what the real argument is about. Diversity is a sacred value and all the arguments you've brought up are actually just post-hoc justifications for a behavior you virtuous. I'm just arguing that there is little more than that.
It's popular among computer nerds to dismiss other peoples' ideas. They might do something like attack someone's ideas with intentional misunderstanding, lazy thinking, and facetious reasoning. In short, they do not show the bare minimum of consideration for others' ideas, instead looking first for avenues of attack. Having ignored and attacked the other person, they then claim no disrespect was meant. They might say something like "I don't know why you find this disrespectful. Could you clarify?"
It does not occur to them that being able to attack peoples' ideas in this pompous way is actually a position of privilege. Anyone can do it, but people born a step ahead are more likely to not reflect on their position, or even feel entitled to it.
In my experience, women and people from disadvantaged backgrounds--people who were not praised to the moon for writing "Hello World" in eighth grade--are less likely to behave in this way.
This is self-evidently an enormous advantage on engineering teams.
Usual disclaimer: personal experience, your mileage may vary, this is just one example, privileged backgrounds have advantages too, yada yada yada.
I did not attack you or ignore you. I directly addressed one of your arguments and attempted to determine whether the other argument is your "true rejection" [1].
On the contrary, the only person ignoring the other's points and making anything close to an attack is you. You've accused me of being disrespectful, called me lazy and accused me of intentional misunderstanding, while simultaneously NOT addressing any of my core arguments.
Quite entertaining, I must admit.
[1] Specifically, I think even if that argument could be proven false, it would not change your conclusion at all. So bringing it up is merely a distraction. See also: http://lesswrong.com/lw/wj/is_that_your_true_rejection/
The question was if diversity is valuable in engineering. I gave a specific example of a specific kind of diversity that is valuable to engineering teams.
If you're interested in Google's data, they make an excellent search engine that you can use to find that kind of stuff. I encourage you to do your own research, in part because I think I've done enough work leading you to the proverbial water.
'Diversity' is usually code for blacks and women. True diversity of thought and experiences are what bring the benefits, which means that a team of 100% males could be highly diverse.
In general I would agree that woman and blacks do have different experiences in life to most people in Silicon Valley. I fear that the push to improve 'diversity' will actually reduce true diversity. Companies in Silicon Valley usually hires people from the same universities who all have similar experiences. This crowds out the hiring from less famous universities, overseas students and other parties. There are no vocal activists to push that kind of diversity.
I still think we as a community should be open to all to participate. But we shouldn't have to lose what makes our community great in the process.
I don't know about you guys, but I don't care about the race, religion or sex of the other parties I work with. I only care about the quality of their work and that they aren't arseholes to be around.
That's a straw man. "Audition via github/coding tests/open source contributions" is not equivalent to a "blind audition" for musicians. GitHub/OSS already have lower participation rates from women and minorities than the technology industry as a whole precisely because the OSS "meritocracy" fails to address discriminatory behavior and is not blind: https://www.theguardian.com/technology/2016/feb/12/women-con...
Blind coding tests would come the closest to the equivalent of a blind audition, but coding tests as hiring criteria have their own problems in general.
The conclusions of the actual study don't support your claims. From Scott Alexander's review of it:
A non-peer-reviewed paper shows that women get more requests accepted than men. In one subgroup, unblinding gender gives women a bigger advantage; in another subgroup, unblinding gender gives men a bigger advantage. When gender is unblinded, both men and women do worse; it’s unclear if there are statistically significant differences in this regard. Only one of the study’s subgroups showed lower acceptance for women than men, and the size of the difference was 63% vs. 64%, which may or may not be statistically significant. This may or may not be related to the fact, demonstrated in the study, that women propose bigger and less-immediately-useful changes on average; no attempt was made to control for this. This tiny amount of discrimination against women seems to be mostly from other women, not from men.
Most of the results of that study suggest open source is friendlier to women than to men. But the study isn't really that high quality, and the results aren't that strong, so I wouldn't draw a very strong conclusion from this.
When that study came out I asked the authors for their data set and analysis scripts. They categorically refused. Also not a strong indication of quality.
The FreeBSD project does now have a code of conduct; it is, Rice said, a "patched-up rush job". Project members still honestly thought that "meritocracy" meant "inclusiveness" initially. They have since learned otherwise, and the code is being reworked.
I think many people feel "meritocracy" has become a code-word for "allowing technical contributions to justify and excuse bad social behaviour."
Important free Software and Open Source projects are almost always community efforts. Ignoring bad behaviour which harms the community may have technical benefits in the short term (assuming the people behaving badly are skilled hackers), but in the long term their contributions may not be worth the harm they do by excluding and driving away other potential contributors.
A hostile work environment is rightly considered a problem that needs to be fixed in a professional context. For those of us doing FOSS as a hobby, it's even more important - few will spend time on a hobby where they are treated badly.
I also like the meritocracy concept. But I feel rather strongly that it is important that the "metrics" are not just technical, but social as well.
I hear you, I definitely agree with your premise, but my worry is that this will basically boil down to a political test to participate in many FOSS communities.
At what point do you deem social behavior unacceptable? It's a fine line to draw and one that might be difficult for many communities to do correctly.
Drawing that line is exactly what codes of conduct are supposed to do - and like everything else in our community, these are documents which are copied, forked and improved by pull requests.
The problem is it still needs to be up to project leaders to make a determination of whether or not the behavior violates those codes of conduct. And they might not be particularly well equipped for that.
What's considered "harassment" for example? Does 1 off comment count or does it need to be systemic? What if it was a heat of the moment situation and an apology was made afterwards? Does expressing an opinion less than the generally accepted one about a rape case for example count as misogyny? What about mental health comments not in line with generally accepted opinions, but which might still hold some validity? How about defending political opinions based on your religion?
There are too many questions that I know many people would respond very differently to.
There are indeed many questions. But a lot of people have spent a lot of time thinking about these things. The answers are out there...
I think if we take a step back and don't try to invent all the wheels ourselves, we'll find that almost all of these questions have established answers from the world of business and human resources.
We do have to get past the first step though, which is agreeing that these are problems we care to solve. The wider community is still divided on that, as illustrated by this thread and the comments on the OP.
I don't think "the answers are out there" so cut and dry. There's many political and social opinions that there isn't a clear resolution on. So unless we have a very good way to solve this concretely and provably I think it's best to not get involved in trying.
That's all well and good for most things, but something that commonly involves shunning people from your communities I don't think so. You need a higher standard - one which we don't have. Even HR people can be fired and are somewhat liable for their decisions. When it comes to oversight, there's just too little here.
There are indeed many questions. But a lot of people have spent a lot of time thinking about these things. The answers are out there...
Yet conspicuously absent in your post is a link to where those answers are. I suspect that because as soon as you link to one you've actually drawn a line in the ground. Instead of codes of conduct which sort of fuzzily describe that one exists "out there."
And once you start talking about where lines are really drawn, it becomes easy see how little agreement there actually is. Even among people that are more-or-less on the same page regarding which problems "we" care to solve.
I didn't give examples, because it's not my field and because I wasn't interested in the inevitable quibbling about minor details.
But I do know people that do that sort of work, and I also know that when I went looking for a code of conduct for my own project, I found lots of pre-existing material to work with.
You guys are making this out to be a lot harder and more complicated than it actually is.
All of the pre-existing ones suffer from this exact problem though in my experience. They leave too much, often almost everything to be decided by the project leaders.
Often times this amounts to "don't be racist" and similar proclamations - these don't offer guidance as to what's deemed racist. Some people would say opposing affirmative action is racist - is that the standard the project goes by? Based just on those codes of conduct, who knows?
Heck, some people would say the president of the united states is racist, but over 47% of the voters wanted him. If you think that full 47% of the population is terrible and racist, on sheer population grounds you probably just rejected a lot of good people.
This is why I find codes to conduct to be extremely low value, they provide nothing beyond say "don't be an asshole" and a fear of reprisal for political reasons.
If 47% of the American voters can't be wrong, why did a similar number of voters choose differently?
It's entirely possible to be racist to some degree while still being a good person overall. That doesn't mean racism is okay, or that it should be acceptable. But suggesting that opposing racism equals branding almost half of the American voters as terrible people is a strawman.
Well, I've seen a surprising number of people talk that way on Twitter and Facebook. Maybe they're just talking out their asses, but some of them seem to take it seriously, so it's not exactly a strawman. I've seen people suggest that yes, if you voted for Trump, you're racist, sexist, homophobic and any other number of things.
My point is, if you use a code of conduct that simply includes dumbed down provisions with no detail, you have no way of knowing what the views of the project leaders are - you might have risk that kind of treatment because you said something positive about Trump on Twitter.
I suppose you can argue this is a strawman on the grounds that it doesn't seem to be happening so far with projects which have implemented a code of conduct - but I'm worried it might have a chilling effect on political commentary in FOSS communities, causing more people to comment anonymously and disassociate their political views from their real information. This kind of chilling effect is hard to measure in many other cases already.
"At what point do you deem social behavior unacceptable? It's a fine line to draw and one that might be difficult for many communities to do correctly."
This is key. A large part of contemporary American (and, as I understand it, European) politics involves struggles over the size of the Overton window. This means that even people with little interest in the project will have a strong incentive to use the project's code of conduct as a tool for defining the boundaries of acceptable discourse in the communities that overlap with the project.
I fucking love FreeBSD. Seriously, I use it any chance I can. I have a Debian VM that I use to do development on because of the tool chain I have to use. But for my production personal websites that I run I choose FreeBSD.
Nothing in this article makes me want to change my mind. On the contrary seeing this article on a 'Linux' website generally lowers my opinion of both the 'Linux Community' and LWN. If LWN had fewer articles like this, and more articles actually communicating useful information to me, I might actually read it more.
I used to use Debian almost exclusively, but ever since this systemd BS I've gone FreeBSD as much as possible. This isn't about personalities, it's about me not caring about the problems that systemd is trying to solve.
I skimmed through the comments and most of them seem to be at odds with the content of the article (which seems to offer constructive opinion). The very first comment is frankly bizarre.
The purpose of the article was certainly not to try to change your mind. I saw a talk by a FreeBSD core team member that I thought was interesting, so I wrote about it. Are you saying LWN should not venture into *BSD space?
Another FreeBSD developer here. I pay for an LWN subscription to help keep on top of what's happening in Linux and to support the high-quality coverage.
This is my exact situation too.
Give me simple config (nee .ini) files to grep/edit, and I can have a system running _the way I want_ faster then any other method.
I can understand it, I can edit it, I can fix it.
IMO systemd and the like are too much like hand-waving voodoo.
It's like trying to interact with an adolescent AI: Computer run service abc123
I don't feel like it.
With config files: Computer run service abc123
Error on line #5 of abc123.conf
Bingo!
I wish they had just named systemd as HAL. It would have let me avoid months of hair-pulling.
Hi, I'm the guy who wrote and presented the original piece.
None of it was meant to discourage you from using FreeBSD. I had nothing to do with the LWN summary but the whole point of the piece was to look at what FreeBSD could be doing better from a community standpoint.
You do let useful contributions slip through the cracks from time to time.
A case in point: Baptiste Daroussin wrote up documentation for EVFILT_FS in kevent. FreeBSD actually has had this for a decade, not that one would know it from the doco (because contrary to the norm the code was patched without amending the doco to match). This was in 2010. The doco patch was never actually added.
Nonetheless, it's one thing that you could do better; and that's what you said that you wanted to look at. There's a long tail of small useful contributions -- even from the people with the FreeBSD.org mailboxes (-: -- that simply don't make it.
There's nothing about EVFILT_FS in the 11.0 kqueue() manual.
Also the "surface" the community sees is not very inviting. Bugzilla is horrible to use, browsing it gives you the strong impression it is abandoned. The wiki is also always outdated, or you can't tell. The forums are a nice addition, but they are only visited by beginners, devs or advanced users don't wanna go there. GitHub pull requests are ignored, because we still sit on SVN (and lol perforce - is that still around?).
Don't get me wrong, I love FreeBSD, but some of the effort and friction is unnecessary.
>I used to use Debian almost exclusively, but ever since this systemd BS I've gone FreeBSD as much as possible. This isn't about personalities, it's about me not caring about the problems that systemd is trying to solve.
Thankfully for those of us unwilling or unable to make the jump to FreeBSD there is still Slackware.
> If LWN had fewer articles like this, and more articles actually communicating useful information to me, I might actually read it more.
As a occasional reader of LWN, I like the fact that they cover other topics apart from LWN. It's always good to learn/see how other communities operate.
is said Debian VM under FreeBSD? if that's the case, what do you use for your VMs? qemu? virtualbox? I'm not sure as to the state of virtualization on FreeBSD...
I clicked on this expecting some technical stuff and all I got was this BS social/community whining.
Well, even in the worst case where FreeBSD community is trash, they have one of the best kernel implementations and one of the best open source OS documentation.
I agree, it was a disappointing article. Even the technical section about source control at the beginning seems a bit odd. First they note how huge the codebase is, then move on to compare the project to Django and Python?
Let's remember that FreeBSD is an entire OS, not just a kernel. If you want to compare it to the linux world you have to imagine the kernel + the GNU userland + the distro specific utilities and package management of something like debian or red hat.
It's not really surprising that the codebase ends up being huge and that you can't just change the architecture and tooling around it to use the trending software stack of the day.
On the other hand the fact that FreeBSD is so comprehensive is the killer feature for me when compared to something like Linux. It's a full OS, with everything (usually) playing nice with each other, a single documentation for the entire base system etc...
I also find that the kernel code is generally a little nicer than linux's, although linux is more featureful overall.
Yes, FreeBSD is slower moving than Linux and generally more conservative. That's not a bug, that's a feature.
The whole idea of this talk was about the community side of the project. I make exactly the points you're making regarding code size but that just speaks to the difficulty of managing a community looking after a codebase of that size.
I'm also not criticizing the pace of FreeBSD development so much as I'm criticizing the pace of its leadership (of which I'm a member, don't forget) to deal with issues that would make FreeBSD more fun to work on.
Thank you for taking the time to reply. It was just a bit of a surprising read from my point of view, as somebody who's not directly involved in the project (like you are) but who's been observing it since around ~2004.
There are three main points in this article: the issue of version control, the "Dragonfly BSD incident", and the GamerGate garbage fire.
Regarding the first issue, while it was sad to see a good dev like Matthew Dillon leave the project, what do you think should have been done better by the leaders of the project? Clearly there was an incompatibility here, maybe having Dillon work on his own project (and then sometimes have a back and forth between Dragonfly and FreeBSD) was the right solution? Would Linux for instance have dealt with the issue better? I recall many personality clashes amongst the Linux "elite", some not so long ago.
The migration away from CVS sure did take a long time, but as you mention yourself the technical challenge was pretty high. Lest we forget, Linus ended up writing his own version control system because the existing solution were not deemed satisfying. And FreeBSD is significantly bigger than linux's codebase. Regarding the test suite, testing operating systems is notoriously difficult (you can't easily abstract away from the hardware to run well contained unit tests). I don't recall Linux having an extensive test suite either.
The GamerGate thing I won't touch with a hundred kilometer pole. How an operating system project got dragged into that I still can't fathom.
So in the end, I don't think those issues are that big of a deal on their own. IMHO the main "trouble" with FreeBSD is simply that its market share is tiny compared to Linux. I'm a big fan of FreeBSD but my IRL job is linux kernel dev, not FreeBSD kernel dev. More and more first party vendors support linux, not any of the *BSDs. "Netcraft confirms it - BSD is dying". There's a momentum problem and I'm not sure switching to github or adding a test suite are going to solve it.
FreeBSD is betamax, linux is VHS. FreeBSD is mercurial, linux is git.
FreeBSD is pretty common in some market segments, especially infrastructure appliances and devices. It's an easy choice for NAS controllers, internet core routers, email gateways, firewalls, messaging platforms, CDNs. Not to forget the humongous chunk of FreeBSD that is in OSX.
If you think it has a small market share, you're looking at the wrong market.
While I agree it is popular in certain circles that use it in high volume, it clearly has a relatively small mindshare among developers and open source contributions. Linux, just the kernel, regularly gets contributions from 100x the people that contribute to FreeBSD base.
I'm gonna have to challenge you on that 100x number because I think you may have plucked it from thin air. Obviously contributor numbers are a) hard to define and b) hard to capture, but for an order-of-magnitude estimation, I give you two sources, both of which have incentive and access to maximise the number counted:
So Linux has more like 13x individual developer count in recent times. You can round that down to 10x if you like, but 6x doesn't tell the recent story.
Note that this is comparing the Linux kernel to FreeBSD base, which is like kernel + glibc + coreutils + binutils + other stuff.
The only thing that could've been done better was realizing that there wasn't a way to fix it earlier. The story was more told as to give an idea of the kinds of things a community can face.
The migration to Subversion was given as a case where core could've made a decision and given direction but chose not to. Whether they're right or not is a whole separate set of arguments.
I think everyone would be happier if Gamergate had never been a thing.
The trouble with FreeBSD, as stated, is that like a whole lot of other community projects it's largely volunteer and its leadership is 100% volunteer. If we had more mindshare we might have more volunteers but then we'd need leadership to be more active.
Same, I do my best to stay away from politics but even a damn BSD story ends up with politics. It's not so much complaint to author but just a grim realization...
The article shows an excellent example of 'moving fast and breaking things':
< In comparison, Python started on CVS, moved to Subversion
< in 2004, then to Mercurial in 2009, and is now moving
< over to GitHub.
I used Python around 2004 and 2005, and never went back to it for my personal projects.
I would rather prefer 'moving slow and preserving things'. Any body here remembered how things went when Linux moved from OSS to ALSA? And now there's this systemd.
you just made my blood pressure go up a few points. The "killer feature" in PA is it's "uninstall" button. I've literally had my sound not work after an ubuntu installation, uninstalled PA, and it immediately worked fine.
I've had audio problems with OSS and ALSA too, in the past. Mostly with ALSA. Overall, PA is an improvement over those, but of course every change can bring new breakage, which was the original point.
I would not count your example as one of moving fast and breaking things. What was really broken by changing the VCS? If you still prefer CVS over git for lame super-conservative reasons that's your choice.
Speaking as a python user, I guess your way of development is then to still code everything in C and sh? No thanks. I'm willing to update my code to newer, less insane, versions of a language - if the benefits outweigh the pain of course.
You stopped using python because they changed the VCS they used for the language? If you're not working on python itself, the language, why does the VCS they use matter to you?
Python is usually considered the one language that moves slowly, exactly to preserve compatibility. Can you explain why you "never went back to it"?
You must be new to Linux. You see, the poster needed a random excuse to inject systemd flamebait, so they grasped at the closest straw they could find, whether or not it was even remotely relevant.
I write new stuff in Python3, and what I do easily works on any Python3.
I don't have Python2 code to maintain, but if I had I would seriously consider updating it. Because I think the changes are reasonable for the most part.
Dou you write your C code in GCC C? Intel C? Microsoft C? C89? C99? C11? What libraries and what versions do you use?
I use both, but I like the changes in Python 3 more. I also like the way Python introduced version 3, by back porting features into the 2.x branch, thus easing the transition to some degree.
I've been using Python since version 1.4 or 1.5. Since that time, they've made many changes, but Python has continued to be a great language. Of note, during the 2004 to 2005 timeframe, they released Python 2.4, which brought a number of speed improvements, multi-line imports, function/method decorators, the ability to invoke modules from the command line, built-in sets, generator expressions, new sort utilities, new string methods, etc.
In the face of all the great things happening in Python during 2004 and 2005, why would you abandon it due to a change in their VCS, especially when SVN is so similar to CVS?
What of the things you are doing did they break by "moving fast"? I learned Python around the same time frame, and while Python has had its pain points since then (packaging, I can see why Python3 is painful for some), "moving fast and breaking things" really doesn't fit my experience.
"One day [Randi Harper] decided to block the Gamergate "trash humans" out with a Perl script; it worked, causing them to lose their minds, Rice said, at which point they started attacking FreeBSD."
Anyone have more info about this? Especially the "Perl script"?
She wrote a script that found every Twitter account that followed 2 or more people from her list of supposed Gamergate figures (which included at least one major celebrity) and encouraged people to mass block all the accounts it found as an anti-harassment/anti-Gamergate measure. The result, in social terms, was that everyone was forced to choose between listening to one side or the other, including journalists who wanted to report on Gamergate, and their entire view of the other side was filtered through what that side said about it. It was, hands down, the single most clever and effective use of a technical tool to increase polarization and hostility online I have ever seen. (Especially since it had little impact on either determined axe-grinders who wanted to cause trouble by digging up inflammatory remarks and quoting them out of context or actual harassers.)
It was, hands down, the single most clever and
effective use of a technical tool to increase
polarization and hostility online I have ever
seen.
This seems like a nonsensical assessment at best. Use of the script was voluntary, and GG was an organized mass-harassment campaign premised on polarizing and hateful nonsense. The whole social phenomenon consisted of a distributed wave of hostility.
I wound up adapting the script myself at one point to mass-block followers of a YouTube/Instagram celebrity who shares my first name and triggers a neverending stream of namespace collisions. It's a reasonable brute-force hack in an environment that lacks real features for dealing with a large population of griefers.
Petty history aside, the project needs to be more open in communication. There's too many secret mailing lists and mystery discussion, which is a common thread in all the problems the list describes.
My early hacking days were primarily on FreeBSD, and though I idealogically agree with RMS and therefore GPL, which is why I push myself onto GNU ecosystems, I must admit the one thing that often tempts me back to bsd land is the consistentcy in system tools and functions, even across other BSD's. I have seen GNU/Linux abused just like I feared BSD systems were going to be, so for practicality purposes I'm seeing less and less of a difference, but oh what I would give for a GPL focused BSD like ecosystem focused Linux effort.
This reminds me of the problems the PHP project faces. It has the same lack of leadership and just goes by consensus, with the same problems (i.e. little gets done when hard decisions must be made; the system for voting on things has helped a little, though, because it means people who are bold can sometimes get things in). There was also an attempt to adopt a code of conduct and, in its failure, it exposed why the project could benefit from one in the first place.
I suspect a lot of open-source projects have similar issues.
Well, there was quite a hostile response from some to it, so its proponent dropped it. What was interesting about the response was how specific individuals did not respond civilly (personal attacks, framing it as a political conspiracy, etc.), thus demonstrating why a code of conduct might be useful.
I love FreeBSD, and I felt like the author of this article does too. It didn't come across as a rant to me, but rather an explanation, and some constructive criticism, of what the author thinks the FreeBSD project could do better.
As with all constructive criticism, you absorb what you feel will help you reach your goals, and reject what doesn't. It is always a good thing to have those insights and options though, I think.
I don't think criticizing FreeBSD's "age" is exactly reasonable in this context, seeing as how Linux is two years older (and GNU even older than that).
FreeBSD is a derivative of BSD, which has history going back to 1977. It long predates Linux (1991) and even predates public announcement of GNU (1983).
I personally don't consider that to be exactly relevant (if it were, then we could say that macOS is also older than GNU, which is sufficiently unintuitive to be misleading). It'd be more relevant if FreeBSD was actually maintained by UC Berkeley's CSRG as an official successor to BSD itself; otherwise, we're dealing with a kind of ship of Theseus situation where things are replaced and rewritten and "age" becomes very ambiguous.
I also don't really consider "age" in and of itself to be a real factor at all here anyway. It implies (probably not intentionally, but the implication is there nonetheless) that things should be rewritten from scratch all the time in order to avoid "old" things, which would be silly.
137 comments
[ 5.1 ms ] story [ 260 ms ] thread> The amount of discrimination is uniform across occupations and industries. Federal contractors and employers who list Equal Opportunity Employer' in their ad discriminate as much as other employers. We find little evidence that our results are driven by employers inferring something other than race, such as social class, from the names. These results suggest that racial discrimination is still a prominent feature of the labor market.
And isn't the only way to live in that goal of meritocracy to actually try to?
Consider Rawl's original position argument: https://en.wikipedia.org/wiki/Original_position -- sure, if you perceive yourself to be (or actually are) of high merit, a meritocracy sounds great. But defining a just society requires one to consider the possibility that one could be in the position of being incapable of meeting the demands that a meritocracy requires of its participants in order to flourish.
Codes of conduct boil down to requiring members of the community to treat each other with basic decency, and defining a process for showing them the door when they fail to do so.
This is not a controversial concept in the real world. You'll be fired from your job if you treat your co-workers badly, you'll be ejected from the pub if you harass the other clients.
Sure, but there'll be a process. You'll have a right to a hearing, the right to your own union representative, and a right to appeal to a tribunal or similar. And the HR people themselves will have oversight. HR don't get handed a license to just fire anyone they want to.
> You'll be ejected from the pub if you harass the other clients
Pubs are not an institution to emulate. A project like FreeBSD should hold itself to a higher standard.
indeed.
and if the HR folks fire so many people that the damage the organization's ability to compete, they'll be out of work sooner or later. no such feedback mechanism is in place for conduct enforcement committees in open projects.
If only it were that easy.
I've seen codes of conduct for technical projects where they said things like "MUST be inclusive of trans, gay, etc.", along with political / ideological statements. And the kicker was a phrase saying "these ideologies are not open for discussion".
Why a software project needs an ideological statement, I have no idea. But it hits all of my red flags that the purpose of the code of conduct is not to treat each other with basic decency, but instead to push a particular ideology.
> you'll be ejected from the pub if you harass the other clients.
What about simple questions?
Q: Hi, I noticed you're a Democrat / Republican / whatever. I think I may disagree with your opinion.
A: THE SIGN SAYS NO QUESTIONING IDEOLOGICAL PURITY. GET OUT.
Uh... no. That way lies totalitarianism.
Any selection of relative values is ideological; and every project is, inherently, based on an agreement to pursue some set of values. And the choice for those values to not include social inclusiveness is as much an ideological choice as the decision that the values should include inclusiveness (or that they should include exclusiveness, which is a third possible ideological choice.)
e.g.
> ... an ideological choice as the decision that the values should include inclusiveness
I explained why this is not just unnecessary, but also why it's wrong on a much more fundamental level.
When I get patches from people, I don't care what's under their clothes. I don't care what their political opinions are. I don't care what religion (or not) they belong to. I evaluate the patch based on it's engineering merits. I give them a review of the engineering work that they did, without reference to any of the above mentioned issues.
It's absolutely inclusive, in a way that perhaps you don't understand. It doesn't pervert the project by demanding that members adhere to a particular ideology.
I find naive attempts at "inclusiveness" to be repugnant. They are a back-door way of leveraging such "niceties" into taking over the group, and establishing an ideology-driven totalitarian dictatorship with Orwellian overtones.
And no, I'm not exaggerating here. Look at any number of groups which started out as goal oriented, and devolved into fights over ideological correctness. Very soon, the arguments over ideology overwhelm the group, and everyone who gets things done... leaves. What's left is the ideology-driven politicians, who then find out that they're in their an echo chamber. They turn on each other, and the group dies a flaming death.
See Atheism+ for a good example of this in recent years.
And yes, treating other people with basic decency is actually a tricky thing that needs to be spelled out for some people. A lot of people actually - you gave some great examples, whether you meant to or not.
There is also the opposite, people who are busy communicating, who generate lots of noise and never do anything.
So yes, merit should be defined as getting useful things done with rough consensus and not as brilliant code that then split the community.
Being socially dysfunctional (as opposed to being malicious, which is a different problem) is often linked to an inability to pick up the social cues and clues that most people take for granted. A document which clearly explains and gives examples of unwelcome behaviour should help in these cases - assuming people actually read it!
Example: Wikipedia. The talk pages on that site, especially on politically charged topics, are detailed examples in how one can behave in a destructive fashion and drive off talent without ever dipping into base namecalling.
The question is "who judges" ?
A meritocracy is generally an engineering meritocracy. People who get things done, get more merit. And it's easy to judge who gets things done. No one cares if the contributor is black, blind, gay, trans, politically left or right. They're doing engineering. All other topics are off topic for the engineering project.
In contrast, "inclusiveness" is a vague concept. It's hard to judge "inclusiveness". So when the judging happens, it tends to be subjective, and driven by politics, ideology, or emotion.
This subject came up on the FreeRADIUS list last year. I made similar points here:
http://lists.freeradius.org/pipermail/freeradius-users/2016-...
I am actively opposed to most "codes of conduct", for reasons stated in the link.
From the main web site http://freeradius.org/list/
---
All mailing lists have a strict code of conduct:
The only permitted topic on the list is technical discussion related to FreeRADIUS.
Off topic messages will result in a warning. Continued misbehavior will result in the person being unsubscribed from the list, and permanently banned.
This code of conduct was defined after many years of experience running the list. It is simple to explain, and simple to enforce. Unlike other codes of conduct, it does not require people to be "inclusive" or "accepting" of certain topics. It requires people to be blind to non-technical topics, as those subjects are explicitly off-topic.
---
Such a "code of conduct" is easy to explain, easy to enforce, and easy to judge. No politics, ideology, or emotion get in the way of people doing engineering.
So, much like with debates over communism, I think we end up with a major disconnect between people who focus on love for the ideal and people who focus on hate for the implementations they've seen.
Seems like it should at least be an amicable goal.
There's also the fact that the participation of women and minorities in OSS is smaller than their participation in the technology industry as a whole. Granted, not every OSS project touts itself as a meritocracy, but it's probably the area where the concept is championed most vociferously.
I think that can mostly be diversity hiring. A company can hire women/minorities to increase diversity. A FOSS project can't accept code on the premise of diversity. I think the narrow scope of most FOSS projects (or the individual components that contributors wind up specializing in) also makes most of the benefits of diversity less relevant. Diverse teams do better on diverse tasks.
(I don't think diversity hiring is a bad practice as long as the people hired are qualified for the job)
No good way to know by speculating.
Unfortunately, the technology world has not had the same experience. When technology becomes more meritocratic (e.g., audition via github/coding tests/open source contributions rather than interviews), we get more Asians, fewer non-Asian minorities and fewer women.
Because meritocracy in technology fails to achieve the goal of "gotta catch them all", it must be opposed.
> When technology becomes more meritocratic (e.g., audition via github/coding tests/open source contributions rather than interviews), we get more Asians, fewer non-Asian minorities and fewer women. Because meritocracy in technology fails to achieve the goal of "gotta catch them all", it must be opposed.
This seems to suggest that you don't want meritocracy. Was that sarcasm?
I don't think meritocracy (at least in tech) helps promote "diversity" (where diversity is a code word for "women and non-Asian minorities"). (The latter claim is broadly supported, albeit in convoluted language, by the social justice types who oppose meritocracy.)
I'm perfectly fine with this; "gotta catch em all" is not one of my goals. It is, however, the goal of many social justice types, so they necessarily oppose meritocracy.
I think there are two factors at play:
* Generation and exchange of ideas and approaches is the most important part of software engineering on a team. Diversity of gender and background probably gives this factor a bump.
* People are biased, both consciously and unconsciously, against certain minorities. This means lower evaluation scores and weaker resumes (since the world shares the bias).
But whatever the reasons, Google and Facebook are pretty good at this whole data analysis thing, so I wouldn't discount their experiences.
Here's a hypothetical. Imagine google made an error and it turns out that their analysis has a sign error. Blacks/women actually underperform. Would you favor flipping the sign on whatever action you propose? If not, why not?
I ask this because in a number of other contexts, the sign is actually flipped. Blacks drastically underperform what would be predicted from college entrance scores, they are less likely to pay back loans (holding other things constant), and more likely to commit crime.
Generation and exchange of ideas and approaches is the most important part of software engineering on a team. Diversity of gender and background probably gives this factor a bump.
I'm the only person of my race/nationality at my current company, but I've never really observed this effect. Can you tell me how to tap into these powers?
I admit, I do sometimes provide ideas that no one else has, mainly in the area of bayesian stats, low level performance hacking and probabilistic data structures. Is that what you mean? Are these the secret powers unavailable if you don't have someone of my race?
No, because of the above point about diversity. It has an effect on more than just the individual. I don't know if Google has made any claims about the following, but it's been noted that, for example, diverse management teams tend to outperform nondiverse ones.
> I admit, I do sometimes provide ideas that no one else has, mainly in the area of bayesian stats, low level performance hacking and probabilistic data structures. Is that what you mean? Are these the secret powers unavailable if you don't have someone of my race?
You are being intentionally facetious. I know you're a smart person, that you're very probably aware of what diversity arguments are about, and this reply is thoughtless in a disrespectful way. I'm only spelling it out to avoid downvoters: the idea is that different approaches and attitudes are informed by race, culture, background and gender in ways that are difficult to measure in the interview process.
For the record, I would consider a white hillbilly or southerner as 'diverse' in most computer workplaces.
That point does not apply to lending or crime prediction. There is no collective decisionmaking on the part of parolees or borrowers.
Do you have any objection to using your same solutions, but with the opposite direction, in this areas? E.g., if google should try and hire more blacks (due to them overperforming), should BofA try to lend less money to them (because they underperform)?
Similarly, since we know diversity harms group cohesion, should companies which value group cohesion avoid it?
You are being intentionally facetious. I know you're a smart person, that you're very probably aware of what diversity arguments are about, and this reply is thoughtless in a disrespectful way. I'm only spelling it out to avoid downvoters: the idea is that different approaches and attitudes are informed by race, culture, background and gender in ways that are difficult to measure in the interview process.
I don't know why you find this disrespectful. Could you clarify?
I'm simply asking, concretely, how "race, culture, background and gender" inform different approaches and attitudes to detecting systematic failures in a sensor network? Or similarly, how does this inform different approaches to querying a dataset consisting of a normalized SQL schema together with a collection of very large structured files?
I'm being facetious because I consider this idea to be patently ridiculous. In most of my jobs I've been the only person of my race present, and it's literally never affected any professional task.
That's also why I'm asking for specifics, rather than vague allusions to some study you kind of remember reading.
I do of course know what the real argument is about. Diversity is a sacred value and all the arguments you've brought up are actually just post-hoc justifications for a behavior you virtuous. I'm just arguing that there is little more than that.
It's popular among computer nerds to dismiss other peoples' ideas. They might do something like attack someone's ideas with intentional misunderstanding, lazy thinking, and facetious reasoning. In short, they do not show the bare minimum of consideration for others' ideas, instead looking first for avenues of attack. Having ignored and attacked the other person, they then claim no disrespect was meant. They might say something like "I don't know why you find this disrespectful. Could you clarify?"
It does not occur to them that being able to attack peoples' ideas in this pompous way is actually a position of privilege. Anyone can do it, but people born a step ahead are more likely to not reflect on their position, or even feel entitled to it.
In my experience, women and people from disadvantaged backgrounds--people who were not praised to the moon for writing "Hello World" in eighth grade--are less likely to behave in this way.
This is self-evidently an enormous advantage on engineering teams.
Usual disclaimer: personal experience, your mileage may vary, this is just one example, privileged backgrounds have advantages too, yada yada yada.
On the contrary, the only person ignoring the other's points and making anything close to an attack is you. You've accused me of being disrespectful, called me lazy and accused me of intentional misunderstanding, while simultaneously NOT addressing any of my core arguments.
Quite entertaining, I must admit.
[1] Specifically, I think even if that argument could be proven false, it would not change your conclusion at all. So bringing it up is merely a distraction. See also: http://lesswrong.com/lw/wj/is_that_your_true_rejection/
If you're interested in Google's data, they make an excellent search engine that you can use to find that kind of stuff. I encourage you to do your own research, in part because I think I've done enough work leading you to the proverbial water.
In general I would agree that woman and blacks do have different experiences in life to most people in Silicon Valley. I fear that the push to improve 'diversity' will actually reduce true diversity. Companies in Silicon Valley usually hires people from the same universities who all have similar experiences. This crowds out the hiring from less famous universities, overseas students and other parties. There are no vocal activists to push that kind of diversity.
I still think we as a community should be open to all to participate. But we shouldn't have to lose what makes our community great in the process.
I don't know about you guys, but I don't care about the race, religion or sex of the other parties I work with. I only care about the quality of their work and that they aren't arseholes to be around.
Blind coding tests would come the closest to the equivalent of a blind audition, but coding tests as hiring criteria have their own problems in general.
A non-peer-reviewed paper shows that women get more requests accepted than men. In one subgroup, unblinding gender gives women a bigger advantage; in another subgroup, unblinding gender gives men a bigger advantage. When gender is unblinded, both men and women do worse; it’s unclear if there are statistically significant differences in this regard. Only one of the study’s subgroups showed lower acceptance for women than men, and the size of the difference was 63% vs. 64%, which may or may not be statistically significant. This may or may not be related to the fact, demonstrated in the study, that women propose bigger and less-immediately-useful changes on average; no attempt was made to control for this. This tiny amount of discrimination against women seems to be mostly from other women, not from men.
http://slatestarcodex.com/2016/02/12/before-you-get-too-exci...
Most of the results of that study suggest open source is friendlier to women than to men. But the study isn't really that high quality, and the results aren't that strong, so I wouldn't draw a very strong conclusion from this.
When that study came out I asked the authors for their data set and analysis scripts. They categorically refused. Also not a strong indication of quality.
Important free Software and Open Source projects are almost always community efforts. Ignoring bad behaviour which harms the community may have technical benefits in the short term (assuming the people behaving badly are skilled hackers), but in the long term their contributions may not be worth the harm they do by excluding and driving away other potential contributors.
A hostile work environment is rightly considered a problem that needs to be fixed in a professional context. For those of us doing FOSS as a hobby, it's even more important - few will spend time on a hobby where they are treated badly.
I also like the meritocracy concept. But I feel rather strongly that it is important that the "metrics" are not just technical, but social as well.
At what point do you deem social behavior unacceptable? It's a fine line to draw and one that might be difficult for many communities to do correctly.
What's considered "harassment" for example? Does 1 off comment count or does it need to be systemic? What if it was a heat of the moment situation and an apology was made afterwards? Does expressing an opinion less than the generally accepted one about a rape case for example count as misogyny? What about mental health comments not in line with generally accepted opinions, but which might still hold some validity? How about defending political opinions based on your religion?
There are too many questions that I know many people would respond very differently to.
I think if we take a step back and don't try to invent all the wheels ourselves, we'll find that almost all of these questions have established answers from the world of business and human resources.
We do have to get past the first step though, which is agreeing that these are problems we care to solve. The wider community is still divided on that, as illustrated by this thread and the comments on the OP.
Yet conspicuously absent in your post is a link to where those answers are. I suspect that because as soon as you link to one you've actually drawn a line in the ground. Instead of codes of conduct which sort of fuzzily describe that one exists "out there."
And once you start talking about where lines are really drawn, it becomes easy see how little agreement there actually is. Even among people that are more-or-less on the same page regarding which problems "we" care to solve.
But I do know people that do that sort of work, and I also know that when I went looking for a code of conduct for my own project, I found lots of pre-existing material to work with.
You guys are making this out to be a lot harder and more complicated than it actually is.
Often times this amounts to "don't be racist" and similar proclamations - these don't offer guidance as to what's deemed racist. Some people would say opposing affirmative action is racist - is that the standard the project goes by? Based just on those codes of conduct, who knows?
Heck, some people would say the president of the united states is racist, but over 47% of the voters wanted him. If you think that full 47% of the population is terrible and racist, on sheer population grounds you probably just rejected a lot of good people.
This is why I find codes to conduct to be extremely low value, they provide nothing beyond say "don't be an asshole" and a fear of reprisal for political reasons.
It's entirely possible to be racist to some degree while still being a good person overall. That doesn't mean racism is okay, or that it should be acceptable. But suggesting that opposing racism equals branding almost half of the American voters as terrible people is a strawman.
My point is, if you use a code of conduct that simply includes dumbed down provisions with no detail, you have no way of knowing what the views of the project leaders are - you might have risk that kind of treatment because you said something positive about Trump on Twitter.
I suppose you can argue this is a strawman on the grounds that it doesn't seem to be happening so far with projects which have implemented a code of conduct - but I'm worried it might have a chilling effect on political commentary in FOSS communities, causing more people to comment anonymously and disassociate their political views from their real information. This kind of chilling effect is hard to measure in many other cases already.
This is key. A large part of contemporary American (and, as I understand it, European) politics involves struggles over the size of the Overton window. This means that even people with little interest in the project will have a strong incentive to use the project's code of conduct as a tool for defining the boundaries of acceptable discourse in the communities that overlap with the project.
Nothing in this article makes me want to change my mind. On the contrary seeing this article on a 'Linux' website generally lowers my opinion of both the 'Linux Community' and LWN. If LWN had fewer articles like this, and more articles actually communicating useful information to me, I might actually read it more.
I used to use Debian almost exclusively, but ever since this systemd BS I've gone FreeBSD as much as possible. This isn't about personalities, it's about me not caring about the problems that systemd is trying to solve.
The comments… yeah, there are people whining about "Marxists" "ruining projects" or something. Welp.
My only gripe is we're still waiting for KDE Plasma 5...
Another FreeBSD developer here. I pay for an LWN subscription to help keep on top of what's happening in Linux and to support the high-quality coverage.
I can understand it, I can edit it, I can fix it. IMO systemd and the like are too much like hand-waving voodoo.
It's like trying to interact with an adolescent AI: Computer run service abc123
I don't feel like it.
With config files: Computer run service abc123
Error on line #5 of abc123.conf
Bingo!
I wish they had just named systemd as HAL. It would have let me avoid months of hair-pulling.
There's already a HAL https://en.wikipedia.org/wiki/HAL_(software)
It's deprecated since its functionality was merged into udev. Then udev was merged into systemd...
=) It's jokes all the way down.
None of it was meant to discourage you from using FreeBSD. I had nothing to do with the LWN summary but the whole point of the piece was to look at what FreeBSD could be doing better from a community standpoint.
A case in point: Baptiste Daroussin wrote up documentation for EVFILT_FS in kevent. FreeBSD actually has had this for a decade, not that one would know it from the doco (because contrary to the norm the code was patched without amending the doco to match). This was in 2010. The doco patch was never actually added.
* https://lists.freebsd.org/pipermail/freebsd-current/2010-Sep...
There's nothing about EVFILT_FS in the 11.0 kqueue() manual.
Don't get me wrong, I love FreeBSD, but some of the effort and friction is unnecessary.
Thankfully for those of us unwilling or unable to make the jump to FreeBSD there is still Slackware.
As a occasional reader of LWN, I like the fact that they cover other topics apart from LWN. It's always good to learn/see how other communities operate.
The fact that some woman wants "FreeBSD" to police the Internet (not just the official FreeBSD communications channels) is a red herring. Ignore her.
Well, even in the worst case where FreeBSD community is trash, they have one of the best kernel implementations and one of the best open source OS documentation.
Let's remember that FreeBSD is an entire OS, not just a kernel. If you want to compare it to the linux world you have to imagine the kernel + the GNU userland + the distro specific utilities and package management of something like debian or red hat.
It's not really surprising that the codebase ends up being huge and that you can't just change the architecture and tooling around it to use the trending software stack of the day.
On the other hand the fact that FreeBSD is so comprehensive is the killer feature for me when compared to something like Linux. It's a full OS, with everything (usually) playing nice with each other, a single documentation for the entire base system etc...
I also find that the kernel code is generally a little nicer than linux's, although linux is more featureful overall.
Yes, FreeBSD is slower moving than Linux and generally more conservative. That's not a bug, that's a feature.
The whole idea of this talk was about the community side of the project. I make exactly the points you're making regarding code size but that just speaks to the difficulty of managing a community looking after a codebase of that size.
I'm also not criticizing the pace of FreeBSD development so much as I'm criticizing the pace of its leadership (of which I'm a member, don't forget) to deal with issues that would make FreeBSD more fun to work on.
There are three main points in this article: the issue of version control, the "Dragonfly BSD incident", and the GamerGate garbage fire.
Regarding the first issue, while it was sad to see a good dev like Matthew Dillon leave the project, what do you think should have been done better by the leaders of the project? Clearly there was an incompatibility here, maybe having Dillon work on his own project (and then sometimes have a back and forth between Dragonfly and FreeBSD) was the right solution? Would Linux for instance have dealt with the issue better? I recall many personality clashes amongst the Linux "elite", some not so long ago.
The migration away from CVS sure did take a long time, but as you mention yourself the technical challenge was pretty high. Lest we forget, Linus ended up writing his own version control system because the existing solution were not deemed satisfying. And FreeBSD is significantly bigger than linux's codebase. Regarding the test suite, testing operating systems is notoriously difficult (you can't easily abstract away from the hardware to run well contained unit tests). I don't recall Linux having an extensive test suite either.
The GamerGate thing I won't touch with a hundred kilometer pole. How an operating system project got dragged into that I still can't fathom.
So in the end, I don't think those issues are that big of a deal on their own. IMHO the main "trouble" with FreeBSD is simply that its market share is tiny compared to Linux. I'm a big fan of FreeBSD but my IRL job is linux kernel dev, not FreeBSD kernel dev. More and more first party vendors support linux, not any of the *BSDs. "Netcraft confirms it - BSD is dying". There's a momentum problem and I'm not sure switching to github or adding a test suite are going to solve it.
FreeBSD is betamax, linux is VHS. FreeBSD is mercurial, linux is git.
That being said, I don't have a solution either.
If you think it has a small market share, you're looking at the wrong market.
1. Linux. "Over 13,500 developers", https://www.linuxfoundation.org/announcements/linux-foundati...
2. FreeBSD. I make this a little over 2,300 names: https://www.freebsd.org/doc/en/articles/contributors/article...
So I suggest it is a only a 6x difference, or at least in that vicinity.
I imagine that the column inches go overwhelmingly to Linux, but tech journalists are moths to a flame.
https://svnweb.freebsd.org/base/head/ -- 128 individual developers have committed to FreeBSD head in the last ~ten week window. (svn log http://svn.freebsd.org/base/head |egrep '^r[0-9]{6,6} \| ' | grep -B999999999 2016-11-25 | cut -d" " -f3 commits.log |sort | uniq | wc -l)
So Linux has more like 13x individual developer count in recent times. You can round that down to 10x if you like, but 6x doesn't tell the recent story.
Note that this is comparing the Linux kernel to FreeBSD base, which is like kernel + glibc + coreutils + binutils + other stuff.
The migration to Subversion was given as a case where core could've made a decision and given direction but chose not to. Whether they're right or not is a whole separate set of arguments.
I think everyone would be happier if Gamergate had never been a thing.
The trouble with FreeBSD, as stated, is that like a whole lot of other community projects it's largely volunteer and its leadership is 100% volunteer. If we had more mindshare we might have more volunteers but then we'd need leadership to be more active.
I would rather prefer 'moving slow and preserving things'. Any body here remembered how things went when Linux moved from OSS to ALSA? And now there's this systemd.
Speaking as a python user, I guess your way of development is then to still code everything in C and sh? No thanks. I'm willing to update my code to newer, less insane, versions of a language - if the benefits outweigh the pain of course.
Python is usually considered the one language that moves slowly, exactly to preserve compatibility. Can you explain why you "never went back to it"?
How does the choice of VCS make a difference for your personal projects using Python?
If they achieved another gain by migrating to HG, why shouldn't they have ?
If they achieved further gains by migrating to git, why shouldn't they have ?
I don't have Python2 code to maintain, but if I had I would seriously consider updating it. Because I think the changes are reasonable for the most part.
Dou you write your C code in GCC C? Intel C? Microsoft C? C89? C99? C11? What libraries and what versions do you use?
In the face of all the great things happening in Python during 2004 and 2005, why would you abandon it due to a change in their VCS, especially when SVN is so similar to CVS?
Anyone have more info about this? Especially the "Perl script"?
https://github.com/freebsdgirl/ggautoblocker
I wound up adapting the script myself at one point to mass-block followers of a YouTube/Instagram celebrity who shares my first name and triggers a neverending stream of namespace collisions. It's a reasonable brute-force hack in an environment that lacks real features for dealing with a large population of griefers.
I suspect a lot of open-source projects have similar issues.
The original proposal was this: https://wiki.php.net/rfc/adopt-code-of-conduct?rev=145194062...
As with all constructive criticism, you absorb what you feel will help you reach your goals, and reject what doesn't. It is always a good thing to have those insights and options though, I think.
Since Dillon was discussed in the article and given he split from FreeBSD 11 years ago ... which OS now is in better shape overall (technically)?
DragonFlyBSD or FreeBSD?
I also don't really consider "age" in and of itself to be a real factor at all here anyway. It implies (probably not intentionally, but the implication is there nonetheless) that things should be rewritten from scratch all the time in order to avoid "old" things, which would be silly.