Problem

Conventional wisdom holds that software has low incremental cost. But we haven't really achieved that promise. Software starts out with low incremental cost, but requires growing investments over time, large teams of people constantly engaged in its care and feeding.

Even with these investments, velocity slows. Vulnerabilities become easier to create. Onboarding newcomers becomes more difficult. Our tools become unaccountable to people.

This trajectory looks a lot like mining. There's a limited window of benefit extracted from an externality. Then we hit diminishing returns. And the environmental cost is paid over an even longer time thereafter, while benefits are captured by a small group.

Goal

An eco-system of software with a sustainable life cycle. Big picture comprehensible to outsiders. 100x more review of its internals. No reduction in velocity over time.

Detail

Most programs start out easy to modify but lose this property over time. They try to present a fixed "black-box" interface to the outside so that people can take them for granted, gradually forget they exist. Over time it takes more and more complexity to preserve this illusion of stability and invisibility. And it's inevitably a losing battle.

Instead, I want to design automation to naturally colonize space in people's heads. As people use it over time, they naturally understand details about how it works. Nothing is hidden. You don't need to know much to start using it. But if you stick around, you will find yourself learning more and more.

Computers shouldn't be like cars, to be delegated to expert mechanics. They should be like laws, for everyone to engage in supervising. Code and laws can have subtle effects that become apparent only over months or years. So there's no way to delegate them indefinitely to others and remain certain that your interests are being protected.

Colonizing brains seems magical. How would it work? The key is to encode in source code not just what the computer does but why. I currently do this using novel kinds of automated tests. Tests allow latecomers to ask the program what-if questions. What if I built it like this? Why do I need this feature? Make the change you're curious about, see what tests break. If no tests break, use your changes with confidence that you haven't caused any regressions.

A community with more approachable software will tend to spread out expertise in it more broadly over time. A community with lots of diverse expertise will naturally depend less on compatibility guarantees. Changing callers will become easy. Tests will flag when a caller is missed. Automation without compatibility constraints will stay simpler and easier for people to comprehend.

When people comprehend the insides of their automation they'll naturally tend to make changes to it. More forks will be spawned. It'll be easy to delete features you don't care about. People will more fluently bounce between forks. Society will organically be partitioned across many slightly different versions. A single software vulnerability will affect less of the world.

I still want people to be able to share software widely, but I'm ok with some need for manual 'fitting' to copy a subsystem from one computer to another.

Principles

• Few dependencies, zones of ownership.
• Diversify across multiple zones of ownership.
• Prefer counter-parties of approximately the same (0.1x-10x) size. Gemini/Twtxt/Tilde > Mastodon > Slack > Google/Facebook.

Methods

• Deliberately leaky abstractions, minimalist requirements.
• Version control for comprehension.
• White-box tests.
• Fork projects when they accumulate too many constraints.

Projects

• Freewheeling Apps: A growing family of software that is easy to try out, easy to modify and easy to share. A test bed for my principles built on a stable, parsimonious 5MB platform (LÖVE) that I don't own. An eco-system that supports others in tailoring apps for themselves by showing the big picture of each app, and the consequences of changes live as the app is running.

• Mu: an uncompromising foundation for software. Zero external dependencies (no C), perfect memory safety. Wants to be the ideal software for running servers, but currently requires running atop an x86 processor and Linux kernel (reintroducing C). There's a bare-metal version that runs without Linux, but it has no networking and only runs under emulation.

• Teliva: a flexible platform for running untrusted software. Depends selectively on existing software from diverse suppliers. Wants to be the ideal client, but currently restricted to text mode. Allows people to organically learn an app's internals and grow to trust it.

Last updated Jul 26, 2023