Consensus voting should make things go faster, not slower, than a traditional top-down command structure.
Consensus voting also provides a safety net for decision-making in a rapidly changing, knowledge-poor environment.
In consensus voting,
- 1. a proposal is made
- 2a. a significant (but not universal) agreement of N participants is reached in support of the issue, or
- 2b. a risk is identified that is so significant that it tanks the proposal
Of course, 2a can yield a "false positive", but you can control the rate of false positives by adjusting
N or defining qualifications on the participants in any given decision.
That can be a very quick process. The proposals can be fairly speculative. It might have been that only 10 people
out of 70 express views. If they are all positive, that is a consensus and there is no need for further deliberation.
If one person raises a significant risk, then the process gets a little longer until that risk is addressed. This
approach works well when relevant knowledge is spread out among many people and no one person can nail a decision.
In contrast, typical top-down decision making is very risky. It relies on a few people to make decisions on
a wide range of topics that are right the first time. And they must research proposals thoroughly before handing
them down. That works well when the domain is well understood and relevant knowledge is concentrated in a few peoples
Which situation sounds more appropriate to Internet startups? open source projects? large technology corporations?
military and government?
Roy Fielding explained a bit of this in his Communications of the ACM article on apache leadership. Curtis's
"thin spread of domain knowledge" is one of the key ideas here. I see the big advantage of open source
in the way it helps to mitigate the thin spread of domain knowledge in the software development industry today.
-- Jason Robbins
Members of the tigris community are invited to submit editorials on topics of interest. Submitting
an editorial is as easy as sending an email message to: email@example.com
Editorial pieces should be well thought out articles of one of the following types:
- Opinion on an aspect of open source or software engineering.
- Introduction to open source technology or software engineering concept.
- Counter-point to a previous editorial.
- Brief comment or correction.
As soon as your message has been reviewed by the moderators, it will be sent to subscribers and
appear in the editorial archive.
Once a week, one editorial will be highlighted on the tigris.org home page. On occasion, we also
invite editorials from notable people in the broader open source and software engineering communities.
You may subscribe or unsubscribe by sending a (blank) message to:
firstname.lastname@example.org or email@example.com.