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 ~

Configurations, user data, file formats, and command-line options should remain backward compatible across updates, so that any existing setups won't break. Users adapt to how programs behave over time, so if developers suddenly change the environment they were accustomed to, they're wasting the time and effort their users have already put in. Whatever reasoning they came up with to justify their changes, the actual cost is always paid by whoever now has to relearn, rewrite, or just lose something that used to work fine.

If breaking compatibility is unavoidable, bump the changes with a major version release, deprecate things gradually with warnings over several releases, and (preferably) provide a migration path.

Software should never do anything to a user's system, data, or files without the user's explicit and informed consent. The default answer to anything weird must always be "no" instead of "yes" (with an opt-out somewhere in the settings). Consent is also not a one-time checkbox, as 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!

This also applies to writing things to the disk (such as cache, logs, configuration, and telemetry) without asking first, and to networked software making requests the user was never told about nor 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 an official, documented way to reach its maintainers, preferably an email address (since email is standardized). Core development discussions belong in persistent and searchable spaces like mailing lists or forums (see: Superiority of Asynchronous Visual Communication), and these spaces should be split by purpose; separate ones for general development, bugs, patches, and documentation, plus a dedicated space solely for announcements.

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 registration-free alternatives, like emailed patches (via git send-email) and mailing lists, to keep the project open and decentralized.

Contribution should also preferably follow the idea that users are developers, which gets rid of the harmful corporate distinction of users as consumers and overlords; programs are source code (see: > Self-Containment) and bug reports are patches.

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 ~

Networked software should not depend on a single provider; entrusting all of your communication, data, and infrastructure to a single authority creates a dependency that can be broken at any time (with censorship, incompetence, hostile acquisition, government intervention, or pure malice). With this dependency, the central authority can decide who gets access and what gets removed, 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 resistant to monopoly, censorship, abuse, incompetence, and technical failure. Peer-to-peer networking takes it a step further by eliminating the dependency on dedicated intermediaries altogether, allowing users to exchange data directly rather than through infrastructure owned and controlled by others. Preferably, intermediaries can also still remain an option (as discussed in Better Internet).

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 "artificially 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 copyright 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's only one caveat specific to software; CC0 doesn't waive or license any patent rights the author may hold, only copyright and related rights (its text explicitly disclaims affecting patents). Since patents (unlike copyright) can still be used to restrict the use of code in the public domain, software released under CC0 should be paired with an additional explicit patent waiver (written in the end of the license, for example) in order to actually guarantee the four freedoms in practice. This only actually matters if you (or employers who could claim your work) hold patents covering something in the code, though, and it mostly becomes worth the bother on bigger or more significant projects. For anything else, it can be unnecessary as there's realistically nothing to waive.

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.

None of this should stop at the source code, of course. A program shipping proprietary art, fonts, sound effects, or data that can't be freely redistributed and modified isn't actually free, so everything bundled with the program should have the same freedoms as the code, to maintain free culture.

Interoperability ~

Programs must operate with each other by relying on openly documented formats and protocols, rather than whatever "specification" a single program happens to implement internally, creating vendor lock-in (see: > Openness). Hence, software must prioritize well-established open standards for input and output, to remain usable across platforms and over time:

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; that's only a rough proxy for how bloated a project "feels" like, but never the metric itself, as 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. The different purposes of programs and varying abstractions of programming languages make this criterion even more ambiguous. A far better metric is asking how many concepts the project introduces, how many dependencies it drags in, and how much of the codebase only exists to support itself.

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 a retarded excuse to make software closed. All it really buys you is a countdown timer before someone finds the bug anyway. A design should hold up even with the full source in front of the attacker, which is yet another reason why 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 examining 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.

True openness also 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 analogous to compilation, and the project file is the source code. Media can be open-source too; distributing the project file (layers and strokes for images, tracks and stems for music, cuts and timelines for video, etc.) alongside the exported output lets people see how it was made and modify it. 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.

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 the intentionally defective "Digital Rights Management" toolset, 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.

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 is a blatant exercise of control disguised as "protection."

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 characters 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, specifically in well-established standards such as C99 with POSIX.1-2008 or older, and ideally limited to what's also valid in C89 and C++ compilers where it costs nothing), 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. As a few examples:

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 be in a plain, textual, human-editable format, and the best form it can take is source code itself; a config.h that the user edits and recompiles, rather than a runtime file the program has to locate, parse, and validate on every launch. Same thing applies for > Extensibility; modifications should be applied as compile-time patches instead of 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 contributes directly to 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). End-user help should be available to those who need it, so documentation should be provided along with the software, 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).