Brian Proffitt has a great article on the difference between communities and crowdsourcing and how companies still often get it wrong with respect to their community building by treating them as a group that will get things done. I came across a good model for this separation of ideas quite by accident.
A professor friend specializes in Italian history. His current research explores the history of Italian coffee and it's spread in the modern world. In a recent presentation ["Cappuccino Conquests" on iTunes, 20 mins plus Q&A], he made an observation that struck me as an inflection point for companies attempting to develop open source communities. He's talking about a particular set of coffee houses in England during the Temperance Movement of the 19th century and how they failed because they were too prescriptive in their messaging. The rise of the modern coffee house, and certainly the rise of Starbucks happened because there was a "co-production of community". [This discussion happens around ~13:00 to 15:00 if you're in a hurry, but the whole discussion of coffee houses historically as alternative work places (think Lloyd's of London) and as places of social democratization is well worth the listen.]
Starbucks didn't "create" the community, but rather created an environment in which the community was co-produced. I think we often get lost in the open source world in the software artifact itself. We understand the co-creation of the software, but fail to understand the co-production of community. Companies trying to develop community often make the mistake of thinking "if we publish, they will come." What's actually required beyond publishing the code under a liberal license is the creation of an environment in which like-minded people can co-produce the community. This is actually a little more than Tim O'Reilly's architecture of participation, and people need to be reminded that community requires not just care and feeding but listening and a sense of equality or partnership as well.
Jono Bacon's excellent "Art of Community" is a blue print for what's needed to build community. The first step that's required, however, is to understand that the community needs to be co-produced and that can only happen when the environment is right.
A recent diatribe about the Linux community made me stop and think about the role of foundations in community building. While I'm sure one can get the vitriolic response the blogger appears to have received asking questions in the wrong discussion forum, I look at the Linux Foundation is an excellent example of an environment in which a community is co-produced. When you think about it, the Eclipse Foundation and the Apache Software Foundation also produce such environments in which communities thrive and develop themselves. (I am certainly working towards providing such an environment for new communities within the Outercurve Foundation.)
We've known how to build communities since you had a campfire and I wanted to sit beside it. As Bob Young once observed, "A community is just a group of people with something in common — they don't have to like each other." But successful communities thrive when there's a sense of equality between participants and joint effort. When I think of the business environments in which I want to spend time working with others, the coffee house is a pretty good business metaphor. It would do well for businesses trying to build code communities to think about how much they're trying to message and direct the "conversation" and whether they'll be successful with that approach.