♠ The Blackrom Development Manifesto

The following document is a draft, dated July 4, 2024. It is likely to be revised or added to. Errata can be found at the end of the document.

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.

Build your bricks small and square.

The most powerful technique earthfolk have developed for building big things is to assemble them from multiple small things. Big things are hard to build. You can't move a big thing yourself, and making sure it's built correctly is difficult and laborious. But making a small thing and making it correctly is comparatively easy, and they can be more easily manipulated to assemble a larger structure.

It's easiest to build a wall out of bricks you can actually lift. Even if you have a team to help, it's faster if everyone can work on their own section of the wall instead of all assisting to lift a single block of stone. Small bricks are also easier to make nice and square. In the same way, it's easier to build complex computer systems from many small components. Small components are easier to understand and use, easier to build, and easier to verify correctness on. This also means it's easier to assemble, meaning teams can work on different parts of a larger structure, instead of concentrating effort on one large component. This process is also recursive! Once you have a collection of small bricks, all verified to be correct, you can assemble them into larger blocks, which you then verify to be correct, and etc.

We of course cannot claim this technique as our own; it is part of the mature and proven engineering tradition of Unix.

Build towns, not towers.

The temptation is strong; now that we have bricks and can easily build bigger structures, why limit our ambition? Why not build a single, massive tower, a city unto itself! It will reach the very heavens, assimilate all peoples into its perfect design!

A minor inconsistency in a single brick could be so small as to evade notice. It's perfectly square, within margin for error. But once you start stacking more bricks on top, that margin becomes smaller and smaller. Suddenly, the assumption of a perfectly square brick starts to matter. Small imperfections compound until the entire tower is listing, imperceptibly, toward the north. And one imperfect brick begins to crumble.

And even if the tower stays steady and doesn't fall, what architect can account for the needs of people 200, maybe 300 years from now? The tower cannot be reconfigured, or else it will fall. It can only be added to, new floors and rooms added, its bottommost floors abandoned. It will become a husk of its former self, and when it collapses it will crush everything around it.

This isn't to say that large-scale design itself is to be avoided. Even small towns can benefit from a competent civil engineer acting as city planner! But houses can be torn down if necessary, replaced with better designs. It isn't easy, but new transit systems can be installed. A town's buildings are less likely to collapse, and less catastrophic when they do. They are more flexible. If you want your design to last and work well for a long time, build a town, not a tower.

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.

Miscellanea

Litany Against Tech-Worship

I must not worship tech.
Tech-worship is the design-killer.
Tech-worship is the little eyeroll that leads to total cringe.
I will face my urge to worship tech.
I will permit it to pass over me and through me.
And when it has gone past, I will turn the inner eye to see its path.
Where the tech-worship has gone, there will be nothing.
Only Blackrom will remain.

Errata