Better Software

This is an article that lists some of what all software developers should aim for after coming up with a good idea. The purpose of software should be to benefit its users; not to waste their time, encourage harmful habits, or duplicate existing solutions (see: Software Alternatives Are Harmful). Technology is a means to an end and not an end in itself; it must not harm its users, endangering their sanity, security, privacy, or anonymity. There is no virtue in adhering to all of these tenets if the resulting program still revolves around a bad idea that creates more problems than it solves.

Apoliticism ~

Both proprietary and free software developers are guilty of not maintaining apoliticism in their programs. When programs become tools to furthermore propagate a certain ideology (e.g., by using the project's socials and blog to push propagandist political narratives and slogans instead of software updates, or by using an emblem or flag as the background under the software's icon), then the developers will have no problem to apply complete censorship (see: Against Moderation) against those who go against their ideas by enforcing "usage policies" and "codes of conduct" unrelated to the actual usage and contribution to the program all over the README/CODE_OF_CONDUCT (or, even worse, the LICENSE) in a way that's no different from corporate EULAs, instead of merely asking the contributors to keep their political views to themselves.

Programs are technology, not brands, identities, waifus, franchises, weapons, political grounds, social networks, work opportunities, property, platforms, or endless money generators. Technology is art, stop polluting it and using it for other than what it's intended for! A calculator program, a game engine, a third-party Discord client, a chat exporter, a Firefox fork, a Linux distribution, an alternative Minecraft launcher, or a display protocol implementation is not the right place to voice your thoughts on an ideological or sociopolitical issue (or to insert harmful code in auto-updates targeting certain users like the Russians during the Russia-Ukraine war, as was prominent in "open-source" projects on GitHub). No matter how "rightful" or "noble" it may seem to you or to others, persuading people in order to seek validation for certain "acts" (or any other kind of ideological advocacy) is nothing but a poor and pathetic display of insecurity, and it applies even for ideas that I advocate for; software is just not the appropriate place for social advocacy, because people from all ideological backgrounds will be using and contributing to it.

Compatibility ~

Backward compatibility ensures that file formats, command-line flags, configurations, and saved data continue working seamlessly after software updates, preserving existing user workflows without breaking changes.

Software should never do anything to a user's system, data, or files without that user's explicit, informed consent, and the default answer must always be no, not yes with an opt-out buried three menus deep. Consent isn't a one-time checkbox either; it has to be revocable at any moment. People change their minds every now and then.

Consent is routinely violated in "autoupdates," which frequently modify software on the user's device remotely, sometimes silently and many times in a forced manner without the possibility to refuse this modification (typically in proprietary software). This is a manifestation of update culture. These remote software modifications are called "updates" to make the user think they're a good thing, but in fact they usually introduce more bugs, bloat, security vulnerabilities, annoyances (like forced reboots), and possibly malware. There must be absolutely no automatic remote code execution!

The same principle rules out silently writing anything to disk (such as cache, logs, configuration, and telemetry) without asking first, and it rules out networked software making any request the user hasn't been told about and agreed to. Where it's going and exactly what it's sending should never be something a user has to sniff traffic to find out.

Contact ~

Every project needs a documented, official way to reach whoever maintains it, preferably through an email address (since email is standardized), alongside a separate address for reporting security issues in private. Core development discussions belong on persistent and searchable spaces like mailing lists or forums (see: Superiority of Asynchronous Visual Communication), and to keep workflows efficient, these spaces should be categorized by purpose; separate spaces for discussing general development, bugs, patches, and documentation, plus a dedicated space solely for announcements.

To keep development collaborative, contributing shouldn't require signing up for anything. Opening an issue or sending a patch shouldn't only happen on web forges; forcing users to register an account just to submit a three-line fix adds unnecessary friction. If a forge is used, it should be fully synchronized with account-free methods like emailed patches (via git send-email) and mailing lists to keep the workflow open and decentralized.

Similar to > Openness, contact methods and development discussion shouldn't be bogged down by obstacles like Cloudflare, bloat, tracking, or mandatory sign-ins (with the most famous example being Discord servers). Real-time chatrooms are too ephemeral and closed up to serve as the main development space, and should be kept strictly for casual social banter.

Decentralization ~

As a matter of principle, networked software should not depend on a single provider, a single machine, or a single point of control; entrusting all communication, data, and infrastructure to a single authority creates a dependency that can be broken at any time, whether through censorship, incompetence, technical failure, financial issues, hostile acquisition, government intervention, or simple malice. The more centralized a system becomes, the more power is concentrated in the hands of those who control it, and the less control remains in the hands of its users. Once one authority owns the entire system, that authority can decide who gets access, what gets removed, what gets monitored, what gets slowed down, and what gets killed outright, and everybody else is forced to accept it because they have nowhere else to go.

Decentralization is therefore much better than centralization because it reduces reliance on any single operator, distributing the burden among many independent parties and making the system more resilient against monopoly, censorship, abuse, incompetence, and technical failure. Peer-to-peer networking takes this principle to its logical conclusion by eliminating the dependency on dedicated intermediaries altogether, allowing users to exchange data directly rather than through infrastructure owned and controlled by others.

Extensibility ~

If certain features truly are relevant to the usage of certain programs in some way that is agreed upon, but still not needed in the core, they should simply be ruled out as extensions (i.e., patches, plugins, etc.), so they can be excluded from the core (thus increasing > Non-Dependency by nullifying interdependency), tested separately, scrapped easily, and removed or replaced at any time by the user's own will without fear of any problem, as is already seen from Suckless software's hyperfixation on > Self-Containment. Two common things that should be ruled out as extensions instead of being included in the core are interfaces, especially GUI (since, according to Unix philosophy, CLI is a universal textual interface allowing pipes, redirection, and scripting, and both interfaces need to be built independently by strictly separating the backend libraries and core logic from the frontend interface), and encryption as a way to maintain anonymity/privacy/security (since it's an imperfect technological solution to a problem rooted in society, as I've noted in Better Internet > Networking).

This is done to maintain a certain degree of > Minimalism and avoid piling shit upon shit, which is prevalent in many software like Emacs and Neovim; sometimes a text editor is just a text editor, not an operating system. I understand that vanilla Neovim is unusable to some people without a bunch of quality-of-life plugins, but with useless ones (like an image viewer, a frontend for YouTube, or a minigame), I don't think it'll have anything to do with "text editing" or "programming" anymore, as you're incrementally ruining a perfectly functioning piece of software. You might as well just pull out an entire ledger of Python dependencies and Rust crates which let you generate 1000x times more AI code by spending hours to enable the pissenshitten function in the poopenfarten configuration files of your boykisser.nvim plugin. I'm just so sorry you were born this way. </3

Freedom ~

This is what we all strive for. We want to be big strong independent basement dwellers who still live in their parents' home. Achieving total freedom in one's use of technology is the greatest accomplishment man can attain. There are rumors that when this happens, golden light starts to emanate from your computer screen and Richard M. Stallman, head of the Church of Emacs, materializes in your room. He has written the GPL (GNU Public License) to help you reach this state of nirvana. The freedom feels so good!

According to the GPL, four freedoms are required for software to be truly free:

  1. The freedom to run the program.
  2. The freedom to study and modify (i.e., fork) the program's source code.
  3. The freedom to redistribute copies of the program's source code.
  4. The freedom to distribute copies of the modified source code.

Access to the source code (i.e., > Openness) is a precondition for this. As for free software licenses, they are mainly divided into:

The GPL is the premiere copyleft license, unlike permissive licenses (such as MIT, BSD, and Apache), in that any derived work needs to be distributed under the same terms; this way it legally demands the work stays free so it can benefit everyone, therefore it never can be close-sourced or used in proprietary and permissive software. Think of it as a license that grants you every freedom, except the freedom to take away other people's freedom (i.e. "forcing freedom"). Hence, this license highly favors the end users and is a "hack" of the copyright system, as Stallman described it, because it uses the legal infrastructure of copyright to ensure software is free rather than restricted. However, copyleft doesn't go without issues:

  1. It adds endless friction and extra work (e.g., copying the license file, forever making sure it doesn't get lost, giving credit (GPL), studying copyright law in order to modify copyleft software, etc.), whereas a public domain and many permissive-licensed works can simply be taken and used as is.
  2. It relies on copyright and "intellectual property" laws to function; to enforce copyleft (i.e., prevent "disallowed" use), one has to make a legal action, whereas with permissive licenses one simply gives up the rights to make a legal action.
  3. It's a massive pile of bloat, which contradicts the tenet of > Minimalism; copyleft licenses must include all the complex and ugly legal boilerplate to be defendable in court, introducing vulnerabilities and incompatibility (apparent from the three versions of GPL) as well as constant legal concerns from new trends (apparent from the conception of AGPL for "networking").
  4. It's ineffective; detecting a violation (through reverse-engineering) and actual legal enforcement is difficult, expensive, and without a guaranteed positive outcome (in fact, the FSF encourages programmers to hand over their copyright to them so they can defend their programs, which just confirms the existence and relevance of this issue). This is a waste of time and effort by forcing you to be a shitty political activism lawyer forever rather than doing actual programming. Besides, proprietary software developers have already established the new corporate plan to make a "bloat monopoly" to bypass copyleft by limiting > Understandability (as discussed in > Minimalism).

As for permissive licenses (like MIT, BSD, Apache, MPL, etc.), they ensure complete freedom in the sense that "you can do anything you want" with the source code (though still require giving credit to the original authors). The main caveat here is that by using such licenses instead of copyleft in important works (especially those that exceed hundreds of source lines of code), one is simply being "artifically cuckolded" in the sense that he's writing code and effectively abandoning the privileges of intellectual property while allowing any large corporation to close-source and monetize the software that said person wrote in a completely legal way. An example of this is that one time when Intel silently took MINIX, an operating system under a BSD license, and used it for their Management Engine, the mass-surveillance microprocessor and permanent NSA backdoor running in all modern Intel CPUs (the MINIX developer reacted like a retard with words like: "at least MINIX is technically the most widely used operating system in the world").

Still, users of permissive licenses are freed from all of the legal headaches about the source code. Sure, while corporations can abuse permissive software easier since there's no legal protection, the root issue should be addressed by improving the socioeconomic system (i.e., promoting freedom and selflessness) rather than by bullshit legal techniques that just imperfectly (and many times completely ineffectively) try to cure the symptoms while strengthening the current system's mechanisms. If a scientist dedicates his work to the public, he's not to be blamed for other people's evil application of it.

A subset of permissive licenses (perhaps the most extreme "free license" type) is patent waivers (like the CC0); they ensure the work was released into the public domain, abandoning even the legal right of proper attribution and copyright. Authorship attribution (most of the time explicitly giving credit somewhere in the work) is something that's often a condition of a software license such as the aforementioned MIT/BSD/etc. licenses, as well as the CC BY licenses (for other intellectual works), granting everyone rights to the work as long as the original author is properly attributed. Forcing attribution is harmful for many reasons:

  1. It may cause practical problems and render the work unusable, having to credit every single person involved into the authorship of some work.
  2. It may force you to be signed under works you don't want to be signed under, since the derived works must be forced to sign your name on them.
  3. It's just legal bloat, extra burden, and still relies on copyright and "intellectual property" laws to function, which aren't effective (especially overseas), and you always have to detect infractions.
  4. It discourages many from using your work to save legal headaches and trouble.
  5. You will almost certainly be attributed even if you don't force it. There's basically no reason not to, it's in everyone's interest; people are culturally very strongly taught to always attribute others and are socially rewarded for doing so. If someone wanted to take credit for some work he didn't make, it would sooner or later be found he didn't make the work anyway (e.g., the original author would comment or it would show the person is incapable of producing more similar works), thus forever marking himself as a scammer. This is apparent from most Chinese (and other third-worlder) copycats who steal even copyrighted works and face no legal trouble.

In any case, some see the issue of choosing between permissive and copyleft licenses ultimately resting on terms of which would maximize the possibilities for users using free software, for good intentions, because technological development nowadays is used in machines that kill children and nanomachines that spy on people. Such a consideration led to the creation of the "Lesser" GPL license (LGPL), a weaker copyleft license which allows free software to be used as a library in proprietary works to compete with proprietary libraries in terms of presence and adoption, instead of fully surrendering the code to proprietary hands. The way it should be, however, is that freedom should be absolute in this regard; one must let go rather than continuing the fight for an arbitrary legal right under a corrupt legal and social system, so CC0 (and similar waivers dedicating works to the public domain) is the absolute best "license" for software development and all other artworks (this is objective and fact-checked!).

There also exist other copyleft and permissive licenses other than the above, but the caveat is that they contain weird or tricky conditions (like that one license that guarantees software freedom for everyone except for Richard Stallman, or that other one that forces all software forks to admit in the license that Cirno is the strongest in Gensokyo, or the infamous "+NIGGER"/"-CHINA" license modifications), or unsuitable language for legal validity (like the WTFPL, which also misses the important disclaimer about providing no warranty, allowing lawsuits in case of damages). These are just for fun, and should be avoided for any serious works.

Of course, none of this should stop at the source code. A program shipping proprietary art, fonts, sound effects, or data it doesn't have the rights to freely redistribute and modify isn't actually free. Everything shipped alongside the program should carry the same freedoms as the code, to maintain free culture.

Interoperability ~

Interoperability determines whether independently written programs can communicate seamlessly by relying on shared, openly documented formats and protocols. That requires the format to actually be an explicit standard on paper rather than whatever a single program happens to execute internally. A "specification" that exists solely as the source code of a proprietary client isn't interoperability, it's vendor lock-in (see: > Openness).

To safeguard longevity and platform independence, software must prioritize well-established, open standards for all input and output:

Minimalism ~

Software minimalism is mainly divided into two parts:

Software minimalism is firstly about internal simplicity (i.e., the simplicity of design, repairing, and hacking), and only secondly about the simplicity from the user's point of view. Such a distinction between "internal" and "external" minimalism was made because, with increased interest in "minimalism," the word itself gets misused and abused. True minimalism aims to minimize everything that's unnecessary, whether in source code or in software design, and keep high-level abstraction to an absolute minimum. A program may "appear" minimalistic in an aesthetical sense whereas it hides a horribly overcomplicated source code under the facade ("pseudo-minimalism"), and another program may have good internal design while still being a horribly overcomplicated tool to use.

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

James Zawinski

As a matter of principle, programs should go further down the lane of simplicity by remaining minimal and focused at a primitive level (i.e., "doing one thing well"), only including absolute necessities and without introducing unnecessary features that duplicate the roles of other software, as feature creep contributes to:

  1. Consuming computing resources and increasing load times.
  2. Cluttering the interface beyond recognition (with layers upon layers of toolbars, dropdown menus, buttons, etc.).
  3. Overwhelming and distracting users.
  4. Amplifying software issues and security holes.
  5. Complicating maintenance and slowing down development.
  6. Decreasing efficiency, since the features won't do the job as well as the actual programs built for that sole purpose (and they won't be used anyway by most users).

Not only that, but it also limits > Freedom by limiting > Understandability, since a complicated gigantic codebase would greatly limit the amount of users who can understand it. This is how corporations such as Mozilla and Red Hat have undermined the entire purpose of free software, establishing a "bloat monopoly" and turning their programs de-facto proprietary, as their huge teams of developers are the only ones who understand the source code. In fact, the reason so much complexity exists in the software world is literally to provide jobs for mediocre engineers. For example, if you want to compile the so called "open-source" Android, you will need a supercomputer at home (with at least 400 GB of space, 64 GB of RAM, a modern 64-bit CPU with 72 cores, and many hours of computational time). Through this "bloat monopoly" that only the richest may conform to (or even legal compliance requirements such as the EU's mandatory content filters imposed on search engines and social media that are practically impossible to comply to without powerful proprietary systems and LLMs), any potential emerging competition is eliminated in the capitalist system.

None of this means minimalism can be measured by counting lines of code; it's only a rough proxy for how bloated a project "feels" like, but never the metric itself; there's no universal line where bloat begins, only the point where a project starts serving its own complexity instead of the purpose it was written for. Moreover, the different purposes of programs and varying abstractions of programming languages make this criterion even more ambiguous. Rather than asking "how many lines of code are acceptable," a far better diagnostic is asking how many concepts the project introduces, how many external dependencies it drags in, how many potential failure modes it creates, and how much of the codebase exists solely to support its own internal infrastructure.

Putting more than one type of functionality in any kind of program which is universally considered unnecessary and irrelevant to its usage is pointlessly duplicating the job of the window manager (in the case of GUI programs) or shell pipes and input/output redirection (in the case of CLI programs), and this is why the Unix philosophy puts an emphasis on software modularity; the idea that programs are supposed to integrate cleanly with others rather than constantly introducing new "features" that other programs already have.

Multiplatformness ~

The worst kind of software censorship is that the product is limited only to specific operating systems (especially proprietary ones like Windows and macOS) or specific hardware (such as x86_64 or ARM). This gets very common when we see the Linux/BSD people resorting to Wine/Proton or engine reimplementations, but the issue of > Ownership arises yet again, since DRM is the cancer that always gets in the way of emulation, and sometimes we see other measures being made to lock out users who have paid the full price for the software in question, so even though the Linux minority are the most willing to pay for software and donate to their developers compared to all of the operating system userbase demographic, they're all forced to pirate because corporations apparently don't want money from people who care about their privacy through natively supporting other platforms.

Non-Dependency ~

Dependencies are made assumptions about the platform that programs will run on (e.g., once we use a library, we are henceforth assuming that this library will be present on every platform our program will be running on). The fewer assumptions are made, the more adherent to > Minimalism and the less limited the program will be in a sense that it gets rid of dependency hell (i.e., the constant management of dependencies and their recursive dependencies) and external control over software. This is why some programmers write their own memory allocation functions even though they are available in the standard library of the language; the consistency, control and knowledge of how exactly such functions behave is often worth the price.

Dependencies are unfortunately unavoidable, but with good approaches, they can be minimized to near zero or abstracted away in order to allow for alternative drop-in replacements (especially throughout other platforms, allowing for > Portability). This approach is achieved by taking into account all types of dependencies:

The final solution to dealing with dependencies is to make the program bootstrap from a very simple system (e.g., some abstract bytecode that's quite easy to implement from scratch). If your program and all of its dependencies only rely on a machine capable of running such bytecode, the program will run anywhere where you implement the bytecode and where there's enough computing resources.

Although this is ideal, it's quite a lot of work to create your whole computing environment from scratch, so in most cases you would rather settle for technology that's already existent and well-established (C, CLI, plaintext formats, etc.) to build your program on top of, and further minimize what you can from the above list. Drop anything that's unnecessary, make optional what can be made optional (e.g., GUI), and if possible, offer alternatives (e.g., software rendering as opposed to GPU-accelerated rendering). Don't use libraries for everything; if you just have to make a ball bounce off of the floor, you don't have to include a whole physics library. If it's simple enough, write it yourself.

Openness ~

Security through obscurity (i.e., hiding how a system works and hoping nobody figures it out) is often cited as a reason to make software closed, but this isn't really "security," it's a countdown timer. A design should hold up even with the full source in front of the attacker, which is one more reason openness matters.

Public and open access to the source code is the only method that completely eliminates all need to "trust" a certain entity or individual with how a certain program operates. By examinating the source code, one can truly be certain whether the program fulfills his standards or not, and whether it's malware or not. However, pure software openness is practically useless without software > Freedom; the "Open Source Initiative" (OSI), headed by capitalists such as Eric S. Raymond, is a weird bastardization of free software that came in primarily as a corporate reaction to the fact that they can make software open-source and still build a monopoly off of them, and that they can also attract a horde of autists with too much free time on their hands who thanklessly contribute to their code.

Most self-proclaimed "anti-capitalist open-source programmers" happily follow this purely capitalist movement, proudly embracing terms like "open-source" and "source-availablity" while completely missing the point, which is apparent from their usage of proprietary Git forges like GitHub or SourceHut, their usage of Discord servers as their main public developer discussion space and support method, etc., while thinking they're opposing something. This is exactly what the OSI wanted to achieve; a false sense of rebellion that will actually make most programmers do their bidding.

Open-source software should be available publicly, easily, upon immediate request, and with a detailed log of all historical changes, without any obstacles that "de facto" hurt openness; this includes Cloudflared, obscured, bloated, anti-privacy, slow (e.g., email requests), sign-in requiring, and paywalled platforms. This makes distributed revision control systems (such as Git, over SSH or HTTPS) superior to other solutions. Public Git forges (such as Forgejo, a community fork of Gitea) and read-only browsers (like Cgit) can be nice frontends to Git repositories, improving accessibility.

Furthermore, true openness dictates that projects remain managed by a volunteer community, not an evil corporation, ensuring the software serves the users rather than a corporate agenda. Corporate resistance to outside output is a hallmark of false openness; for example, freedesktop.org aims to deprecate Xorg in favor of Wayland largely by not accepting outside commits, establishing control through attrition.

In a similar light to the points expressed in > Freedom, this extends beyond source code to any media shipped with a program. Music, drawings, videos, fonts, etc., are usually made in a program-specific editing format and then exported to a distributable file. This exporting process is an analog for compilation, and the project file is the source code. Media could be open-source; distributing the project file (layers and strokes for images, tracks and stems for music, cuts and timelines for video, etc.) alongside the exported output would let people understand how it was made and modify it. In practice, almost no one does this, but it should become the norm.

Ownership ~

It makes no sense to own data on a device that's not owned by you. Unless you want a file or two to be available to others in a fast convenient way, the fact that you have your own HDD/SSD (with backups) means that there's no point in storing your data on remote external infrastructure (i.e., someone else's computer), as that would cause a trust-based dependency that could get broken anytime for a multitude of reasons, such as getting banned from the service, or a fault in the provider's servers, or unavailability of network access, or losing passwords, or getting phished. It's also costly in terms of bandwidth and requires expensive infrastructure as a matter of principle.

The only reason why corporate entities begin to push the "cloud" model is to merely have greater control on data. Content tyrants (such as YouTube) don't want you saving content locally for a reason, as they would much prefer everyone be cattlechuted into DRM-encumbered proprietary web stream players and mobile applications with restrictions on when, where, what, and by whom any piece of media can be accessed. It would be awful for them if you were to save and share any of it on massive external drives. In a more dystopian future, newer hardware will most likely come with no storage at all, and will require a constant connection to the "cloud" in order to access files and use software. Autonomous computers would legally present the same "danger" as the uncertified ownership of guns, only ever being needed by terrorists, pedophiles, and pirates.

Even Tomoko is sailing the sea!

Average subscription fan vs. average piracy enjoyer.

Moreover, it also makes no sense to host data that's not even owned by you. If you think you've ever "purchased" or "owned" a piece of software (or any kind of digital media like games or ebooks) as a product, you've got things wrong. Software, along with other digital goods, is information, and information isn't a tangible, irreproducible good that can be traded. The only thing that can be exchanged are the "ownership rights" (copyright and intellectual property) associated with that information. Instead, what you've paid money for is a service; you're paying for rent to a license that gives you the right to use the software, and without such a license, you are liable to be sued under "copyright infringement" by the entity that maintains ownership of the copyright (as is written out clearly in every EULA), and yes, the rent can be revoked at will without any warning or consequence.

There's a reason why research shows for the millionth, billionth, trillionth, quadrillionth, quintillionth time that piracy doesn't equal a lost sale, and that cracking down on piracy is exactly what results in undesired outcomes; it's because copies of information are supposed to be redistributed and shared freely by those in possession of it, not to be restricted by "Digital Rights Management," which at one point becomes such a pain the ass that people would naturally resort to piracy in order to get a DRM-free version that's much more convenient to use, as no self-respecting legitimate customer wants to go to through a proprietary spyware "store" to pay for a "product" also embedded with proprietary spyware that would then wrongfully accuse him of piracy and lock him behind a serial code that might or might not even work because a keygen executable on someone else's computer might have guessed that code before he bought it (and there's lots of such cases).

The entire "intellectual property" scam (including copyright and DMCA laws) is hurting consumers, pirates, creators, and sale revenue all alike while bringing benefit to the government elites (which is why you will never see pro-piracy laws). The people against "piracy" (because it's an "unethical plunder of other people's property") continue singlehandedly destroying the internet even harder than all governments combined have ever been able to do, only because they believed a lie that was propagated so much over the years by a multitude of corporations who want to put price tags and subscription plans on things that were never supposed to be sold. "Piracy" isn't theft, unlike taxation.

Moreover, software shouldn't artificially prevent people from hacking it, breaking it, raping it, or using it in ways it wasn't intended for; that's the user's device and the user's risk. If that basic right isn't given, then software isn't truly "owned." Security is the user's responsibility, not something a developer "enforces" on their behalf, and there's always a trade-off between security and functionality; removing someone's ability to choose where they sit on that spectrum isn't protection, it's control.

Portability ~

Portable software, according to Unix development, is software that is easy to port to other platforms, whether they be hardware platforms (CPUs, ISAs, game consoles, etc.) or different operating systems. Portability is an extremely important attribute of good software, as it allows to write the program once and then run it on many different computers with little effort; without portability, we'd be constantly busy rewriting old programs to run on new computers. Essentially, portability frees programs from being tied to specific platforms and exist abstractly and independently, becoming thus future-proof.

Portability is different from mere > Multiplatformness; multiplatform software simply run on more than one platform without necessarily being designed with high portability in mind, whereas portable software possess the inherent attribute of being designed so that little to no effort is required to make them run on a wide range of general platforms.

Portability is achieved through careful design choices related to > Non-Dependency, made to avoid platform-specific features, such as writing in assembly code (as that's specific to each CPU), directly using Linux syscalls (as they're specific to Linux), and using UTF-8 charaters instead of ASCII in the source code (which many restrictive or legacy systems don't support). It's also achieved by adhering to > Minimalism (in order to support low-end technology with hardware resource constraints), using well-established programming languages supported basically by every platform (C, especially in well-established standards like C99 or C89, ideally if it's valid across both and is compatible with more standards or even C++ compilers), and using well-established shell scripting languages (POSIX shell). Hence, one must avoid Bashisms, Python, Rust, Ruby, Java, C#, Flash, JavaScript, and other heavily abstracted (or unnecessarily complex, such as OOP) languages like the plague. This ensures the codebase remains independent of massive external package managers and virtual machines.

Readability ~

A project's source must be readable and consistent by following a set of rules when styling code:

Additionally, use a simple version numbering system; preferably with the major.minor.patch format, where:

Self-Containment ~

There's a reason why Suckless software insists on staying self-contained, where programs are distributed as source code to be compiled and run; no daemons to start, no database services to configure, and no configuration files scattered across ~/.config/, ensuring that software is future-proof. Distributing pre-built binaries introduces an unnecessary layer of implicit trust, which directly violates > Non-Dependency.

Configuration should also live in a plain, textual, human-editable format, and the best form it can take is source code itself; a config.h the user edits and recompiles, rather than a runtime file the program has to locate, parse, and validate on every launch. > Extensibility follows the exact same rule; modifications should be applied as compile-time patches rather than through heavy plugin APIs or embedded scripting engines bolted on for runtime customization.

Understandability ~

Understandability allows repairing a program or reimplementing it by third-parties (to protect against software rot), and enables software > Freedom in a practical "de facto" way, not only a legal "de jure" way. Like > Minimalism, software understandability is, again, divided into two parts:

Internal understandability is about the source code. It needs to be simple to grasp while inspecting and studying, without any obscurity, by adhering to internal minimalism and being well-commented (with searchable keywords or WIP and TODO notes), as nobody is willing to get through massive and convoluted codebases just to make sure that it respects user freedom, privacy, security, etc. > Readability also plays a great role for enabling understandability.

As for external understandability, it's about how the program functions on the outside. It needs to be simple to use by adhering to external minimalism and being well-documented, especially when it comes down to its formats and public interfaces (APIs). It's important to stress that end-user help should be available to those who need it, hence, documentation should be provided along with the software, and without the need to connect to the internet, because a computer doesn't revolve around constant internet connection. Think about all the possibilities where people can be offline; power outages, running out of data, places without Wi-Fi, temporary ISP shutdowns, moving out, simply refusing to connect to the internet, living in a post-apocalyptic era and stumbling across the program in a USB disk, etc. Even if people have internet connection, offline documentation remains superior because it's fast and future-proof, whereas online documentation requires that an external website should be up at the moment of accessing (which by the way can be prone to link rot).