Title: Free Software *IS* Politics, Dead Horse Edition
Created: 2022-04-21
Author: zlg

It seems that the systemd debate has made its way to Alpine Linux[1], and
naturally that gets people out of the woodwork to bang their drum about it
again. [2] The irony's not lost, either. It's really tiring to see people
complain about politics, in a software movement that's entirely about the
politics of software to begin with. Have you guys forgotten why we're here? Are
you more open source instead of free software? Even then, that's a political
statement; one of practicality and reduced costs.

For those unfamiliar, Alpine Linux is a Linux distribution (NOT GNU/Linux)
powered by busybox, musl libc, and OpenRC. By contrast, systemd is a project
aiming to provide a "system layer" between userland and the kernel. It
explicitly depends on a recent build system (meson) and generally only supports
glibc and the Linux kernel. It explicitly does not support any alternative
libc. In short, Alpine and systemd go together like oil and water, on purely
a technical basis. The social half even moreso, since this incompatibility
resulted in users having access to a simpler system that isn't built on systemd.
Choice is great, right? Some disagree, but they're free to make their own
projects.

When dealing with the systemd debate, many try to reduce it to the early years
of the debate, where people used the false dichotomy of technical and social.
Or they derail and assume it's a personal vendetta against Lennart Poettering,
without accounting for Lennart's behavior when he was advocating for systemd,
and the smug ways that his project has treated contributions, criticisms, and
distros like Gentoo. We do personal responsibility, first impressions, and all
that civil shit, right? Can we not apply this to our fellow developers? Are we
not responsible, to some degree, for how others perceive us and our projects? If
so, then I think it's fair to criticize a developer.

Lennart said "Gentoo, this is your wakeup call," [3] concerning the ability to
run udev without systemd, when eudev was created. He actively asked GNOME to
depend on systemd. [4] Granted, GNOME was probably going to use it anyway due to
Red Hat employing both Poettering and many GNOME developers... A number of Arch
developers (particularly its sysvinit maintainer) were early contributors to
systemd. It's safe to say, influencing other projects is the bread and butter of
the systemd project, and I challenge anyone to argue otherwise.

If you're going to participate in the debate, at least understand the history of
the project and the actions of the principal authors -- cultural origin matters
here because their values are baked into the project. The discussions from
the Arch and Debian communities are also worthwhile, to show examples of how
NOT to deal with the issue. Arch promised sysvinit would remain as an option,
then pulled the rug out from users with their switch. Debian had an *ugly*
debate that resulted in some developers leaving the distribution altogether, and
sparked the creation of the systemd-free Devuan distribution.

Arch and Debian both went systemd, while Fedora and SuSE leaned into systemd
first. As a witness to both Arch and Debian's decisions as-it-happened, the
one thing most distro devs missed was user transparency. Whatever plan you go
with, you need a pathway for the users who get left out, or you're going to
create a rift in the community or even a fork. So many users who didn't want
systemd got stuck with it. Some people who were using systemd on neutral distros
found themselves having to make a decision, where there wasn't a need to before.
Systemd support was not uniform across the ecosystem (wrt build options), and
still isn't.

The decisions affected a ton of users, ironically creating *more* forks and
attempts to maintain control of one's computing -- the dreaded "fragmentation"
boogeyman, often coming from those who don't see the value in a diverse software
ecosystem. The fatal flaw of consolidation is the assumption that every
developer in the problem space can agree on how its problems get solved. Given
human nature, that is very flatly a false assumption. Every solution in software
has different benefits and pitfalls. Some optimize for CPU speed. Some for
memory. Some for I/O. Others for networking! No single project can solve every
problem in a space. The solution to this is coexisting via multiple projects,
all of which can solve the problem(s) in the style that they choose. The
openness of software diversity is why systemd had a chance of adoption at all.

The ways that various distributions handled their decisions were decidedly high
temperature, and it's clear from the beginning of the systemd project that
it was intent on changing distributions. Denying that is to side with groups
trying to manipulate the ecosystem into carrying their software on every default
install. It's competitive behavior that has no place in a collaborative
environment.

Not every piece of disruptive software causes this much trouble, though. One of
Lennart's other projects, PulseAudio, hasn't caused nearly as much trouble even
though it, too, has its share of critics. I posit that the limited scope of the
project and its less aggressive appeal to the ecosystem allowed it to coexist
with ALSA and JACK in a better way than systemd does with other inits. Many
environments can treat PulseAudio as "another supported stack" with a little
maintenance, without upsetting their software's architecture.

Even the Wayland project, with its own brand of smugness and the specific goal
of replacing X11, hasn't done much to create an actual, damaging rift in the
communities they are near. Programs can support both Xorg and Wayland; at least
for the features that they both share.

It could also just be the nature of init systems. You generally have to make
an all-or-nothing decision. Coexisting init or service systems are a somewhat
new idea, which is why most distributions choose a single init. Apparently it's
possible, though, to mix and match between OpenRC, s6, and runit. Neat.

The technical and social are inescapably intertwined, just like politics is
to free software. Two sides of the same coin. The movement itself began as
the desire to fix a printer driver and compute *their way*. Furthermore, the
decision of which packages to include in a distribution is also political. It
affects the "computing lives", for lack of a better phrase, of the users who
trust the distribution's choices on software, or are otherwise aligned with
their software philosophy. Anything that has far-reaching consequences on how
people interact or conduct themselves could be interpreted as political.

So, what's really being called for when we're asked to "stahp being political"?
To ignore the social history of a project? To censor jokes we don't find
funny? To ignore prior debates, the outcomes of said debates, or the project
management of upstream? Software isn't developed in a vacuum, and software
with a big picture agenda (anything involving the desire to standardize is
automatically political) is not doing itself any favors by accusing others
of being problematic, when *the politics is the point*. It comes off as
intellectually dishonest or in bad faith.

Why *shouldn't* we consider the whole when we make software decisions? If given
the choice between two technically identical upstreams, would you rather deal
with the upstream who's helpful and receptive to contributions and doesn't
mind if people don't use their software, or one that sees itself above you,
decides the structure of your system without helpful or constructive feedback
for contributions, wants every system you touch to run their software, and has a
nasty habit of displacing other software? You sure that last part is really an
oopsie? Am I "not allowed" to notice that part?

I know what I'd choose, and it doesn't have to be highly personal. It's a matter
of one's own software standards. As a programmer, I find it shameful to push
one's project in a way that creates a lot of discord in the community. I don't
try to get people to use VGStash over Backloggery or their other favorite game
manager, but I might bring it up in a conversation if someone doesn't sound sure
of how they want to fix that problem, and it's relevant to the conversation.
Even then, I'd rather know that I have users because they like the software, and
not because I screamed about it from the digital rooftops or pressured people
into using it. That's a false merit, if anything.

Coexisting as a software project is not particularly hard. I could not, in good
conscience, act in the ways that Lennart has regarding systemd, even if it was
my own project. While some of the responses he's gotten have been over the top
(death threats? Crazy), I think it's entirely fair to apply my personal standard
to my software choices, and the people who write them.

I think there are many other people in free software who use similar criteria to
determine which software they use. This is especially important for software
that you think you might contribute to! If you don't like the ideas of the
author, or their tech choices, or their philosophy to software, those are valid
reasons to avoid their software! It's also valid to tell others that's your
reason. They don't have to agree with you.

But, I have to question the motives and values of a person who tells me to stop
paying attention to the politics that happen from a project with a decidedly
political aim. The technical and social parts of free software cannot be
reliably separated, any more than a human being's identity can be separated
between heart and mind. Separating the art from the artist only shows half the
picture.

Focus on the whole, and make the right decision for your computing. No outside
entity knows your needs better than you do.

-z

(Who can read the GNU Manifesto [5] and not gather that it's political?)

[1]: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/33329
[2]: https://christine.website/blog/politics-cudgel-experimentation-2022-04-21
[3]: https://lists.freedesktop.org/archives/systemd-devel/2014-May/019657.html
[4]: https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html
[5]: https://www.gnu.org/gnu/manifesto.html