[The following article was adapted from a presentation delivered February 17, 2000 as part of "The Unfinished Revolution," a series of seminars held at Stanford University under the direction of computer pioneer Doug Engelbart. It was published in the November 2000 "Visions" supplement of Government Technology magazine under the title "Designing Killer Government Apps." It appears here under its original title, understood by the audience to mean "the killer app for Dynamic Knowledge Repositories," which are central components of Engelbart's program for advancing Collective IQ.]
This idea originated with Ken Clements, a fellow Foresight Institute senior associate. Ken and I met at a Foresight Nanoschmooze. I had spent the day attending the first session of an e-commerce standards organization called ebXML, which is a joint initiative of OASIS and the United Nations body for electronic trade, UN/CEFACT. Ken, I discovered, had recently helped complete the standardization of an important wireless communication protocol, IEEE 802.11. We began comparing war stories about how you actually develop technical standards and get people to agree to them. Ken shared a thought for applying technology to committee work, and I subsequently extended it and wrote it up as a proposal. This is the idea I'd like to share with you.
I should explain that I am very interested in Doug Engelbart's notion of collective IQ. I can testify that under the right conditions, groups of people can come together and think at a level that is beyond the abilities of one person. I agree with Doug that we need technologies to support collective IQ in order to solve the big problems that we've been discussing in this seminar.
We've been assuming in these discussions that better solutions to critical problems like the energy crisis come from better information. It's my observation, however, that not all disagreements are due to misunderstanding. Take the abortion controversy. People are not going to stop disagreeing about this if you provide them with better information. I believe this to be true of many of our hardest public policy concerns.
Issues that cannot be resolved simply by providing better information cannot realistically be resolved by consensus. This is especially true when decisions affect existing economic interests, as is the case, for example, in determining energy policy.
But we not only have to make decisions about these hard problems, we also have to consent to be legally bound by our decisions. So the question I'm interested in pursuing as an information technologist is this: How do we use technology to facilitate the process of making legally binding decisions on matters about which we cannot always achieve consensus?
We have a traditional answer to the problem of how to make formal decisions when not everyone agrees on the solution. It is far from new; pieces of it go back almost four centuries. I'm talking about the Anglo-American parliamentary process. In the U.S., we have a standard specification for this process called Robert's Rules of Order.
The traditional process is deeply woven into our legal and social structures. An earlier speaker in this seminar noted that there are some 87,000 federal, state, and local governments in the U.S. Virtually all of these governments, as well as many U.S. corporations, are operated under some variation of the process embodied in Robert's.
So what's wrong with the traditional process? Quite simply, it's slow, it's complicated, and worst of all, it doesn't work online. As every user of e-mail has discovered, going online has some clear practical advantages, and our inability to put formal deliberation online has meant that efforts to institute "electronic democracy" never seem to get much beyond the establishment of informal discussion groups. Useful as they are, these can never substitute for the processes that formally determine public policy.
It's unfortunate that the traditional process resists computerization, because there are a lot of things to be said in its favor.
First, the traditional process is the epitome of democracy. In practice, democratic rule means following a set of democratic procedures. I believe that any fair, orderly, majority-rule process will eventually evolve into something that looks like Robert's.
Second, the traditional process is fully documented. You can go into any bookstore or library in the country and get a copy of Robert's.
A third big advantage of the traditional system is that it is, as we say in the computer business, thoroughly debugged. The reason that the current edition of Robert's is seven hundred tedious pages thick is that its users have, over the course of a century and a quarter, worked through just about every possible wrinkle in formal procedure.
A Robert's process is also capable of bootstrapping itself. With a copy of Robert's you can turn any gathering into a deliberative assembly that is every bit the procedural equal of all the other governments and quasi-governments in the land. This is pretty amazing.
These qualities make the traditional process enormously robust. As long as people are willing to follow the rules, it will produce a solution. This is the kind of process we need to deal with the hard issues. So maybe the problem of putting the traditional process online is worth another look.
Technically, the heart of the problem is that e-mail is too slow. Phases of the traditional process that take place in seconds during a meeting require a complete cycle in e-mail, which in most distributed committees takes 48 hours or more. You can always conduct mail ballots (as Robert's has allowed for at least a century now), but you cannot make or amend motions effectively in e-mail. So the solution is not simply to transpose the traditional process into e-mail. We need a completely different way of looking at this.
My observation, and it's the only original contribution that I can claim here, is that any process that is set up according to Robert's is, in computer science terms, a state machine. I don't mean that it would be a state machine if we put it online, I mean that it's been a state machine all along. The state of the traditional parliamentary process is what gets saved when it adjourns to the next day. Such a machine moves from state to state in a way that's completely determined by its inputs. Parliamentary motions can be seen as commands to this machine, and thus the eighty-odd motions in the current edition of Robert's can in computer terms be thought of as the machine's instruction set.
It ought to be possible to implement such procedural machines in software. To give this idea some substance, Ken and I came up with something we call the Parliamentary Assistant.
Imagine a Robert's process running on a web server. The server takes care of all of the procedural details and maintains the document base, so it's automating a great deal of the work that humans usually have to perform. Interaction with the machine takes place through forms that the server presents to the user, so working with the system is similar to ordering a book online or interacting with a computer game. (Indeed, if the system were fast enough and interactive enough, the social dynamics of such software could actually start to resemble the social dynamics of a multiuser game.)
If it were technically feasible, the benefits of implementing our traditional process this way would be considerable.
First and most important, the server would always know the state of the process. This would significantly ease the burden on the human participants and completely eliminate the infamous "point of order." Points of order would be impossible in a software implementation of the traditional process, because the user simply wouldn't be offered any choices that weren't legal at that point.
Another benefit would be the elimination of priority conflicts among speakers. Much of traditional parliamentary procedure has to do with ways of determining who has the floor. This is to prevent people from interrupting each other. But in a digital setting, it's impossible for one person to interrupt another. If someone's contribution arrives one millisecond later than someone else's, the first comes earlier and the second comes later. There is no question about the order.
Thinking about the parliamentary process as a machine lets us apply some useful machine concepts. When an assembly amends a motion, for example, and then amends the amendment, it is asking the same process or piece of procedural machinery to operate upon itself; in programming, this is called recursion.
Another machine concept that applies here is parallel processing. When a committee forms a subcommittee, it is creating a parallel process that runs according to the same rules.
The application of machine concepts to the traditional process suggests some optimizations. For instance, one of the factors that really slows down the traditional process is that we can only talk about one thing at a time. With computer assistance, I think we can do better than this.
Consider how it's decided to end debate on a particular question. If a motion is pending and someone wishes to proceed to a vote, debate has to stop temporarily in order to take up the question of whether to end the discussion. But in a machine version, the main question would not have to be set aside in order to decide whether to end the discussion. Applying the concept of parallel processing, we could put consideration of the motion to stop the debate in the background, on a different track from the thing we're talking about. So we could start collapsing the time it takes to do this. The idea of parallel administrative tracks could be extended to most of the motions related to parliamentary housekeeping.
All the technology that we are currently using to do business online -- electronic forms, menus, and so on -- can be used to construct the user interface to the machine. A really good interface would not only show you what you could legally do at any moment, but it would allow you to preview the next state of the machine if you did it. Basically, the software would hold your hand through the entire process.
An interesting question about a system like this would be the role of the chair. The traditional process relies heavily on the presence of a capable chair. This has the potential to slow down the system tremendously if you try to put it online, because it puts a human interaction into the loop every time the chair is called upon to perform some procedural function, which in the traditional system happens constantly. But if the chair doesn't have to decide who has the floor, or what motion is in order next, or where we are in the process of amending an amendment to an amendment, then we can cut a huge amount of delay out of the process.
Automating all of the functions of the chair is probably impossible. Setting agendas, for example, is a task that's hard to imagine a machine performing successfully. Checking lexical form is another. In the traditional process, you can't say "I move that we do not do X," you can only say "I move that we do X," and it's the job of the chair to enforce this rule. This is a classic example of a task that is brain-dead simple for a human being and really hard for a machine. It's also the chair's job to judge relevance; here again, it's hard to visualize the machine performing this function. So our goal is not to replace the chair but rather to move the chair far enough out of the critical path to make the system work online.
Success in putting our traditional system online could have revolutionary implications for the way society is governed.
What we're suggesting is nothing less than the electronic implementation of our traditional majority-rule parliamentary process in such a way that the online version would be legally identical to the traditional version. With slight modifications to suit local rules, such systems could put every existing structure of government online, from the local school board to the U.S. Congress and from the condo owners' association to the directors of General Motors.
An electronically distributed yet legally binding process would make possible global decision-making by people who are distributed in space and time and make possible local decision-making by people who might not be skilled in the intricacies of the traditional process.
Whether such an approach is technically feasible remains to be seen. But if it is feasible, I think it might be a key to solving the hard policy problems confronting us.
[A copy of the proposal by Bosak and Clements can be found at http://metalab.unc.edu/bosak/pa/pa.htm. The author can be contacted at bosak@eng.sun.com.]