🏆 I provide private lessons on Emacs, Linux, and Life in general: https://protesilaos.com/coach/. Lessons continue throughout the year.

Accessibility and software freedom

A free software license is not enough

Software that conforms with the four essential freedoms does not necessarily empower users to be free. To actualise their rights, users must be able to access the program. This expands the set of requirements beyond the narrow confines of the free software definition into domains of usability and accessibility. Matters such as illegible colour combinations and incomplete documentation deny users the chance to employ free software in pursuit of their ends.

Software freedom has hitherto been framed in terms of legal requirements, as a means of bending copyright law to forward the needs of the user. The intent is to empower those who run the program to operate aloof from the influence of the program’s creator or distributor. While the repurposing of copyright law is fecund, the emphasis on code alone remains limited in scope and thus unambitious in outlook. The target audience is necessarily restricted to a nucleus of enthusiasts who are more or less inclined to tinker with the program. Everybody else is relegated to the status of a “normal user”, else “normie”.

Such a divide is unsustainable. Hacker communities do not exist in a vacuum. They are influenced, framed, or otherwise conditioned by legal-institutional arrangements beyond the field of programming. Software freedom cannot be treated in vitro as a standalone quality: it is but a facet of freedom at-large and thus depends on the prevailing conditions in the given political milieu.

Free software developers hold a tacit responsibility to serve the public good. They must care for others and have a sense of the bigger picture. Software freedom is not the vestige of some elite. It has to be readily available to all people, regardless of their skill level. Not simply as a matter of principle—a tokenistic claim on rights—but in its instantiation as a common good.

Impeding and ultimately excluding the so-called “normies” runs counter to the telos of a free society. Providing a non-technical user with some source code and a free license does not bestow upon them effective freedom. In the absence of high quality documentation and intuitive/usable interfaces, the person remains oblivious to the potentiality of the program and has no means of enacting the kind of changes that software freedom renders rightful. Such a user is excluded from the group that enjoys the liberties of freed programs, by virtue of their lack of expertise in the given area.

Compassion is key in dismantling those barriers to entry. All code should be well documented. Manuals must come with lots of real-world examples, not contrived abstractions that only domain experts can grasp. Text has to be legible at all times and information be kept to the essentials of the task at hand. Points of entry must be discoverable and clearly explained in the program’s accompanying study materials. When in doubt, developers have to default to what is likely to work for the least experienced person. Instructive resources cannot assume the user has prior knowledge of all the neighbouring issues of the task at hand: they need to be sufficiently explanatory.

The sort of README file that is five lines long and tells the user to run some arcane commands in a terminal shows a lack of compassion. It basically expects the person to perform a leap of faith and hope for the best, without ever putting things in context. This is scary for the uninitiated and makes them feel disempowered. Same for attitudes that go along the lines of “code should speak for itself.” Composable and clear code is of great value, though a program alone cannot be didactic for those who do not know how to read it. Aphorisms of this sort express a perhaps innocuous pride that is rooted in ignorance of the wider magnitudes and in the resulting lack of empathy.

The language has to be the one people use every day. Technicalities have to be explained in plain terms. Acronyms should always be expanded at least once and jargon be coupled with parenthetical statements or footnotes that state the point in ordinary palaver. Manuals should be written for a wider spectrum of users, both experts and newcomers alike. Make it customary to include a “how to” section (or equivalent) that shows how things are done and go the extra mile to explain what some snippet of code is doing. Veterans will know what to skip. Everybody else will benefit from the extra effort.

“Why go through all that trouble?” the free software hacker type may wonder. “Why should I care when all I want is to tinker with a program?” The answer consists in the recognition that software permeates every aspect of quotidian life and affects everyone involved: it is not contained to the profession of programmers and Information Technology administrators. What happens in the technology fields reverberates across society. Software exists in a continuum of interpersonal affairs.

While some may be taking it for granted, software freedom is in fact a privilege. We can afford it in principle because we live in societies that already have rudiments of freedom in place. These did not simply happen nor were they always there. They are the product of struggles to effectively abolish arbitrariness in the interactions between humans. Put differently, an outright illiberal order has the capacity to abolish software freedom altogether. Thinking that somehow code will always be left to operate alone is a fool’s gambit. It is understandable why a free software programmer may show no interest in the grand magnitudes of politics. Nevertheless, history shows that politics has a way of finding everyone, no matter how narrow their niche is. Those who do not care about what happens outside their purview risk suffering the consequences of decisions that are made in their absence.

The power of numbers is instrumental to the cause of freedom. A critical mass has the requisite exposure to reinstitute society in the interest of liberty and thus can implement thoroughgoing reforms at the political level. The bigger picture perspective puts free software developers, contributors, and evangelists in a position to build alliances with groups that promote liberty in other aspects of life. There are linkages to be drawn between the different domains of specialisation, provided one is willing to discern their potential and make them happen, all while blithely retiring the concept of “normies.”

The call to “keep politics out of it” that is encountered in technical fora is understandable in that it asks of contributors to remain focused on the implementation details of the topics under discussion. Yet it has to come with the understanding of the aforementioned continuum and the inherently political nature of software freedom as a facet of freedom at-large. Free software developers are de facto activists, even when they think they are merely flipping bits on a computer. They assume such a role by contributing to free software which, in turn, has the outright political end of emancipating users from the fetters of control, broadly understood.

Not everyone needs to pay attention to political events. They must simply admit they are not living in a bubble. The practical insight is to set a high standard for the quality of code and its accompanying study material. Software freedom rests on a strong documentation culture and an ethos of caring. This suggests a pedagogical outlook. Developers are not merely distributing source code and a concomitant COPYING license. They have the duty to teach people; to empower them to use, modify, distribute, and re-use programs in a manner that makes sense to them in light of the greater good.