What Can the Apache Software Foundation Teach Us about Collaboration?

In a recent interview, Justin Erenkrantz, the president of the Apache Software Foundation, discusses some of the day-to-day operations of the ASF. There's some history in there, but also a really good introduction for those unfamiliar with the ASF.

Here's a bit that caught my attention. Justin quotes Roy Fielding:

One of the key things in Apache, another quote from Roy Fielding is, "If it didn’t happen on the mailing lists, it didn’t happen." All of the discussions, all of the decisions, have to be made on our published mailing list. That allows people who may be in different time zones, or different work schedules, to coordinate through this mailing list.

This strikes me as important because there are a lot of people in the "regular business world" trying to enable or improve collaboration -- through social networks and such -- and they're trying to do it while still accommodating face-to-face meetings, offline conversations, and closed-door sessions. No organization is perfect, but the ASF says this: if we remove the assumption that we will sometimes exclude some people from observing or participating in our discussions, or take a decision "off-line" in a private phone call, then we can support collaboration on highly complex projects with a relatively basic infrastructure. That's the opposite of a lot of business "collaboration" which seems to only be helpful in gathering information. When a decision is required, a single person or small group of people makes the call for the whole group.

Of course, the interview points out that the ASF does have a hierarchy. To contribute to a project, one earns greater privileges as one demonstrates usefulness and an attitude that is appropriate to the community. Thus the ASF refers to itself as a meritocracy. Reputation matters greatly in the ASF's projects, and so does attitude.

In the interview with Justin, a few things about the ASF strike me as important:
- The ASF is essentially a "community of practice" - a group of people with closely aligned expertise and day-to-day job responsibilities.
- Each project is an effort organized around a rather specific goal - the improvement and release of a certain software product.
- Participants typically involve themselves in multiple projects, so cross-fertilization tends to be common, facilitating interoperability among different technologies.
- Participation (or a leadership role) in one project does not grant special privileges in another.
- One of the ASF's primary roles is to protect its projects from an inappropriate degree of corporate influence.
- Leaders in the ASF have a responsibility over the projects' operations with respect to the foundation's rules, but they do not "govern" technology decisions.
- There is a transparent system for determining how one achieves rights and privileges.
- There is a lot of disagreement and argument, but projects rarely fork.
- The organization adapts to support new requirements.

Here's my question: when attempting to improve collaboration in an organization, what can we learn from the experience of the ASF and organizations like it? The ASF presents an example of one set of "ground rules" for collaboration, but there are others, some quite different. How well would an "Apache style" collaboration model work for your projects?