The Thousand Year Roadmap

I made this presentation at Seneca’s FSOSS a few weeks ago; some of these ideas have been rattling around in my brain for a while, but it was the first time I’d even run through it. I was thoroughly caffeinated at the time so all of my worst verbal tics are on display, right as usual um right pause right um. But if you want to have my perspective on why free and open source software matters, why some institutions and ideas live and others die out, and how I think you should design and build organizations around your idea so that they last a few hundred years, here you go.

There are some mistakes I made, and now that I’m watching it – I meant to say “merchants” rather than “farmers”, there’s a handful of others I may come back here to note later. But I’m still reasonably happy with it.

One Comment

  1. Posted November 16, 2015 at 4:36 pm | Permalink

    Very cool talk, and the subject is one I’ve thought about a lot. Having an open architecture is definitely necessary to longevity. However, it’s only the ante at the table. Once you’ve successfully disseminated the knowledge of your processes and values, you still have to get people to pay attention to the information you make available. While Damascus steel and Greek fire were trade secrets, there were other (particularly non-military) technologies that weren’t actually secret in their day. That didn’t prevent them from being lost.

    Part of the problem is the peculiar human institution of division of labor and specialization. Even if a web-browser is open source, most people treat it as somebody else’s problem, an externality. If enough people don’t invest the years necessary to understand how browsers work, that knowledge *will* eventually be lost no matter how many copies of the artifact survive.

    But it’s not an insoluble problem. Division of labor has been essential and its benefits long outweighed its drawbacks, but I think software finally gives us a way to avoid division of labor. Software is intrinsically a medium for recording of methodological (rather than purely factual) knowledge, it just needs the right representation. I’ve been working on ways to reduce the investment needed to learn complex new codebases: Key is to avoid the vicious cycle of abstraction, where you promise someone they never have to worry about the internals of your library, freeze its interface, and then make contortions to satisfy the prematurely-ossified interface that make its internals ever harder to understand. In its place, I’m exploring a virtuous cycle where using something gradually gets one to learn about its internals, causing the internals to be organized to reward curiosity.

    To your dictum of “don’t create systems of secrets” I’d add “white-box, not black-box”.