gay robot noises

An elegy for GNU and RMS

Assorted thoughts about rms, the GNU project, the FSF, and the future.
date:
2326 words
BROKEN ICON

NOTE: I'm explicitly not going to address all the events that led to rms resigning and then rejoining the FSF board. I certainly do have opinions, but I want this piece to focus entirely on a technical/leadership perspective.

I'm also going to talk a lot about emacs here because that's the GNU project that I have the most complaints about. To establish my Cool Kid Credentials, I've been using emacs both in my hobby work and professionally since about 2010 or so. First using a hand-rolled configuration, then Spacemacs for a while, and then finally back to a hand-rolled one using some of the packages I discovered via Spacemacs.

ADDED, 2022-10-01: Hello, Hacker News! Totally putting this on my resume. Some comments at the bottom.

the cost of principle

RMS is nothing if not a man of principle. He really, truly believes in his ideas of software freedom in a way that I really do think very few people believe in anything these days, and nothing in this essay is meant to disparage those beliefs. And for the most part, I agree with those ideas; I think the growth of proprietary software everywhere has been a terrible thing.

But I don't think he's an effective advocate for those ideals. Standing in the road to be a roadblock against the forces of proprietary software does nothing when those forces can just drive around you. The free software movement lost in a very thorough way, but from the way the FSF and RMS act, you'd think it's still valiantly fighting the good fight. And I'd rather have a flawed but effective advocate than a principled but ineffective one.

This post about the FSF's "Respects Your Freedoms" program explores how this winds up undercutting the FSF's own goals: their insistence on an all-or-nothing approach to hardware that "respects your freedom" resulted in them undercutting their own goals.

emacs and the gcc AST

I think the thing that best represents my frustration with the leadership from RMS (and by extension, the GNU Project and the FSF, given how thoroughly the three of them are interlinked) is what happened when an emacs dev wanted to add C++ information to emacs via the AST. A summary:

From here, the project bogs down, and was eventually abandoned.

Of note is that this is all from 2015. A year or so later, the Language Server Protocol was standardized (in part due to large work from Microsoft, of all organizations), and it's led to a revolution in how we think about language editor support. And both ccls and clangd are based on clang.

This sort of thing is why I think rms is fighting a battle that no longer exists. If someone wants to have a proprietary compiler but doesn't want to parse C++ (which is, by far, not the hardest part of writing a compiler), they wouldn't use gcc in the first place. They'd use clang, because part of its entire design motivation was to be modular and extendable.

One of the most salient bits of that whole AST discussion is that RMS does not in fact know about operator overloading, and in fact has never used C++. This isn't a vice in and of itself, of course. The principles of software freedom aren't tied to any programming language. But if you're trying to make decisions based on your understanding of what information is necessary to analyze C++, I would expect at least basic familiarity with C++.

garbage collection and word processing

Another thread that really illustrates my issues is one about Emacs's GC. I won't pretend I know enough about language design and garbage collection to say whether or not Daniel's proposal here is good. Maybe it is, maybe it isn't. My complaint here is about RMS replying to the thread by saying that it would actually be more important for emacs to be a better word processor, and that improving the GC performance would only "permit some operations on larger problems than now".

When told that someone doesn't think word processing in emacs is not a good focus, RMS replies "please stop interfering". The irony here, of course, is that the thread was originally not about word processing, and to the best of my knowledge RMS doesn't contribute much code to Emacs these days (if any).

This is, frankly, nonsensical to me. You can use this argument to apply to any performance optimization! Not only that, but there are some tasks that are so important that the code for them is written in C, not because it's difficult, but purely for performance reasons. The support for libgccjit (just-in-time compiling elisp to bytecode via GCC) that landed in Emacs 28 has been one of the biggest performance improvements I've seen in the decade-plus I've been using Emacs, and before that the support for parsing JSON in C was essential for using LSP servers (which generate a lot of JSON).

But RMS's reply a bit downthread really sums up RMS's attitude towards not only Emacs, but the GNU Project as a whole:

Emacs is not an independent project, and it isn't governed by its contributors. I'm the head of the GNU Project, and that includes Emacs.

You, as a contributor, can advocate a certain decision, which means you present arguments why I should approve it. I don't need to advocate a decision in that sense.

I leave most technical decisions up to the contributors, including you, because for most of the questions I don't have any special preference of my own. For those questions, I'm happy with whatever works, and I know the contributors can figure out what works.

However, making progress on Emacs as a word processor is one of my specific goals. This is what Emacs needs to do to be useful in all the ways it should be useful.

For RMS, the priority of Emacs is not creating the best text editor in general; it's creating the best text editor according to RMS's interests. I don't intrepret this as him explicitly saying "no, I would not approve merging GC improvements"; I don't think he's ever blocked a feature for reasons as petty as "I don't think this would be useful" (as opposed to more principled reasons). But I think this speaks to a sort of "benevolent dictator" attitude that I don't think is useful for the project.

fighting the previous war

There's a saying that generals always fight the previous war. I'm not a military historian, so I can't say how true this is. But I think the FSF is absolutely fighting the free software war of the 80s. The requirement to assign copyright to the FSF for enforcement purposes doesn't make sense in a world where megacorporations that want their own editor they can control have enough resources that they can just write their own. Insisting on not adding functionality because someone evil might use it is pointless when the evil people have enough budget to just write their own compiler.

And RMS has even had some concessions to these practicalities; Vorbis Beta 4 relicensed from LGPL to BSD with RMS's approval:

It is wise to make some of the Ogg Vorbis code available for use in proprietary software, so that commercial companies doing proprietary software will use it, and help Vorbis succeed in competition with other formats that would be restricted against our use.

and yet...

And yet, I still use Emacs. I'm writing this post in it. I'm probably going to go through the FSF copyright assignment process at some point (which has been digital worldwide for a few years and digital in the US for a few more) since I may want to contribute to eglot or dash.el, both of which require FSF assignment so they can be distributed with Emacs proper. I wasn't sure about this for a while, but then I thought about it like this: I'm fine with using React for my personal projects, and I'd be fine with contributing to it, despite the fact that I think Facebook (the product, and the company formerly known as) has done orders of magnitude more harm to the world than even the worst possible accounting of the FSF.

And of course, emacs still exists, and is generally usable for modern software development, text authorship, and so on. Emacs is going to have built-in LSP support soon with RMS's approval, and he in fact stated he tried to convince the GCC maintainers to add LSP support. I said this in the opening, but I don't think RMS is a cranky old man that hates progress because he is compelled to do evil, regardless of its utility. But I think his principles are getting in the way of progress, and that's true regardless of the cases above where he was willing or even supportive of things that I think are good for the project as a whole.

In my opinion, the best way forward would be for RMS to step down from his leadership roles and hand over those positions to people who are capable of a more modern approach to these projects. I'm not sure who those would be, but I'm sure there are good candidates. But I'm not under any illusion that this post will convince him to do anything; I'd be surprised if he or any of the people with any influence even read it (edit to add: I'd be surprised because I'm just some random person with a blog, not because I think the relevant people wouldn't read this post if they're made aware of it!)

So why write this? To complain, mostly. This is something that's been weighing on me for a while, especially as I think about the future of Emacs (which I think is a separate post on its own; the TL;DR is that I want to be able to continue using Emacs for another decade, and that requires having enough of a userbase that I don't have to write all the functionality I want myself).


responding to HN

This section added 2022-10-01 22:25 PDT. I don't use Hacker News myself, and rather than effectively leave part of this post in the comments section of an unrelated website, I thought it'd be good to address points here.

bus factor

Volundr says:

If nothing else, there needs to be a clear concession [sic; succession?] plan ASAP. One refrain I kept reading when he came back to the FSF was that we needed him back because no one else could lead this movement. Really? No one? In 36 years since the FSF was founded it hasn't managed to attract a single individual with the sufficient combination of motivation, morals, and skill to replace Stallman? If that's not the definition of failure I don't know what is.

The man is 70 years old. Decent odds they'll be doing without him sooner than later.

This is a very good point, and one I wish I'd thought of. The biological reality of these squishy fleshbags is that sooner rather than later, RMS will be unable to lead. And given everything, I suspect that will happen within a couple decades. I also very much do not think that free software will have won by then, which means that the movement will need someone to continue to do the work after RMS is gone.

As software developers, when we work on projects, we try to maximize the bus factor: how many people would need to get hit by a bus/h before the project effectively falls apart. If RMS truly is irreplaceable, then it means the free software movement has a bus factor of 1. This is not a good situation to be in, and insisting that he's a vital piece of the movement that can't be replaced is a bad thing.

RMS has done a lot of good work in the past. Emacs wouldn't exist without him, of course, and a large part of the GNU suite is based on his own handiwork. And I don't think that RMS is the only reason the free software movement has failed; there are a lot of issues at play here. But you can't be a leader based on past results; you have to continue to deliver.

compromise

Several people said comments to the effect of "it's important that the FSF stay uncompromising since they're the only organization that stakes out such an absolute stance".

I'm not asking the FSF to change its mission to include things like racial inequality in tech, or climate change, or social issues in tech, or whatever. I'm not saying the FSF's goals aren't worth pursuing; I'm saying the FSF is ineffective at achieving those goals. You can use only hardware that Respects Your Freedom, and use a browser extension to block nonfree JavaScript, and so on. I'm sure RMS himself lives a life as close to his ideals as humanly possible. But most people don't.

// α-5/h