Mozilla finally disavows Discord

mhoye’s new blog post on the future of Mozilla community chat came out last week. He notes about Discord that “their active hostility towards interoperability and alternative clients has disqualified them as a community platform.”

I am very thankful that the Mozilla brass have realised this, as I pointed out in an earlier installment. Kudos to them that three of their four options are fully libre — I sincerely hope they choose one of those three, and keep the Mozilla community libre and open.

The state of FLOSS and the tech industry

I’ve read an article today, in ZDnet, mourning how desktop distributions seem to wax and wane. It really made me think about how to properly convey what I feel to be the root issues with desktop adoption of Linux (and the wider CS industry), and why I think most people are very, very wrong about it.

Most people, normal people, they do not care about shiny. They don’t care if their email client or word processor is written in C++, Rust, JavaScript, Python, Ruby, or FORTRAN. They just want something that is simple to use and allows them to accomplish their tasks. It feels like most programmers and designers have lost that concept. I’ve met people in this industry who thought that they could sell people their products based on metrics like memory usage and number of packets transferred. Very excited people tell me how they use MapReduce and AngularJS and MongoDB and MariaDB (sometimes all four at once), like they deserve an award for Most Use of All Available Frameworks And Patterns Released This Decade. There’s a great article I read recently that puts in no uncertain terms: You are not Google. Even Google isn’t Google. Following these “trends” may make your product seem “trendy” to other developers, but all you are doing is wasting your time while leaving your users under-satisfied. Focus more on your software and how it can help people, and less on how it can help your résumé.

Meanwhile, I’ve seen libre software developers put up on their homepages that they now offer Flatpak images and are very excited to tell you that. Nobody knows what that means outside of developer circles! Do you think your grandparents care that your word processor is available in Flatpak or Snap? Do they even know what that means? In addition to this, Flatpak and Snap are anti-solutions. They don’t solve any real problems; they only serve to create new ones. What if a user or distribution wants to use ALSA instead of PulseAudio? What if a user or distribution uses an alternative to systemd? What if a user wants to use sound from their existing session at all? What about CPU architectures that aren’t supported by all developers, like ARM, POWER, or RISC-V? Focus more on your software and how it can help people, and less on following the trendy new shiny.

My personal hope for this industry is that we gain stronger distributions with better focus, and that developers leave packaging to the distribution packagers. This would allow us to have a few different desktop distributions. Distributions could be working together on a common frameworks, like KDE, while having specific plans and goals in mind. Gentoo and Arch for the tinkerers; Gentoo with more focus on source building, Arch with more focus on a tightly integrated system. Adélie and Fedora for the general public; Adélie with more focus on stability and portability (X11, PPC/ARM), Fedora with more focus on incubating new systems. Obviously there would be distributions that would pop up with unique goals; their work could be integrated later in to a main distribution that is aligned with it.

I feel like this could really be a way forward towards more wide adoption of Linux, on the desktop and beyond. I hope we can work together towards it.

(As a small aside that I wanted to note: I hope “The Year of the Linux Desktop” never comes. I hope that we usher in an Era of the Linux Desktop.)

Speaking with authority

I’ve just spent the better part of three hours arguing on IRC about Let’s Encrypt clients. After speaking with two others, I realised that nobody who I spoke with before knew their facts were facts.

Different people all told me various incorrect information, such as:

  • No ACME client supports doing a manual DNS TXT record for verification bootstrapping until you have an httpd up. (, dehydrated, and certbot all support this.)
  • LE needs IPv4 for the HTTP challenge. (It worked fine for me with an IPv6-only host. I’m not sure which it would prefer if it had the choice between v6 and v4, or if it’d use Happy Eyeballs and connect to whichever responded first.)
  • It isn’t possible to step through the process manually as a debugging aid; you have to rely on your ACME client’s debugging facilities. ( helped a tonne.)
  • You have to be listening for the HTTP challenge on port 80. (The TLS-ALPN-01 challenge type exists which will only ever use port 443 for the challenge.)
  • Critique of how I isolated each service on a separate VM so that they would be more secure, saying it was “over-convoluted”.

All of these people spoke with an air of authority. They sounded like they genuinely knew what they were talking about, and were trying to inform me of the limitations of ACME clients / Let’s Encrypt. Nobody actually knew the answer, but they thought they were right because it fit their experience.

When I speak to people about technology, whether in real life, on IRC, or on a mailing list, I always try to make the limitations of my knowledge clear. Many is the time I have said “I’m not sure if you can do that”, or “I don’t know if X supports Y“. And sure, on occasion I will say “I have never done Y and last I knew X couldn’t do that”. Note, however, that all of these are presented as statements from my hive of knowledge, and not presented as plain facts. The art of communication seems to be lost on far too many in the technology field.

There is no shame in not knowing the answer to something. It is certainly more helpful to say “I’m not sure you can do that”, instead of “you can’t do that”. I almost gave up on Let’s Encrypt and wrote another article on how useless it is, because I was told by people who used Let’s Encrypt that it had all of these limitations that made it seem useless, arbitrary, and ridiculous to me. (Thanks to Rich Felker of musl, and Freeyorp, for setting the record straight.)

Maybe we need a new term for this. “Organic FUD”, since it comes from the community itself? At any rate, I hope that in the future, more people note the limitations of their knowledge up-front rather than sounding authoritative about a subject they know little about.

The problem with “patches welcome” culture

I’m going to tell you a secret.

Most computer users cannot write computer code. (Shock!) This is not anything new, and I would dare say this is not even necessarily a problem that needs to be corrected. In a similar vein, a great deal of first-world citizens use cars daily, but I doubt many drivers would be able to fully rebuild an engine, or even describe the difference between EFI and carburetors.

This is the fundamental flaw behind the “patches welcome” culture, and why some libre open source projects have less-than-ideal user experiences, and some even have communities that most would describe as “elitist”.

While drafting this article, a few people told me that they agreed with the substance but did not like that I was using “patches welcome” to describe the culture. While it is correct that most libre software projects should be welcoming of patches, that is not what this article is about. When these people say “patches welcome”, it is a deflection; they don’t want to put forth the effort to properly maintain their software.

Let’s consider an example of this. In a welcoming environment that fosters participation and communication, a request for a feature from a user typically goes somewhat like this:

User: I would really like to be able to select an entire sentence using a key combination so that I can make the sentence bold or underline without dragging.
Developer: Okay. We’ll add that to the list of features that have been requested. Thank you for telling us!

Sometimes these features take time to add; maybe some will never see the light of day. Nevertheless, the user still informed the developer of the software what they needed, which allows the developers to make better choices about how they approach building the software, and what features to prioritise.

Now, in a project with “patches welcome” culture, the users are ignored or even chastised. I’ve actually seen discussions very similar to the following take place:

User: I would really like to be able to select an entire sentence using a key combination so that I can make the sentence bold or underline without dragging.
Developer: patches welcome
User: I don’t know how to write code.
Developer: Then you shouldn’t ask us for help.

This behaviour undermines what libre software is supposed to stand for. It gives the user reason to go back to using proprietary software, where they can call up Microsoft or Apple and tell them what they want or ask for help when they need it. Even if the proprietary software corporations never add their suggestion, they still feel more connected and respected than they do by this example libre project. This behaviour gives the user no reason to use the software that respects them and their freedoms. Free Software is meaningless if it has no users to use it.

Some may argue that people should be empowered to learn to program, and there definitely is a case to be made for that. However, you really need to consider all the reasons people *would not* want to learn to program:

  • They would rather spend that time with family, friends, or their hobbies.
  • They have learning or mental disabilities that make algorithmic reasoning, logic, or concentration required to program difficult.
  • They have physical disabilities that make programming difficult.
  • They simply aren’t interested.

That last item is especially important. Do you want someone who has no interest in programming – no interest in security, or correctness, or doing things the Right Way (or even the way you want them done) – to commit code to your repository? Are patches really welcome, or are you just deflecting the requests of your users so you don’t have to maintain the software you’ve written?

All people deserve Free Software. Nobody deserves to be denigrated, shamed, or ignored because of their inability or lack of desire to program a computer. My personal suggestion to those who do not want to accept feature requests unless patches are attached is to not publicly release your software. If you do, add a notice stating that you do not wish to be contacted about your software by users, so that they may make an informed decision about the software that they use.