In a previous post, I said we need to Innovate as well as Advocate. How? Here is one idea.
For the non-engineers reading this, a quick explanation: Once upon a time, software was created by coding wizards in ivory towers, who would carefully prepare major software releases, having only trained testers examine them, before with some small fanfare allowing users to purchase the results. As you might imagine, software releases tended to suffer from unexpected bugs when running in the real world with real users pounding on them.
The Open Source movement changed all that in the software world, and the classic essay on the subject is called The Cathedral and the Bazaar, by Eric Raymond. The essay was inspired by the success of the Linux operating system, the development of which “seemed to resemble a great babbling bazaar of differing agendas and approaches…out of which a coherent and stable system could seemingly emerge only by a succession of miracles” - and yet which became the most widely used server platform on the Internet.
Why can’t we do the same with Public Policy? And what would that look like?
Policies and laws are documents. Unlike software, we can pretty much all read and understand them. But we usually do not get to see them until they are in nearly-final state and making their way through the legislative process. Sometimes this is by design – in the worst cases, one side (need I say which?) will assemble an extremely unpopular set of laws, perhaps a budget that strips money from schools, or one that removes protections from large groups of people, and unveil it only immediately before the vote that makes it law. This is pretty much the exact opposite of a healthy development cycle.
The process of actually writing laws and policy occurs mainly out of public view. ALEC, the notorious engine for churning out legislation advancing corporate interests, holds meetings with heavy security and bars journalists from the entire hotel where they are held. Progressive think tanks like SIX have a much more inclusive and open process, but by being explicitly progressive from the outset, also sometimes turn out laws that have had only one-sided input.
Raymond’s key takeaway, that “Given enough eyes, all bugs are shallow“, that more users having access earlier in the process produces better results, transformed the process of software development. Would exposing policy documents during the process of development have the potential to do the same for public policy?
But the trolls! How to have a productive discussion and craft a policy while fending off constant attacks from those who hate the fundamental values behind it?
A bazaar is not a free-for-all, though it may seem so to an outsider. Engineering culture has strong norms, that newcomers are often exposed to in a sort of trial-by-fire. Fundamentally, these boil down to the respect of others’ time and attention, the understanding that work talks, and that if you don’t like how someone is doing things, you are free to branch off it and create something of your own. Open source software in particular is ‘copylefted’, meaning that it is free for anyone to copy and change it as long as the result is also free.
Thus, perhaps an Open Public Policy could have a structure, one that expresses the values behind it. Those who share those values, are invited to help craft the details. Those with different values, should create a different policy entirely, and let the two compete.
New standards in software are usually first expressed in a paper entitled Request for Comments. So in that spirit, here is
Request for Comments 1: A Structure for Open Public Policy
However, another norm is never to have a solution in search of a problem. Linus Torvalds, creator of the Linux operating system, famously said,
“Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you’ll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don’t think about some big picture and fancy design. If it doesn’t solve some fairly immediate need, it’s almost certainly over-designed. And don’t expect people to jump in and help you. That’s not how these things work. You need to get something half-way useful first, and then others will say “hey, that almost works for me”, and they’ll get involved in the project.
And so, while recognizing the big picture lets see if we can apply this technique to a concrete problem. Since these will be open to comments, even presenting something that might be a dumb idea is not so bad – someone will point out why it is dumb, and how it should be fixed, before it becomes law and hurts anyone. So I’ll present here some probably dumb ideas for fixing problems, with the expectation that the community will point out the flaws, and either trash the idea entirely or perhaps save it by fixing them. And in particular, I will request reviews from those my ideas are most likely to offend or upset.
RFC 2: Homeless on Beautiful Streets, an idea for San Francisco
RFC 3: Community Service for Citizenship (TBD)
RFC 4: Responsible Gun Ownership (TBD)
The RFC’s with supporting essays will be published in this new Open Public Policy channel. Readers are welcome to submit, whether your own ideas, policy that is from a well-known organization or existing model law.