♠ The Blackrom Development Manifesto

The following document is an early draft, dated June 29, 2024. It is likely to be revised or added to. Errata will be included at the end of the page when this happens.

We hold these truths to be self-evident:

Folks who work with computers should hate computers. Computers are evil, dangerous, and will destroy your life if you let them. Thus, the task of writing software and designing hardware is to trick the computer into useful labor while mitigating its ability to hurt you. This can be achieved only through a deep understanding of the machine and an unfailing commitment to maintaining control over as many things as possible.

A hacker must therefore be someone as disgusted by computers as they are fascinated by them. Their relationship with computers must be a black romance, a love borne from hatred, an obsession wrought from revulsion.

Wait, why use computers at all, then?

Because their power is worth harnessing. Much good has been achieved by the digital revolution. Knowledge can be shared, friendships can be formed, families can keep in touch -- all across any distance, nearly instantaneously. We have made many formerly difficult tasks easy. We have unlocked whole new styles of music, avenues of literary expression, and even invented a whole new interactive medium. None of these things would have been possible without computers.

We hate computers because of what they are, and use them anyway because of what they can do.

Why do we hate computers?

Because they suck.

Okay, we'll expand on it a bit. We hate computers because they hate us. A computer is, in theory, the ideal creative environment, allowing the minds of us earthfolk the freedom to build anything that can be modeled mathematically -- which is to say, anything we are capable of conceptualizing. In practice, a computer is a torment nexus of edge cases and gotchas, confusing and poorly-documented designs, mysterious bugs and inexplicable brokenness. The computer is an Ozymandian monument to our own inability to actualize our own ideals. Or worse still, they prove that the space of our imaginations is fundamentally limited, that it is mathematically impossible to achieve a perfect design. In the machine, we see the jagged insufficiencies of our minds.

Perhaps it is more accurate to say that computers are not strictly evil, but provide us with the power to fuck things up faster and more efficiently than ever before. The computer, after all, is only an unfeeling machine. But unfeeling machines are famous for chewing off limbs when disrespected. (We call it "technical debt" here.)

The Principles of Blackrom Development

The computer hates us; we must love each other.

Computers are for everyone. The systems we build with them, therefore, must be liberatory, egalitarian, and above all accessible. Though we are about to spill far too many pixels denouncing needless complexity, design decisions that help folks are never needless, particularly when they address the needs of underprivileged groups. Blackrom development is, as a matter of principle, devoted to the needs of the disabled, the poor, those of oppressed ethnicities, sexualities, genders, or other identities, and all other folks whose needs are often unmet or even maliciously withheld. For the same reasons, blackrom development is definitionally anticapitalist.

We also acknowledge the wellbeing of developers and engineers. The folks building these systems must take care not to overwork themselves. FOSS burnout is a major problem. Thus, if a developer has not been able to undertake the task of making major feature additions in the name of accessibility, we recognize and respect this. Accessibility is, nevertheless, always a major priority. Blackrom developers must not callously ignore the needs of others, or worse, invent a development philosophy which fundamentally excludes their needs. (Suckless devs, this means you.)

There is no good way to do anything with a computer.

All programming languages are bad. All operating systems are bad. All protocols are bad. All software is bad. All hardware architectures are bad. Computers are bad, and so is every way of using them.

When you eliminate the delusion that computers are good, you see that all forms of computer chauvinism are foolishness. We have no time for "I use Arch, btw," for command-line jackasses who smugly look down on GNOME or KDE users, or for Rust evangelists refusing to understand why someone might prefer to write C, C++, Zig, or Hare.

That said, we have even less patience for oppressive design. We can never tolerate Big Tech exploiting and abusing their users in the name of greater profit. All ways of using computers are bad, but not all of them are evil. (But please remember that the oppressed are never at fault! We are in the business of building alternatives, not of shaming folks who can't use them.)

Furthermore, all ways of using computers are bad in different ways. And the only entity capable of knowing which pain points are tolerable is the entity actually facing them. Therefore there can never be one single best solution to any problem.

Keep sight of the machine's true form.

The machine exists as it is, not as we would like it to be. Opaque design decisions and abstractions risk obscuring the spirit of the silicon. And an unobserved machine loves nothing more than to misbehave. We must never look away. Strengthen your resolve, and develop an iron stomach. Look upon the machine with revulsion, but you must look.

Protect yourself from the machine with abstractions.

We are ill-equipped to fight the machine alone. It is a whirlwind of confusion, and we must anchor ourselves. Here, we may turn to mathematics, to abstractions. Though perfection is impossible to actually achieve, so too is the raw chaos of reality impossible to parse. Therefore we must draw lines, categorize ideas, abstract away difficult and tedious details.

This may seem to contradict the previous point. That is because it does. These requirements are always and ever in tension. This is not a bad thing. The universe thrives on the tensions between opposing forces. And many good and wonderful things cease to exist when tension is resolved. A star dies when the tension between gravity and radiation pressure is resolved. A song ends when the tension in its harmonies is resolved. We must abstract, but flexibly, never losing sight of the reality beneath the abstraction. We must accept this contradiction; our languages and designs will be stronger for it.

Move slowly and fix things.

"Disruption" is an overrated and actively harmful artifact of a capitalist economy. The world of tech is plagued by a constant coming and going of trendy languages, fad management techniques, vaporous development philosophies, as companies jockey for influence and clout and the profit they entail. This helps nobody.

We require a stable engineering tradition in order to properly tame the machine. If we are fighting our own techniques, it will overpower us. Our tradition should be a body of knowledge and experience we can rely on to keep us out of trouble. Throwing out decades of proven ideas isn't innovation, it's wasting effort.

But also remember that there is, and always will be, room for experiments and exciting new ideas. A tradition can evolve while staying stable! But our core systems, management techniques, and programming languages benefit from staying boring. Better the devil you know.

Last words

No, you don't actually have to hate computers. Nobody should have to devote their life to something they hate doing. But I think any developer or hardware engineer worth their salt definitely has a complicated relationship with the machines. If love ignores faults, is it love at all?

In the immortal words of the Dread Pirate Roberts, "Life is pain, princess. Anyone saying differently is selling something." I distrust anyone who tells me computers are good, or can be painless and intuitive. Anyone who lionizes a particular programming language, operating system, or paradigm is either naive or actively deceitful. Painlessness is never really an option; you are trading one pain point for another.