Section 22.4. What Should We Do Differently?

22.4. What Should We Do Differently?

Political ideas, like democratic experimentalism and distributed community problem solving, share some central characteristics with the open source software process.^[5] In my view, the most interesting intersections lie in the configuration of referee functionshow any system decides that some "code" is better than others and should be incorporated into an interim package, how long it should stay there, how it can be removed or modified and by whom, how it ought to be configured to interface with other code, and what happens when the system breaks down. These are constitutional questions in a profound sense, in that they reflect on the constitutive elements that make up a community (even if they are not legally enshrined in something that people call a constitution).

^[5] See, for example, M.C. Dorf and Charles Sabel, "A Constitution of Democratic Experimentalism" (Columbia Law Review, 1998).

Open source communities are tackling all of these problems, with varying degrees of self-consciousness. The patterns and practices of collaboration within open source communities are evolving rapidly, and that provides interesting experimental insights that can travel outside the software and technology worlds. The seven design principles I laid out earlier are not optimization functions. They are explications of trade-offs; understanding them is a prerequisite to smart experimentation. So, the first thing we should do differently, or more than we do at present, is to instrument some of these experiments and tighten up the feedback loops so that we learn more quickly and more precisely about what happens when you slide the levers of these seven design principles into different configurations.

The second thing we can do differently is to get precise and transparent about the overall goal of communities of knowledge and practice in politics. Open source communities provide a very good template for a broad statement of goals. I propose that when designing a system, you ensure the following:

• The system has effective individual incentives, organizational structures, and information technology tools...

• To pull together distributed knowledge within communities that are trying to solve practical problems...

• By combining pieces of knowledge into something useful in a manner that...

• Ensures that error correction exceeds the rate of error introduction as the system "learns," while...

• Maintaining the process over time in a sustainable, nonexploitable, and expandable way.

The challenge and opportunity here are highly general across political communities. And they are going to get more important in the future, particularly as the economics and demographics of advanced industrial countries continue to drive many of the social welfare functions that have for some time been provided by the public sector, out of that sector. Some of these functions, of course, get moved into the private sector. And social scientists have learned a great deal in the last 20 years about the upsides and downsides of what is commonly called "privatization." We argue around the margins about how to engineer the transition and we argue about the overall efficacy and desirability of the outcomes, but at a high level we do understand a fair amount about sensible governance principles and the tradeoffs they engender in the private sector setting.

We know much less about how to set up systems for moving some welfare provision functions into the civil society space, which is neither public sector nor private sector per se. Open source-style collaboration is, in a real sense, a form of technologically enabled civil society. And so the third thing we can do differently is to mine the experience of open source for lessons about how to create pragmatic, workable alternatives to privatization that can be implemented and can evolve within a developing civil society space.