The Perpetual Beta

There is a thought that has been nudging at me for several weeks now, if not months, and it has not bothered me for many years now. At least ten, I believe.

For the first time in many years, I am seriously considering moving my main workstation to Windows.

I have used Windows in all this time. I have even written code for Windows, some of it closed-source, commercial code that many people have touched. But back in 2003 or 2004, when I finally removed that Windows partition, I did it because I genuinely thought FreeBSD (at the time, and later — Linux) was a better system, even for a desktop or a workstation.

I am not too convinced of that today, and after tinkering with Windows 10 for a while it is clear to me that the only things that keep me from switching to it are privacy concerns and muscle memory.

Perhaps the most important factor in this state of affairs is that I have lost my optimism. Fifteen years ago, as today, I did not think there is some mythical victory awaiting us just around the corner. But if you were to ask me if I thought free software applications would be better five years from now, my answer would have been a very emphatic yes. Today, I am not too sure anymore.

Ten Years of Optimism

The first time I had a computer on which I could run Linux at home, instead of using a shell account, was in the summer of 2003. LWN's headlines for those days include such nostalgia-inducing news like the release of Gnome 2.4, Slackware 9.1 and 1.1.

If one were to look at these programs five years later, in the summer of 2008, the progress would have been obvious and radical. Opening a Microsoft Word document with back in 2003 was like playing a rigged lottery; by 2008, the lottery was much harder to lose, and was a good office suite in and of itself, not just something Linux folks use when they can't send plain-text emails.

Outside the large desktop environment projects (and sometimes inside, too), many, many applications have been abandoned. This is the way of things, of course; take a casual stroll among the virtual shelves of the archive and you will find tens of thousands of abandoned applications.

Thing is, though, many of them have never been replaced. A steady exodus of talented programmers towards the web, macOS, and mobile platforms has caused many old, independent projects to remain dormant, and no one seems to have been around to write a replacement. And the way we treat backwards compatibility means that the old programs are not much of an option, either.

Larger projects have often suffered from the opposite problem: they have not been abandoned, in fact, they have been worked upon frantically. KDE, for example, is unrecognizable today; and yet almost ten years after the 4.0 release, properly placing desktop icons was an improvement important enough that it got its own entry in the 5.11 release notes. A feature that has, in fact, worked perfectly well since the first release of KDE 3.0, has been improved so much that it ended up needing repairs — and the repairs are still ongoing. It is still pretty buggy even at the time of writing; unfortunately, my puny QML skills are entirely insufficient to do anything except whine about it.

Going in Circles

This is an accurate description of nearly every major project. Gnome, KDE (and the applications around them), even GTK, Firefox, Grub 2...

There used to be this certainty among us that the next release of anything was going to be better. Maybe buggier, but those get ironed out, that is not a problem.

But we rarely heard of an often-used feature getting removed, or of configuration options being removed. Not all changes were popular, of course. The first release of Gnome 2.0 unleashed not only a flurry of flamewars, but also at least one fork. None of them were successful — whereas MATE and Cinnamon are both successful, long-lived projects, which I suspect will continue to work just fine when everyone will scramble to fix their Gnome desktops when GTK 4 sees its first official release.

I like to call this the perpetual beta. There are projects which, at every point in time, have a least one important module (but usually more) that is beta-quality, at best. Hardly a release goes by without something that worked perfectly fine being replaced with something that just needs a little more work. And when this cycle is finally broken, a few more releases are put out, and then the whole thing gets rewritten.

Of course, whatever it is replaced with rarely works fine from the very beginning (which is true of any kind of software). But by the time when it receives enough fixes that it at least stops crashing — feature parity with the old version is, at this point, something that no one even bothers thinking about anymore — there are many other modules that are just begging for the same treatment.

Of course, this is not true of all applications. XFCE has been steadily getting better since forever; Blender, Python, Emacs (and Vim, I hear, but I wouldn't know...) have all been getting steadily better. But they are becoming the exception, rather than the rule.

Meanwhile in Windows Land

Have you seen what Windows is doing lately?

While we are happy that we can finally place our icons on the desktop in the right manner (or with the right extension...), or that we can set a custom wallpaper for our lockscreens instead of the retina-burning bright blue, things that Microsoft is working on include:

  1. Making your computer better at understanding things that you yell at it, because you have been able to order it around for years now.
  2. Application virtualization.
  3. Centrally-managed (if you want it) 2FA.
  4. Device and Credential Guard to protect against UEFI runtime malware (though I have to say, our defenses are way better).

Now, a lot of people insist that change is necessary for progress, and they are not wrong per se, but not every change is a kind of progress, nor does it necessarily lead to progress. The constant breakage (and the flurry of fixes) are a normal part of a beta, but perpetual beta is not progress.

About Responsibility

Whenever these discussions pop up, they inevitably move into the direction of this is how volunteer-driven projects work, people who work in their spare time don't owe you anything. The latter is certainly correct — in fact, not even people who are paid to write software really owe users anything, since it is not users that pay them.

The former, on the other hand, is debatable. There are plenty of projects that do not work like this at all. And we do not need to look at projects like OpenBSD (which tends to divert the discussion by throwing in terms like pragmatism and paranoia): the development of the Linux kernel itself does not work like that, and it did not work like that back when it was mostly developed by volunteers, either.

I think what separates these projects from those in a perpetual beta is responsibility. Some teams, or some projects, build a culture of responsibility. Some do not. Most commercial projects that survive do build it, because being irresponsible tends to be bad for business. Many open source projects that are fundamental to infrastructure efforts of large businesses also build it, partly through influence, partly through control, and partly because this is just how quality software gets written.

Money is not the only ingredient here. There are projects that lack it chronically, like Gimp, and yet they do not suffer from this perpetual beta syndrome.

It seems that it all boils down to the same old question, which countless meaningless HR interviews have rendered almost embarrassing to ask: at the end of the day, why do you sit down in front of your computer and start to program?