I'm working on ways to better convey the global structure of programs. The goal: use an open-source tool, get an idea for a simple tweak, fork the repo, orient yourself, and make the change you visualized -- all in a single afternoon. I'd like to live in such a world, wouldn't you?

The benefits of such a world extend far beyond mere convenience. Open source would more fully deliver on its promise; are the sources truly open if they take too long to grok, so nobody makes the effort? More broadly, the fact that software is eating the world makes it imperative we keep it easy for anybody to understand, lest we disempower vast swathes of humanity. Specialization has been great to us for ten millennia, but it has also caused problems. We delegate too much to 'experts' because we want to ignore externalities, but the 'experts' then capture our institutions. I'm hoping software will allow us to break out of this cycle of dysfunction by helping us manage the burden of externalities. But first we must manage the externalities that plague software itself.

Software today is based, like the rest of society, on specialization. We delegate our dependencies to some stranger upstream. If something is broken we wait for someone else to fix it. That's an externality. We require things to continue working the way they always have. That's a second externality. We're at the mercy of changes made upstream. That's capture. I want to explore an alternative way, a virtuous cycle where using a dependency gradually causes one to learn its internals, and learning internals gradually empowers one to change them. In this world, upgrades are never effortless, but they also never turn into arbitrarily deep rabbit holes.

Peter Naur thinks (c. 1985) that programs can never be understood without talking to their author. I'd like to prove him wrong, with some help from Christopher Alexander and others. My best-guess solution lies somewhere in the vicinity of http://akkartik.name/post/wart-layers and http://akkartik.name/post/tracing-tests. I'm now trying to apply these ideas to a relatively hostile domain: a mini OS to build full-stack applications that boot directly into a single application, only providing what it requires. If this resonates, get in touch!

Update Nov 2014: Development is now happening in the open.

Update Mar 2015: I've been increasingly exploring the duality between conveying codebases to programmers and teaching programming to non-programmers. The best way to teach people programming might be by getting them gradually making bigger and bigger changes to existing programs. And the biggest reason programming is hard for most people might be that the software stacks we've ended up with actively hinder learning. Even if we forget how bad they are after we cross the chasm to become programmers.

I think the first program I use to demonstrate Mu might be an environment for teaching programming.

Update July 2015: The environment for teaching programming one-on-one.

Comments gratefully appreciated. Please send them to me by any method of your choice and I'll include them here.