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?

Fear: Bad for Individuals, Bad for Groups

I was reading something by Krishnamurti the other day that seemed oddly familiar: "To be creative, which is to have real initiative, there must be freedom; and to have freedom, there must be intelligence." Krishnamurti says that intelligence cannot exist where there is fear or prejudice, and goes on to describe "the intelligent mind": "The intelligent mind is an inquiring mind, a mind that is always watching, learning, studying. Which means what? That there is intelligence only when there is no fear..."

This idea of fear as the obstacle that impedes intelligence, thereby limiting freedom and creativity, reminded me of a similar discussion of the negative effects of fear. In their book Built on Trust, Arky Ciancutti and Thomas Steding identify a half-dozen behaviors that underlie a properly functioning organization, which they call "the leadership organization." The authors argue that when each member of an organization commits to these behaviors and attitudes, the organization builds trust internally, and when there is trust among the members of an organization, it improves its performance.

A quick summary of the book doesn't do justice to the ideas, but what I like most about it is that it's more than platitudes - it's a recipe for building trust in an organization. And what's more, the best organizations I've been a part of were the ones that put the principles of Built On Trust into practice.

I agree with Krishnamurti and I agree with Ciancutti and Steding. Fear stifles innovation, initiative and creativity in individuals, and what's more, it prevents trust from developing within groups. And yet, many business managers believe that fear is an effective motivator. Fear may be somewhat effective at driving workers to a goal, but the cost is an organization composed of individuals who don't innovate, lack initiative, and don't work well together.

The best organizations you've been a part of - was there fear or was there trust and creativity? And more importantly, if you reject fear as a management tool, what do you employ to motivate and guide your teams?