A vision

by Raph Levien
24 Aug 2001

This document presents a rather far-fetched vision I have for a goal that free software developers may wish to bring to reality. At this point, it's very rough, and not at all intended for general consumption. In fact, it's not so much a document as a conversation.

Background and motivation

Free software is often accused of being best at "chasing tail-lights", ie duplicating systems that have already been fully designed and implemented by the proprietary software industry. This is partly true, yet proponents of free software can also point to quite a few innovations that have come from the free software world, not least of which most of the Internet's backbone, including TCP/IP, the authoritative mail, DNS, and other servers, and the early evolution of the Web.

I propose some explanations for this disparity. Free software operates under some crushing disadvantages compared with proprietary software, but also has some killer advantages.

Disadvantages:

Advantages:

(todo: these need to be filled in and explained)

At present, it's hard to point to a compelling vision for what free software is trying to achieve. The original goal of the Gnu project was essentially to create a clone of proprietary Unices that were available at the time. Well, we've done that. The Gnome and KDE projects largely exist to clone the kind of desktop environment that users expect from Windows and Macintosh, and we've sorta done that.

What next? I don't personally find the .NET environment compelling, even though it's got some nice pieces.

So here I propose a vision for a system, which in many is much more ambitious than current proprietary efforts, yet (hopefully) strips away enough of the useless complexity that it's actually practical for a bunch of intelligent, motivated, but unpaid volunteers to build. One caveat, though. It's going to require a lot of research. I think that's a good thing. Depending on research adds too much risk for most proprietary software companies. But for free software developers, research is a big part of why it's fun.

Configuration science

Current computer systems suck. A big part of why they suck is that they require so much time and effort to configure. In fact, if you added up the cost of all the time spent fiddling with configuration, it would be unimaginably large. Virtually all of the salaries of sysadmins, network admins, and database admins fall into this category as well.

It's worse than that. A huge fraction of security vulnerabilities in practice are due to misconfigured systems. Good sysadmins are supposed to keep track of all the updates and patches, apply them regularly, and fix the things that the updates break. That's a lot of work, though, so it usually ends up not being done.

I believe it doesn't have to be this way. I believe it is possible to build systems that for the most part configure themselves. When you get a new gadget, you should be able to plug it in, turn it on, and have it Just Work. However, we don't know how to build these systems yet. I christen this gap in our understanding the new field "configuration science".

I didn't quite invent the phrase. I've heard it used derisively by acedemics to refer to parts of system design that aren't worthy of intellectual study. I think they've got it backwards.

Athshe

In early 1999, I got very excited by the prospect of the W3C's DOM. I started implementing an SVG editor, Gill, which relied heavily on the DOM to support it's Model / View architecture. I quickly got disillusioned. The concepts behind DOM are noble, but in practice it's way more complicated than it really should be.

I gave some thought to what a DOM would be like if it didn't have all the XML-world complexity and W3C brain damage. I called the resulting design Athshe. I never really wrote it up properly, and have not pushed it at all. Yet, I still think it's a damn good idea.

The idea of Athshe is fairly simple. Throughout computer systems, you see a package of four data structures replicated over and over: key->value mappings, sequences, metatags, and blocks of binary data. Here are some examples:

Key->value mappings

Sequences

Metatags

Blocks of binary data

I've grouped together uses of these concepts from dramatically differing levels of granularity. Further, some are used over the network (the world), some are at the level of filesystems (your computer), and some at the level of individual files or e-mail messages.

I believe that it's both possible and a good idea to unify these concepts across such widely differing levels of granularity. For one, I believe it's common for systems to move between levels of granularity. Examples:

Free software

* www.levien.com