Here’s what gets me excited about making: it lets you build stuff the way we build software. Historically, there have been two ways to make stuff. You could be an artisan and decide how you’d work, and your stuff would be expensive, though it was pleasant to make and was often beautiful. Or you could go to a factory and be part of a process that predetermined precisely how you’d work, down to the finest movement; your stuff would be cheap, and though it was sometimes beautiful, it was often horrible, and it was never nice to make.
Then along came software: suddenly, you had people working like artisans, but producing like factory workers. Software tools made it cheap to coordinate the labor of lots of people, so you could run something with the efficiency of an assembly line without requiring people to work in tightly coupled ways.
You write this chunk, I’ll write that chunk, and we’ll use the version-control system to keep track of who’s doing what, and to let us roll the code versions forward and backward when things break. And when we’re done, the infinite reproducibility of software will let us sell it or give it away at industrial scale. We can work from our hammocks and outperform the cubicles!
So now here’s “making,” where we’re using networks and software tools to coordinate our activities. We trade recipes and 3D objects, and improve them. We sit on chat channels when we’re bored, and offer just-in-time mentorship to newbies who’re getting started. We produce things that everyone thinks of as coming from a factory, but we make them here in our garages and offices and living rooms and basements and kitchens.
But there’s a critical difference between bits and atoms: the cost of burying your mistakes. When code doesn’t work, we erase it. When stuff doesn’t work — or gets superseded — we try to recycle some of it, but most of it goes to landfill. And most of the stuff we work with has a duty cycle of a month or a year or two, but has a half-life of a millennium.
It’s one thing to do iterative design that has you trying variation after variation in your code base; it’s another thing to squander rare earths, hydrocarbons, and the like on a series of experiments. These resources are cheap, yes, but only because they externalize the cost of dealing with them to generations yet to come — that is to say, your kids and their kids.
Makers aren’t the worst offenders, not by a long chalk. The world is full of stuff-mongers who make everything from Happy Meal Toys to thumb drives out of materials that future archaeologists will puzzle over in the year 3522 A.D. — and yet these objects have a useful life measured in months, or possibly a year or two. We’d be better off figuring out how to make them out of spun potato peels and straw, but here they are, in their millions, made out of absurdly long-lived polymers and metals, without a thought as to how they’ll degrade into the materials stream for recycling and reuse.
But makers are supposed to be inventing the future, living as though it were the first days of a better nation. If we’re to bring the glory of software-like production to the world of atoms, let’s figure out how to match the duty cycle to the material life of our components. How do we build complex technical devices that are designed to fall apart (into useful materials, or compostable ones!) by the time we get bored with them?
ADVERTISEMENT
