The FSF does not represent my views

Earlier this week, Richard Stallman announced that he was rejoining the board of the Free Software Foundation. You may recall that he resigned as president and board member in 2019 after making unacceptable remarks about the sexual assault of a minor. This was not the first instance of unacceptable behavior. The FSF made no real changes to address the issue and now has welcomed Stallman back.

I’m thankful that the people I choose to associate with have universally condemned this as harmful. I wrote in 2012 that I think he hurts his own ideological cause. At the time I wrote the post, I was thinking entirely of his rigid aherence to free software over all else. In truth, the harm he does goes well beyond that. For me, the licensing terms of free and open source software are not as important as the human impact.

As I wrote last month, free and open source software is not the end goal. What good is free software that is used to harm others? And what good is a free software movement that is not willing to include underindexed groups. We cannot tolerate nor enable this sort of behavior.

The Fedora Council spent a lot of time debating our vision statement.

The Fedora Project envisions a world where everyone benefits from free and open source software built by inclusive, welcoming, and open-minded communities.

Fedora PRoject vision

The inclusion of the “built by” is no accident. We want our community to be vibrant and healthy. That cannot happen when bad behavior is allowed to persist.

I think it’s too late for the FSF. They’ve painted themselves into a corner long ago. This only cements that. Still, perhaps with a new slate, the organization can be reborn into something that aids the cause it purports to champion. That is why I have signed the open letter calling for the resignation of Stallman and the entire FSF Board of Directors.

If you want a diverse community, you have to stand up for marginalized members

On Monday, The Perl Conference’s Standards of Conduct Committee published an incident report. In a talk at the conference, a speaker deadnamed and misgendered a member of the community. As a result, they took down the YouTube video of that talk.

The speaker in question happens to be a keynote speaker at PerlCon. The PerlCon organizers wrote a pretty awful post (that they have since edited) that essentially dismissed the concerns of the transgender members of the Perl community. They went on to mock the pain that deadnaming causes.

I did not think to save their post in the Wayback Machine before they edited it down to a brief and meaningless statement. “We are preparing a great conference and do not want to break the festival and trash our year-long hard work we did for preparing the confernece, the program and the entertainment program.”

What they don’t say is “we value the marginalized members of our community.” And they make that very clear. Editing out the insulting part of their post does not ,mean much, as VM Brasseur pointed out.

https://twitter.com/vmbrasseur/status/1148674272350494720

If you value an inclusive community, you have to stand up for the marginalized members when they are excluded. If you don’t, you make it very clear that you’re only giving lip service to the idea. As it is, the PerlCon organizers don’t even apologize. They’re more concerned about the bad publicity than the bad effect on the community.

Inclusion is a necessary part of good coding

Too often I see comments like “some people would rather focus on inclusion than write good code.” Not only is that a false dichotomy, but it completely misrepresents the relationship between the two. Inclusion doesn’t come at the cost of good code, it’s a necessary part of good code.

We don’t write code for the sake of writing code. We write code for people to use it in some way. This means that the code needs to work for the people. In order to do that, the people designing and implementing the technology need to consider different experiences. The best way to do that is to have people with different experiences be on the team. As my 7th grade algebra teacher was fond of reminding us: garbage in, garbage out.

But it’s not like the tech industry has a history of bad decision making. Or soap dispensers not working with dark-skinned people. Or identifying black people as gorillas. Or voice recognition not responding to female voices. What could go wrong with automatically labeling “suspicious” people?

I’ll grant that not all of these issues are with the code itself. In fact a lot of it isn’t the code, it’s the inputs given to the code. So when I talk about “good coding” here, I’m being very loose with the wording as a shorthand for the technology we produce in general. The point holds because the code doesn’t exist in a vacuum.

It’s not just about the outputs and real world effect of what we make. There’s also the matter of wanting to build the best team. Inclusion opens you up to a broader base of talent that might self-select out.

Being inclusive takes effort. It sometimes requires self-examination and facing unpleasant truths. But it makes you a better person and if you don’t care about that, it makes your technology better, too.