Consider the shiny red apple. “Buy me! Eat me!” it cries.

And what if you do? Will it be crisp, sweet and just a bit tart? Will it harbor a worm?

Will it be worth it? Will it deliver a good value??

Call those “signal value”, and “use value”. The attractive apple signals its value, but only by using the apple can you know its true “use value”.

Imagine! What you might do with that apple? You might display it in a bowl on the table. You might add it to a fruit salad. You might carve a hole in it, fill it with brown sugar, bake it, and later top it with ice cream. You might even fling it at a mugger and save an old lady. That apple is full of potential. How many old ladies might you save? Do these options make it more valuable?

If you watch, sometimes you will see shoppers in that trance of imagination. Boys in hardware stores will look at the coils of rope. They will imagine all the things they might do if they only had a length of rope. Oh, the trouble they might get into! They don’t value the rope particularly for its signal value, or for a use value. They value all those imagined worlds where that rope might play a role.

A designer might choose to focus on any mix of these three kinds of values. A car, for example; he might try to make it signal sophistication. He might labor to make it solid, affordable, reliable. He might attempt to create a car that enables a larger range of imaginary uses: a place to store the canoe, a holder for the french fries, a removable seat

But really I want to talk about software.

Software is assembled from modules with a liberal amount of caulking. Much of the craft of software design consists of design patterns for designing modules well.

I don’t think it’s too exaggerated to say that much of that craft is informed by a castle metaphor. Which is to say that a module is like a castle. You dig a moat around the module to defend it. You drop a carefully designed drawbridge (or more) to allow your users, about whom you are naturally somewhat paranoid, to safely transact with your module.

This metaphor is full of delightful consequences. Life is easier for your users, since they need only understand the drawbridge and can happily ignore all whatever bizarre things you might be doing behind the castle walls. For example you can safely reengineer your module without disturbing them. The metaphor runs deep, because it ties into one’s ideas about property rights, privacy, safety, etc.

But what if this is entirely backwards? What if this is entirely the wrong way to think about modules? What if we should be thinking like that car designer?

Shouldn’t the real goal of a powerful module be to create a large universe of options? Shouldn’t an exciting module create for its users the pleasure that a small boy gets when he contemplates a coil of rope?

Open.

A good module opens a universe of potentials, it delivers a bundle of options.

The modules whose design is grounded in the castle metaphor are often closed. They hoard their options.

These ideas are in partly the fault of Baldwin and Clark’s paper, “Does Code Architecture Mitigate Free Riding in the Open Source Development Model?“.

The most excellent cartoon of open-source offered in that paper is roughly as follows. If designers of open-source projects strive to design a kernel who’s nature creates a large bundle of options, then good things happen. Outside developers, with no coordination, are empowered to pick from among those options. They will, obviously, select the ones that best fit their skills and needs. The authors call each of those options a module, and the architecture modular. The kernel creates a kind of organizing principal for the project, a way of parceling out (or allocating) the work. The designer’s reward is that he gets to see his imaginary world built out – as if by magic. The contributing developers get rewarded directly – one module pays its own freight with that developer. The project thrives, assuming we can keep the barrier low enough so that developers contribute back their additions.

Abracadabra, the free riding problem is solved, and with luck the network effect around a project spins up enough to become self-sustaining.

Very nice.

But more than anything else, what I found fascinating was that the open source design problem is entirely inside out from the classic software engineering module design problem. The goal isn’t to create a beautiful well-guarded castle on a hill. The goal is to create a point of rendezvous. A place where a crowd of people wander about in a trance, imagining, “What kind of trouble might I get into with that rope?”

In France I like to go to the food markets. People walk slowly. They look at piles of mushrooms, beef, apples. I assume they are imagining, “Just what might I do with that apple?”