I've put a brief review of Karl Fogel's fantastic Producing Open Source Software up on the OSAF Group blog. I don't want to plaster that blog with a bunch of quotes, but I like to do that with my book reviews, so I'm putting those here.

p. 29 Stability in a project does not come from formal policies, but from a shared, hard-to-pin down collective wisdom that develops over time

p. 65 group-based governance is more "evolutionarily stable"

These two are why I like Apache style communities

p. 68 Think of a veto as somewhere between a very strong objection and a filibuster

A great and succinct description of veto.

p. 84 The ability to write clearly is perhaps the most important skill one can have in an open source environ-
ment. In the long run it matters more than programming talent. A great programmer with lousy commu-
nications skills can get only one thing done at a time, and even then may have trouble convincing others
to pay attention. But a lousy programmer with good communications skills can coordinate and persuade
many people to do many different things, and thereby have a significant effect on a project's direction
and momentum.

It's all about leverage.

p. 103 The more a project grows, the more important this sort of consistency becomes. Consistency means that
everywhere people look, they see the same patterns being followed, so they know to follow those pat-
terns themselves. This, in turn, reduces the number of questions they need to ask. The burden of having
a million readers is no greater than that of having one; scalability problems start to arise only when a
certain percentage of those readers ask questions. As a project grows, therefore, it must reduce that per-
centage by increasing the density and accessibility of information, so that any given person is more
likely to find what he needs without having to ask.

Consistency enables scalability

p. 131 Delegation is not merely a way to spread the workload around; it is also a political and social tool. Con-
sider all the effects when you ask someone to do something. The most obvious effect is that, if he ac-
cepts, he does the task and you don't. But another effect is that he is made aware that you trusted him to
handle the task. Furthermore, if you made the request in a public forum, then he knows that others in the
group have been made aware of that trust too. He may also feel some pressure to accept, which means
you must ask in a way that allows him to decline gracefully if he doesn't really want the job. If the task
requires coordination with others in the project, you are effectively proposing that he become more in-
volved, form bonds that might not otherwise have been formed, and perhaps become a source of author-
ity in some subdomain of the project. The added involvement may be daunting, or it may lead him to be-
come engaged in other ways as well, from an increased feeling of overall commitment.
Because of all these effects, it often makes sense to ask someone else to do something even when you
know you could do it faster or better yourself. Of course, there is sometimes a strict economic efficiency
argument for this anyway: perhaps the opportunity cost of doing it yourself would be too high—there
might be something even more important you could do with that time. But even when the opportunity
cost argument doesn't apply, you may still want to ask someone else to take on the task, because in the
long run you want to draw that person deeper into the project, even if it means spending extra time
watching over them at first. The converse technique also applies: if you occasionally volunteer for work
that someone else doesn't want or have time to do, you will gain his good will and respect. Delegation
and substitution are not just about getting individual tasks done; they're also about drawing people into a
closer committment to the project.

Delegation builds trust, which builds community.

There are also some great ideas/wishes for tools on pages 40, 44, and 173. The whole topic of tools is good for another (series) of posts.